Hi all, Sorry for the late reply on all these, and thanks for the feedback so far! I lost track of this thread as I was putting together slides for IETF 116 and whatnot. I’ll reply to various outstanding emails individually...
On Sat, Mar 11, 2023 at 2:43 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > I had a read and think this is a great topic for > discussion. > > A few points: > > - I think we'd benefit from trying to think through > the dynamics of this, e.g. how many of each entity > might we see and how'd that differ from the current > web PKI and possibly affect the web? (It's fine that > that analysis emerge in time, not asking for it now.) > Yup. I think how deployments end up looking will definitely be interesting to figure out. As you say, how this shakes out will emerge in time, but sections 9 and 11 contain some initial thoughts. One thing I think we could have conveyed more clearly is the relationship between an overall certificate negotiation framework and this draft. We’re interested in certificate negotiation because we think it’s a good fit for a host of problems in the PKI, particularly around agility. Notable for this draft is it gives more room to explore the tradeoff space, since we can deploy different solutions for different requirements. Merkle Tree Certificates represent one point in the tradeoff space. We started with this draft because it was fairly self-contained. I’m hoping we’ll have a more refined and concrete negotiation write-up next, which might make some of this clearer. (What’s in there now is somewhat of a placeholder.) > - I do think the trust_anchors extension values might > be better off as e.g. truncated hashes of public keys > or something like that. > That doesn’t quite fit with some directions we’re envisioning, but I agree having the IDs specified tightly would be nice. How about we put a pin in this, and when we’ve got the write-up above ready, we can ponder this? > - Aside from better on-the-wire efficiency, I think > another reason to examine designs like this is that > adding multiple public keys and signatures to x.509 > certs (one of the alternative designs) seems like it > might be a bit of a nightmare, as PKI libraries are > buggily updated to try handle that - designs like > this seem better in terms of keeping the new code in > a less risky place. > > Cheers, > S. > > On 10/03/2023 22:09, 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 <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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
