Hi David, Interesting idea. Seems like a radical, hard change but I want to understand it better. Some clarifications:
- Previously, in the ICA suppression draft you had correctly brought up the challenge of keeping an up-to-date ICA cache while most browsers are not up to date. The Merkle tree mechanism requires constant updates. Would that be even more of challenge with browsers that have not been updated? - To make this work for WebPKI, would the Transparency Service need to fetch from all WebPKI issuing CAs and update them every hour? - CAs would also need to publish their Merkle tree logs similarly to CT, right? - Negotiating a new CertType would be a fingerprint as you say in Section 12. The size in the response is also a fingerprint for the Subscriber. It is not a huge concern for me personally especially if this got wide adoption, but it was brought up before in similar contexts. - To me this draft eliminates the need for a PKI and basically makes the structure flat. Each CA issues certs in the form of a batched tree. Relying parties that “trust and are aware” of this issuing CA’s tree can verify the signed window structure and then trust it. So in a TLS handshake we would have (1 subscriber public key + 2 signatures + some relatively small tree structure) compared to (1 signature + (3 sigs + 1 public key) for server cert + (1 Sig + 1 Public key) per ICA cert in the chain). If we borrowed the same flat PKI logic though and started “trusting” on a per issuer CA basis then the comparison becomes (1 public key + 2 signatures + some small tree structure) vs (1 public key + 4 sigs). So we are saving 2 PQ sig minus the small tree structure size . Am I misunderstanding the premise here? From: TLS <tls-boun...@ietf.org> On Behalf Of David Benjamin Sent: Friday, March 10, 2023 5:09 PM To: <tls@ietf.org> <tls@ietf.org> Cc: Devon O'Brien <asymmet...@google.com> Subject: [EXTERNAL] [TLS] Merkle Tree Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi all, I've just uploaded a draft, below, describing several ideas we've been mulling over regarding certificates in TLS. This is a draft-00 with a lot of moving parts, so think of it as the first pass at some of ideas that we think fit well together, rather than a concrete, fully-baked system. The document describes a new certificate format based on Merkle Trees, which aims to mitigate the many signatures we send today, particularly in applications that use Certificate Transparency, and as post-quantum signature schemes get large. Four signatures (two SCTs, two X.509 signatures) and an intermediate CA's public key gets rather large, particularly with something like Dilithium3's 3,293-byte signatures. This format uses a single Merkle Tree inclusion proof, which we estimate at roughly 600 bytes. (Note that this proposal targets certificate-related signatures but not the TLS handshake signature.) As part of this, it also includes an extensibility and certificate negotiation story that we hope will be useful beyond this particular scheme. This isn't meant to replace existing PKI mechanisms. Rather, it's an optional optimization for connections that are able to use it. Where they aren't, you negotiate another certificate. I work on a web browser, so this has browsers and HTTPS over TLS in mind, but we hope it, or some ideas in it, will be more broadly useful. That said, we don't expect it's for everyone, and that's fine! With a robust negotiation story, we don't have to limit ourselves to a single answer for all cases at once. Even within browsers and the web, it cannot handle all cases, so we're thinking of this as one of several sorts of PKI mechanisms that might be selected via negotiation. Thoughts? We're very eager to get feedback on this. David On Fri, Mar 10, 2023 at 4:38 PM <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-merkle-tree-certs Revision: 00 Title: Merkle Tree Certificates for TLS Document date: 2023-03-10 Group: Individual Submission Pages: 45 URL: https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.txt Status: https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/ Html: https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs Abstract: This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post- quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. The IETF Secretariat
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
