Re: [TLS] Merkle Tree Certificates
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 On Behalf Of David Benjamin Sent: Friday, March 10, 2023 5:09 PM To: Cc: Devon O'Brien 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 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
Re: [TLS] Merkle Tree Certificates
Hi Hubert, I am not an author of draft-davidben-tls-merkle-tree-certs, but I had some feedback on this question: RFC7924 was a good idea but I don’t think it got deployed. It has the disadvantage that it allows for connection correlation and it is also challenging to demand a client to either know all its possible destination end-entity certs or be able to have a caching mechanism that keeps getting updated. Given these challenges and that CAs are more static and less (~1500 in number) than leaf certs, we have proposed suppressing the ICAs in the chain (draft-kampanakis-tls-scas-latest which replaced draft-thomson-tls-sic ) , but not the server cert. I think draft-davidben-tls-merkle-tree-certs is trying to achieve something similar by introducing a Merkle tree structure for certs signed by a CA. To me it seems to leverage a Merkle tree structure which "batches the public key + identities" the CA issues. Verifiers can just verify the tree and thus assume that the public key of the peer it is talking to is "certified by the tree CA". The way I see it, this construction flattens the PKI structure, and issuing CA's are trusted now instead of a more limited set of roots. This change is not trivial in my eyes, but the end goal is similar, to shrink the amount of auth data. -Original Message- From: TLS On Behalf Of Hubert Kario Sent: Monday, March 13, 2023 11:08 AM To: David Benjamin Cc: ; Devon O'Brien Subject: RE: [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. Why not rfc7924? On Friday, 10 March 2023 23:09:10 CET, David Benjamin wrote: > 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 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-0 > 0.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-0 > 0.html > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-c > erts > > > 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 Secretar
Re: [TLS] Merkle Tree Certificates
Come embrace the temptations of the Sea-SIDH! Intermediate certs are rarely used, so that would achieve 204 byte sig on intermediate+ 64 byte intermediate key + 204 byte sig of EE cert since the signing time doesn't matter. Then with SCT and OCSP, it's 204 bytes each. As for the actual proposal, I like the idea of per-protocol subjects. I am worried about the way this makes the PKI a more distributed system, in the Lamportian sense. A certificate being used successfully depends now on the transparency service propagating the batch from the CA and the CA creating the batch, and the user-agent, not the site, determines what transparency service is used. This makes it much more difficult for sites to be sure their certificates will actually work. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
