I don't think flattening is the right way to look at it. See my other reply for a discussion about flattening, and how this does a bit more than that. (It also handles SCTs.)
As for RFC 7924, in this context you should think of it as a funny kind of TLS resumption. In clients that talk to many servers[0], the only plausible source of cached information is a previous TLS exchange. Cached info is then: if I previously connected to you *and I am willing to correlate that previous connection to this new one*, we can re-connect more efficiently. It's a bit more flexible than resumption---it doesn't replace authentication, so we could conceivably use larger lifetimes. But it's broadly the same w.r.t. when it can be used. It doesn't help the first connection to a service, or a service that was connected long enough ago that it's fallen off the cache. And it doesn't help across contexts where we don't want correlation. Within a web browser, things are a bit more partitioned these days, see https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md and https://github.com/privacycg/storage-partitioning. In comparison, this design doesn't depend on this sort of per-destination state and can apply to the first time you talk to a server. David [0] If you're a client that only talks to one or two servers, you could imagine getting this cached information pushed out-of-band, similar to how this document pushes some valid tree heads out-of-band. But that doesn't apply to most clients, certainly not a web browser. On Tue, Mar 14, 2023 at 9:46 AM Kampanakis, Panos <kpa...@amazon.com> wrote: > 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 <tls-boun...@ietf.org> On Behalf Of Hubert Kario > Sent: Monday, March 13, 2023 11:08 AM > To: David Benjamin <david...@chromium.org> > Cc: <tls@ietf.org> <tls@ietf.org>; Devon O'Brien <asymmet...@google.com> > 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 <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-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 Secretariat > > > > > > > > -- > Regards, > Hubert Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > 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
