Re: [TLS] Merkle Tree Certificates
> > I mean, is there a cryptographic reason for it? No. > (However, absent cryptographic reasons, this all is way premature.) > Indeed. We like to have a concrete proposal, but thinking through these details is premature at this point. [snip] What that in effect does > is to make it much more difficult to exploit chosen-prefix collisions in > hash function. However, that requirement holds irrespective of the hash function used, and it has in fact been held for SHA-256 (regardless of there not being > any known even remotely feasible attacks) instead of just being a dead > letter from the past with much worse hash functions. > Ah, it would indeed be neat if we could design this, so that we do not require (chosen prefix) collision resistance of the hash. I'd say it's nice to have, but not a must. Tracking in https://github.com/davidben/merkle-tree-certs/issues/45 Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Mon, Jun 5, 2023 at 12:42 PM David Benjamin wrote: > > It’s true that this would require code changes in more components. But > TLS, ACME, etc., are deployed many more times than they are implemented. > ... [snip] ... > > To ACME specifically, we definitely don’t want it to be painful for ACME > clients to implement! It’s probably a bit hard to discuss that in the > abstract, with our ACME section being just a placeholder. Perhaps, when > we’ve gotten an initial draft of that, we can figure out which bits we got > wrong and iterate on that? > Fwiw, I don't think expertise in PKI is really a concern here. I know more than most people about this problem, but less than everyone else in this thread. I don't even maintain this stuff myself, I just happen to use Google for "Managed Certificates" and never think about it... thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote: > > > Thanks! That’s indeed inconsistent, we’ll fix it. > > > https://github.com/davidben/merkle-tree-certs/issues/32 > > > > Hmm... Looking at that construct, why is the pad there? > > > We pad to the hash block size. When computing the full Merkle tree, or > verifying an authentication path, the values before the pad are the same, > and thus we can precompute the hash state after digesting those fixed > values. > > (With the current inputs and sha256, it will only make a difference for > HashAssertion though.) I mean, is there a cryptographic reason for it? If one wanted to really micro-optimize performance, I think the optimal design for SHA-256 would be to have padding for assertions but not for empty nor nodes (since not padding empty and node saves one block). (However, absent cryptographic reasons, this all is way premature.) > > And there does not seem to be any way to salt the hash. WebPKI requires > > what effectively amounts to salting the hash via serial number (even > > for SHA-256). > > > > Please elaborate. >From CABForum Baseline Requirements version 1.8.7 (2.0.0 has the same requirement, but in several places), section 7.1.: "CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG." In certificate structure, serial number comes very early (it is in fact the first non-length field that varies). What that in effect does is to make it much more difficult to exploit chosen-prefix collisions in hash function. However, that requirement holds irrespective of the hash function used, and it has in fact been held for SHA-256 (regardless of there not being any known even remotely feasible attacks) instead of just being a dead letter from the past with much worse hash functions. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
> > Thanks! That’s indeed inconsistent, we’ll fix it. > > https://github.com/davidben/merkle-tree-certs/issues/32 > > Hmm... Looking at that construct, why is the pad there? We pad to the hash block size. When computing the full Merkle tree, or verifying an authentication path, the values before the pad are the same, and thus we can precompute the hash state after digesting those fixed values. (With the current inputs and sha256, it will only make a difference for HashAssertion though.) > And there does not seem to be any way to salt the hash. WebPKI requires > what effectively amounts to salting the hash via serial number (even > for SHA-256). > Please elaborate. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Mon, Jun 05, 2023 at 03:35:17PM -0400, David Benjamin wrote: > Thanks for such detailed feedback! Responses inline. > > On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara > wrote: > > > Some quick comments / ideas: > > > > - I think it would be easier for subscribers to get inclusion proofs > > from transparency service than certificate authority. > > > > This is because issuance is heavily asynchronous, whereas most > > servers assume ACME is essentially synchronous. > > > > If certificates are canonicalized (this is mostly matter of ensuring > > the names are always sorted), this could be endpoint to download known > > inclusion proofs by certificate hash. > > > > Or maybe even have both, and subscribers can use whichever is more > > convinient. > > > > We’re currently envisioning that the transparency services will potentially > vary by RP. They’re effectively the RP’s CT policy. The different TSs all > see the same trees, just later than the CA. It seems simpler then to get it > from the CA, which will be the least behind. This also means RPs can adjust > TS preferences without impacting subscribers or CAs at all. The equivalent > of a CT log migration and distrust is much less invasive. > > Also, subscribers already talk to CAs via, e.g., ACME, so it seemed natural > to rely on that existing relationship. Especially as subscribers will need > a fallback credential from a CA anyway. > > I suppose there’s no reason why the subscriber couldn’t fetch from the TS. > Though I’m not seeing how it would be more convenient. Could you elaborate? Well, maybe that was a bit X-Y. What I am really after is some mechanism of downloading certificates outside ACME, because the issuance wait is likely prohibitive for many ACME clients. > > I don't see rule for how claims are sorted within each type, > > only how different types are sorted. > > > > - If each claim was in its own Claim, then one could maybe even > > shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and > > dns/dns_wildcard. > > > > This could also simplify sorting: Sort by type, lexicographic > > sort by claim contents. > > > > Thanks! Yeah, the actual Claim bits were just a naive transcription of > X.509 SANs for now without much thought. I filed > https://github.com/davidben/merkle-tree-certs/issues/31 to track those. One use of strict canonical encoding would be to let the subscriber compute the certificate body itself. E.g., so it could look up the certificates by body hash. > > - I don't think anybody is going to use signatures with >64kB keys, > > so subject_info length could be shortened to 16 bits. > > > > Added to https://github.com/davidben/merkle-tree-certs/pull/29 As a note about signature sizes, TLS (1.2 and 1.3) have 64kB signature limit. IIRC, in NISTPQC outside the "interesting" stuff, only PICNIC had trouble with that. However, when it comes to PQC stuff, IIRC there is second call for proposals going on right now. > > > - I think it would be easier if lifetime was expressed in batch > > durations. Then one would not need window size, and especially not > > handle lifetime / batch_duration not being an integer! > > > > I think we’d still need to be able measure it in both units, but maybe I’m > missing something? > > We need something in units of batch duration (currently window size) to > size the signed windows, etc. > > But the RP can’t just use the window in lieu of expiry, because it can’t > simply assume all batches are valid, because the RP may be unable to fetch > new windows for a long period of time, such that the old (or all!) batches > have fallen off. > > We could do that calculation in batch durations, but then we need to > measure the current time in batch numbers, which seemed unintuitive to me. > And then once that was in seconds, it didn’t seem that aligning it on batch > duration did much. Well, actually doesn't look like things get too annoying if lifetime / batch_duration is not an integer: - window size can be just the ceiling of that. - RPs can calculate explicit expiry via t = t_0 + p * t_p + t_l. Neither of which needs floating-point (which one definitely does not want to use here). > > - The root hash being dependent on issuer and batch number iff there > > are multiple assertions looks very odd. > > > > Empty assertion list might be special. But this also happens for > > one assertion. > > > > Thanks! That’s indeed inconsistent, we’ll fix it. > https://github.com/davidben/merkle-tree-certs/issues/32 Hmm... Looking at that construct, why is the pad there? And why are index and level after pad instead of before? And there does not seem to be any way to salt the hash. WebPKI requires what effectively amounts to salting the hash via serial number (even for SHA-256). > > - Is there reason for type of trust_anchor_data to vary by proof_type? > > Why not always have MerkleTreeTrustAnchor there? > > > > The thinking was to be
Re: [TLS] Merkle Tree Certificates
On Wed, Mar 22, 2023 at 11:22 AM Ilari Liusvaara wrote: > On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote: > > > > > > Unpopular pages are much more likely to deploy a solution that > > > doesn't require a parallel CA infrastructure and a cryptographer > > > on staff. > > I don't think the server-side deployment difficulties with this have > anything to do with parallel CA infrastructure or admins having to > understand cryptography. > > > > CAs, TLS libraries, certbot, and browsers would need to make changes, > > but I think we can deploy this without webservers or relying parties > > having to make any changes if they're already using an ACME client > > except upgrading their dependencies, which they would need to do > > anyway to get plain X.509 PQ certs. > > I don't agree. > > I think deploying this is much much harder than deploying X.509 PQ > certificates. X.509 PQ certificates are mostly dependency update. This > looks to require some nontrivial configuration work that can not be > done completely automatically. > > And then in present form, this could be extremely painful for ACME > clients to implement (on level of complete rewrite for many). > It’s true that this would require code changes in more components. But TLS, ACME, etc., are deployed many more times than they are implemented. As the code changes happen per software package, hopefully the per-deployment cost beyond that can be minimal. (Though, of course, that will depend on exactly how each package's existing configuration interface looks, and how/whether they apply it to the new thing. Understanding what protocol properties would make this easy or hard would be very useful, but I also suspect it depends on a lot of details we've still left as placeholders right now.) These things also don’t have to happen all at once. It can be a transition over time, or perhaps some sites just stay with the fast-issuance mechanism (be it X.509 PQ or something else) if they’re happy with it. Merkle Tree Certificates themselves cannot be your only certificate type anyway, since they only work with up-to-date RPs. To ACME specifically, we definitely don’t want it to be painful for ACME clients to implement! It’s probably a bit hard to discuss that in the abstract, with our ACME section being just a placeholder. Perhaps, when we’ve gotten an initial draft of that, we can figure out which bits we got wrong and iterate on that? David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
Thanks for such detailed feedback! Responses inline. On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara wrote: > Some quick comments / ideas: > > - I think it would be easier for subscribers to get inclusion proofs > from transparency service than certificate authority. > > This is because issuance is heavily asynchronous, whereas most > servers assume ACME is essentially synchronous. > > If certificates are canonicalized (this is mostly matter of ensuring > the names are always sorted), this could be endpoint to download known > inclusion proofs by certificate hash. > > Or maybe even have both, and subscribers can use whichever is more > convinient. > We’re currently envisioning that the transparency services will potentially vary by RP. They’re effectively the RP’s CT policy. The different TSs all see the same trees, just later than the CA. It seems simpler then to get it from the CA, which will be the least behind. This also means RPs can adjust TS preferences without impacting subscribers or CAs at all. The equivalent of a CT log migration and distrust is much less invasive. Also, subscribers already talk to CAs via, e.g., ACME, so it seemed natural to rely on that existing relationship. Especially as subscribers will need a fallback credential from a CA anyway. I suppose there’s no reason why the subscriber couldn’t fetch from the TS. Though I’m not seeing how it would be more convenient. Could you elaborate? > - I don't think there are any sane uses for >64kB claims, so the > claim_info length could be shortened to 16 bits. > Works for me. https://github.com/davidben/merkle-tree-certs/pull/29 > I don't see rule for how claims are sorted within each type, > only how different types are sorted. > > - If each claim was in its own Claim, then one could maybe even > shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and > dns/dns_wildcard. > > This could also simplify sorting: Sort by type, lexicographic > sort by claim contents. > Thanks! Yeah, the actual Claim bits were just a naive transcription of X.509 SANs for now without much thought. I filed https://github.com/davidben/merkle-tree-certs/issues/31 to track those. > - I don't think anybody is going to use signatures with >64kB keys, > so subject_info length could be shortened to 16 bits. > Added to https://github.com/davidben/merkle-tree-certs/pull/29 > - What does it mean that in this document the hash is always SHA-256? > Just that the hash function used in building the trees, etc. is SHA-256. (It’s the only ProofType we’ve defined. One could define others, but I don’t particularly care to.) > - Apparently issuer id is limited to 32 octets. This could be noted in > the definition. > Also added to https://github.com/davidben/merkle-tree-certs/pull/29 > - I think it would be easier if lifetime was expressed in batch > durations. Then one would not need window size, and especially not > handle lifetime / batch_duration not being an integer! > I think we’d still need to be able measure it in both units, but maybe I’m missing something? We need something in units of batch duration (currently window size) to size the signed windows, etc. But the RP can’t just use the window in lieu of expiry, because it can’t simply assume all batches are valid, because the RP may be unable to fetch new windows for a long period of time, such that the old (or all!) batches have fallen off. We could do that calculation in batch durations, but then we need to measure the current time in batch numbers, which seemed unintuitive to me. And then once that was in seconds, it didn’t seem that aligning it on batch duration did much. > - The root hash being dependent on issuer and batch number iff there > are multiple assertions looks very odd. > > Empty assertion list might be special. But this also happens for > one assertion. > Thanks! That’s indeed inconsistent, we’ll fix it. https://github.com/davidben/merkle-tree-certs/issues/32 > - I think LabeledWindow should add 64 spaces in front, so it > reuses the TLS 1.3 signature format. > > This reduces risks of cross-protocol attack if the key gets > reused anyway (despite there being MUST NOT requirement). > Filed https://github.com/davidben/merkle-tree-certs/issues/30. I’m slightly torn on this. The part of me that doesn’t trust people to keep keys separate wants to do it. But the part of me that’s sick of chasing this down in every new protocol would rather we just stop pretending using the same key for multiple things is remotely sensible. :-) > - Is there reason for type of trust_anchor_data to vary by proof_type? > Why not always have MerkleTreeTrustAnchor there? > The thinking was to be extensible for other proof types that may not have the (issuer, number) structure. E.g. perhaps a fast-issuance model that’s more analogous to X.509 with CT, if we get a meaningful enough improvement? This isn’t strictly necessary. We could simply
Re: [TLS] Merkle Tree Certificates
On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd wrote: > 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. > I wasn’t able to find a reference to a Sea-SIDH signature scheme. Do you have a pointer? Do you mean this thing? https://eprint.iacr.org/2020/1240.pdf Taking 2 seconds to generate a signature is... certainly a constraint. :-) > 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. > To some degree, subscribers already rely on this. RPs have various requirements, and it is up to the CA to provide subscribers with certificates that meet the requirements. Some requirements can be checked by the subscriber, but some cannot. In X.509, the certificate chain and signatures can be checked by the subscriber. (Although X.509 is so complex and variable that it’s unlikely the subscriber’s checks exactly matched the RP’s!) But other requirements, notably future policy actions, cannot. The certificate may later be revoked, the CA or CT log may be distrusted, etc. In this proposal, we could have the CA pass the subscriber the signed window alongside the proof (not currently in the draft, but this is a good reason to include it). The subscriber can then check the inclusion proof, hopefully with much less implementation variability than X.509. The subscriber still needs to know if the RP recognizes that batch. These are more dynamic than X.509 roots, but are covered by the negotiation mechanism. On mismatch, you just pick another certificate, such as an X.509 one which is as checkable as before. So this part isn’t so much checked as made moot. (A negotiation mechanism is ultimately “tell me if the RP will accept this cert, so I can filter down to the ones that work”.) Finally, subscriber and RP must agree on what, e.g, root hash #42 was. This flows from CA to TS to RP, which is indeed hard for the subscriber to directly check. (Though the subscriber could always fetch hashes from known TSs to compare.) However, a mismatch here means the CA produced a split view. The responsibilities have shifted, but analogous misbehavior in X.509 + CT would typically result in a policy action, something the subscriber already cannot check offline. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
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 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 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: >
Re: [TLS] Merkle Tree Certificates
On Thursday, 23 March 2023 03:00:53 CET, Kampanakis, Panos wrote: Hi Hubert, I totally agree on your points about time-to-first-byte vs time-to-last-byte. We (some of my previous work too) have been focusing on time-to-first byte which makes some of these handshakes look bad for the tails of the 80-95th percentiles. But in reality, the time-to-last-byte or time-to-some-byte-that-makes-the-user-think-there-is-progress would be the more accurate measurement to assess these connections. Neither cached data nor Merkle tree certificates reduce round-trips Why is that? Assuming Dilithium WebPKI and excluding CDNs, QUIC sees 2 extra round-trips (amplification, initcwnd) and TLS sees 1 (initcwnd). Trimming down the "auth data" will at least get rid of the initcwnd extra round-trip. I think the Merkle tree cert approach fits in the default QUIC amplification window too so it would get rid of that round-trip in QUIC as well. I meant it on TLS level. Sure, on TCP level the less data you need to send the less problem you have with congestion window. But even there, I don't see insurmountable problems with it; even with 3 Dilithium certs, with 2 SCTs each, we're talking about 22kB of data; that's half of what cloudflare found to be an inflection point for extra data: https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ So I'm very unconvinced that for good general web browsing experience Merkle Tree Certs will be qualitatively better than cached info. -Original Message- From: Hubert Kario Sent: Wednesday, March 22, 2023 8:46 AM To: David Benjamin Cc: Kampanakis, Panos ; ; 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. On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote: On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: ... I'm not seeing where this quote comes from. I said it had analogous properties to resumption, not that it was a privacy problem in the absolute. I meant it as a summary not as a quote. The privacy properties of resumption and cached info on the situation. If you were okay correlating the two connections, both are okay in this regard. If not, then no. rfc8446bis discusses this: https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#appendix-C.4 In browsers, the correlation boundaries (across *all* state, not just TLS) were once browsing-profile-wide, but they're shifting to this notion of "site". I won't bore the list with the web's security model, but roughly the domain part of the top-level (not the same as destination!) URL. See the links above for details. That equally impacts resumption and any hypothetical deployment of cached info. So, yes, within those same bounds, a browser could deploy cached info. Whether it's useful depends on whether there are many cases where resumption wouldn't work, but cached info would. (E.g. because resumption has different security properties than cached info.) The big difference is that tickets generally should be valid only for a day or two, while cached info, just like cookies, can be valid for many months if not years. Now, a privacy focused user may decide to clear the cookies and cached info daily, while others may prefer the slightly improved performance on first visit after a week or month break. It also completely ignores the encrypted client hello ECH helps with outside observers correlating your connections, but it doesn't do anything about the server correlating connections. In the context of correlation boundaries within a web browser, we care about the latter too. How's that different from cookies? Which don't correlate, but cryptographically prove previous visit? ... I don't think that's quite the right dichotomy. There are plenty of reasons to optimize for the first connection, time to first bytes, etc. Indeed, this WG did just that with False Start and TLS 1.3 itself. (Prior to those, TLS 1.2 was 2-RTT for the first connection and 1-RTT for resumption.) ... In my opinion time to first byte is a metric that's popular because it's easy to measure, not because it's representative. Feel free to point me to double blind studies with representative sample sizes showing otherwise. Yes, reducing round-trips is important as latency of connection is not correlated with bandwidth available. But when a simple page is a megabyte of data, and anything non trivial is multiple megabytes, looking at when the first byte arrives it is completely missing the bigger picture. Especially when users are trained to not interact with the page until it fully loads (2018 Hawaii missile alert joke explanation): https://gfycat.com/queasygrandiriomotecat Neither cached data nor Merkle tree certificate
Re: [TLS] Merkle Tree Certificates
Hi Hubert, I totally agree on your points about time-to-first-byte vs time-to-last-byte. We (some of my previous work too) have been focusing on time-to-first byte which makes some of these handshakes look bad for the tails of the 80-95th percentiles. But in reality, the time-to-last-byte or time-to-some-byte-that-makes-the-user-think-there-is-progress would be the more accurate measurement to assess these connections. > Neither cached data nor Merkle tree certificates reduce round-trips Why is that? Assuming Dilithium WebPKI and excluding CDNs, QUIC sees 2 extra round-trips (amplification, initcwnd) and TLS sees 1 (initcwnd). Trimming down the "auth data" will at least get rid of the initcwnd extra round-trip. I think the Merkle tree cert approach fits in the default QUIC amplification window too so it would get rid of that round-trip in QUIC as well. -Original Message- From: Hubert Kario Sent: Wednesday, March 22, 2023 8:46 AM To: David Benjamin Cc: Kampanakis, Panos ; ; 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. On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote: > On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: > >> On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: >>> 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 ... >> https://github.com/MattMenke2/Explainer---Partition-Network-State/blo >> b/main/README.md >>> and https://github.com/privacycg/storage-partitioning. >> >> Sorry, but as long as the browsers are willing to perform session >> resumption I'm not buying the "cached info is a privacy problem". >> > > I'm not seeing where this quote comes from. I said it had analogous > properties to resumption, not that it was a privacy problem in the absolute. I meant it as a summary not as a quote. > The privacy properties of resumption and cached info on the situation. If > you were okay correlating the two connections, both are okay in this > regard. If not, then no. rfc8446bis discusses this: > https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#appendix-C.4 > > In browsers, the correlation boundaries (across *all* state, not just TLS) > were once browsing-profile-wide, but they're shifting to this notion of > "site". I won't bore the list with the web's security model, but roughly > the domain part of the top-level (not the same as destination!) URL. See > the links above for details. > > That equally impacts resumption and any hypothetical deployment of cached > info. So, yes, within those same bounds, a browser could deploy cached > info. Whether it's useful depends on whether there are many cases where > resumption wouldn't work, but cached info would. (E.g. because resumption > has different security properties than cached info.) The big difference is that tickets generally should be valid only for a day or two, while cached info, just like cookies, can be valid for many months if not years. Now, a privacy focused user may decide to clear the cookies and cached info daily, while others may prefer the slightly improved performance on first visit after a week or month break. > >> It also completely ignores the encrypted client hello >> > > ECH helps with outside observers correlating your connections, but it > doesn't do anything about the server correlating connections. In the > context of correlation boundaries within a web browser, we care about the > latter too. How's that different from cookies? Which don't correlate, but cryptographically prove previous visit? >> Browser doesn't have to cache the certs since the beginning of time to be >> of benefit, a few hours or even just current boot would be enough: >> >> 1. if it's a page visited once then all the tracking cookies >> and javascript >>will be an order of magnitude larger download anyway >> 2. if it's a page visited many times, then optimising for the subsequent >>connections is of higher benefit anyway >> > > I don't think that's quite the right dichotomy. There are plenty of reasons > to optimize for the first connection, time to first bytes, etc. Indeed, > this WG did just that with False Start and TLS 1.3 itself. (Prior to those, > TLS 1.2 was 2-RTT for the first connection and 1-RTT for
Re: [TLS] Merkle Tree Certificates
On Fri, Mar 10, 2023 at 05:09:10PM -0500, David Benjamin wrote: > > 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. > > Thoughts? We're very eager to get feedback on this. Some quick comments / ideas: - I think it would be easier for subscribers to get inclusion proofs from transparency service than certificate authority. This is because issuance is heavily asynchronous, whereas most servers assume ACME is essentially synchronous. If certificates are canonicalized (this is mostly matter of ensuring the names are always sorted), this could be endpoint to download known inclusion proofs by certificate hash. Or maybe even have both, and subscribers can use whichever is more convinient. - I don't think there are any sane uses for >64kB claims, so the claim_info length could be shortened to 16 bits. I don't see rule for how claims are sorted within each type, only how different types are sorted. - If each claim was in its own Claim, then one could maybe even shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and dns/dns_wildcard. This could also simplify sorting: Sort by type, lexicographic sort by claim contents. - I don't think anybody is going to use signatures with >64kB keys, so subject_info length could be shortened to 16 bits. - What does it mean that in this document the hash is always SHA-256? - Apparently issuer id is limited to 32 octets. This could be noted in the definition. - I think it would be easier if lifetime was expressed in batch durations. Then one would not need window size, and especially not handle lifetime / batch_duration not being an integer! - The root hash being dependent on issuer and batch number iff there are multiple assertions looks very odd. Empty assertion list might be special. But this also happens for one assertion. - I think LabeledWindow should add 64 spaces in front, so it reuses the TLS 1.3 signature format. This reduces risks of cross-protocol attack if the key gets reused anyway (despite there being MUST NOT requirement). - Is there reason for type of trust_anchor_data to vary by proof_type? Why not always have MerkleTreeTrustAnchor there? - And proof_data length field should probably be 16 bits. I don't think proof_data will ever exceed 8kB. - For type-independent expiry info to be helpful, this must be somehow plumbed to the TLS server. - Even if ACME itself allows for long processing delays, many (most?) ACME clients do not. - Multiple orders from single newOrder or multiple certificates in single order sounds like it would break assumption made in ACME rather badly, and thus recipe for trouble. - Isn't cert_type deprecated? - "We may need to define a third one.", you men fourth one? - I think the uniform certificate format is already a requirement in TLS 1.3. And OpenPGP format is banned in TLS 1.3 anyway. So parsing to extension blocks without knowing certificate type is no problem. > 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 -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote: > > > > Unpopular pages are much more likely to deploy a solution that > > doesn't require a parallel CA infrastructure and a cryptographer > > on staff. I don't think the server-side deployment difficulties with this have anything to do with parallel CA infrastructure or admins having to understand cryptography. > CAs, TLS libraries, certbot, and browsers would need to make changes, > but I think we can deploy this without webservers or relying parties > having to make any changes if they're already using an ACME client > except upgrading their dependencies, which they would need to do > anyway to get plain X.509 PQ certs. I don't agree. I think deploying this is much much harder than deploying X.509 PQ certificates. X.509 PQ certificates are mostly dependency update. This looks to require some nontrivial configuration work that can not be done completely automatically. And then in present form, this could be extremely painful for ACME clients to implement (on level of complete rewrite for many). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
> > Unpopular pages are much more likely to deploy a solution that doesn't > require > a parallel CA infrastructure and a cryptographer on staff. > CAs, TLS libraries, certbot, and browsers would need to make changes, but I think we can deploy this without webservers or relying parties having to make any changes if they're already using an ACME client except upgrading their dependencies, which they would need to do anyway to get plain X.509 PQ certs. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote: On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: 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 ... https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md and https://github.com/privacycg/storage-partitioning. Sorry, but as long as the browsers are willing to perform session resumption I'm not buying the "cached info is a privacy problem". I'm not seeing where this quote comes from. I said it had analogous properties to resumption, not that it was a privacy problem in the absolute. I meant it as a summary not as a quote. The privacy properties of resumption and cached info on the situation. If you were okay correlating the two connections, both are okay in this regard. If not, then no. rfc8446bis discusses this: https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#appendix-C.4 In browsers, the correlation boundaries (across *all* state, not just TLS) were once browsing-profile-wide, but they're shifting to this notion of "site". I won't bore the list with the web's security model, but roughly the domain part of the top-level (not the same as destination!) URL. See the links above for details. That equally impacts resumption and any hypothetical deployment of cached info. So, yes, within those same bounds, a browser could deploy cached info. Whether it's useful depends on whether there are many cases where resumption wouldn't work, but cached info would. (E.g. because resumption has different security properties than cached info.) The big difference is that tickets generally should be valid only for a day or two, while cached info, just like cookies, can be valid for many months if not years. Now, a privacy focused user may decide to clear the cookies and cached info daily, while others may prefer the slightly improved performance on first visit after a week or month break. It also completely ignores the encrypted client hello ECH helps with outside observers correlating your connections, but it doesn't do anything about the server correlating connections. In the context of correlation boundaries within a web browser, we care about the latter too. How's that different from cookies? Which don't correlate, but cryptographically prove previous visit? Browser doesn't have to cache the certs since the beginning of time to be of benefit, a few hours or even just current boot would be enough: 1. if it's a page visited once then all the tracking cookies and javascript will be an order of magnitude larger download anyway 2. if it's a page visited many times, then optimising for the subsequent connections is of higher benefit anyway I don't think that's quite the right dichotomy. There are plenty of reasons to optimize for the first connection, time to first bytes, etc. Indeed, this WG did just that with False Start and TLS 1.3 itself. (Prior to those, TLS 1.2 was 2-RTT for the first connection and 1-RTT for resumption.) In my opinion time to first byte is a metric that's popular because it's easy to measure, not because it's representative. Feel free to point me to double blind studies with representative sample sizes showing otherwise. Yes, reducing round-trips is important as latency of connection is not correlated with bandwidth available. But when a simple page is a megabyte of data, and anything non trivial is multiple megabytes, looking at when the first byte arrives it is completely missing the bigger picture. Especially when users are trained to not interact with the page until it fully loads (2018 Hawaii missile alert joke explanation): https://gfycat.com/queasygrandiriomotecat Neither cached data nor Merkle tree certificates reduce round-trips I suspect a caching for a few hours would not justify cached info because you may as well use resumption at that point. 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. it does depend on complex code instead, that effectively duplicates the functionality of existing code 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, ... web browser could get a list of most commonly accessed pages/cert pairs, randomised to some degree by addition of not commonly accessed pages to hide if the connection is new or not, and make inference about previous visits worthless True, we could preload cached info for a global list of
Re: [TLS] Merkle Tree Certificates
Thx David. The spirit of the draft is clearer now. ACK about the miscalculated signature. I was counting the sig in the signed window, but indeed that does not take place with every connection. I think I understand your point about delegating trust. You basically say that if we could have an accurate picture of all ICAs at the RP we would be doing the same thing already. And the way you address the problem in this draft is by introducing the window within which you can rest assured you have the accurate picture of all certs. The non-updated RP is an issue that can’t be neglected (your draft addresses it with the time window). Let’s say we assumed RPs are up-to-date, and the ones that are not can retry without assuming an accurate ICA picture. How bad is having a non-updated RP retry? Is the problem keeping a connection state issue as someone had mentioned before? Another operational question: So this draft would work for ACME issued certs where the client can acquire the tree structure from the Merkle Tree CA which tracks ACME certs. But if you generalized this, wouldn’t that mean that either the RP needs to keep track and negotiate tree roots from multiple Merkle Tree CAs or a central Merkle Tree CA needs to aggregate all kinds of issued certs from CT or somewhere else? Another random comment: The tree version approach resembles the CA dictionary approach of cTLS. You basically have snapshots of the delegated trust book and if the peer recognizes it then you no longer need to establish trust. From: David Benjamin Sent: Monday, March 20, 2023 2:43 PM To: Kampanakis, Panos 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. Hi Panos, > - 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? I think you misunderstood my comments on the ICA suppression draft. :-) Most browsers can be kept mostly up-to-date, and I agree that is an opportunity to reduce sizes for most connections, including addressing ICAs. The key word here is "most". The challenge isn't keeping most RPs up-to-date, but addressing the remaining out-of-date RPs. My feedback was on how the draft handled this. It uses something time-based and makes implicit assumptions about the structure of the PKI. This document instead tries to have a more robust negotiation scheme. I also think this is better thought of as a trust agility problem, and it's a missed opportunity to not address that. More on this below. I also agree with [0]. X.509 has grown to be a pretty poor fit for TLS and HTTPS, and led to a slew of complexity, deployment problems, and security problems. The PQ transition, and things we do motivated by PQ's unique constraints, are a good place to rethink what parts of X.509 do and don't still make sense. This draft doesn't directly address this---it's not, on its own, a replacement and can coexist either X.509 or a non-X.509 mechanism---but I think the certificate negotiation and deployment ideas are worth exploring for that space. [0] https://mailarchive.ietf.org/arch/msg/pqc/Q8GDQPTsmhOIblYECcaEMIwRhP0/ > - To make this work for WebPKI, would the Transparency Service need to fetch > from all WebPKI issuing CAs and update them every hour? Almost. This document describes a new kind of CA. X.509 CAs and Merkle Tree CAs are distinct roles, though having some entities operate both kinds of CAs would be a natural deployment strategy. So, to clarify, yes, the TS would need to fetch from all trusted Merkle Tree CAs every hour. It would not need to fetch from CAs for other mechanisms, such as existing X.509 CAs. > - CAs would also need to publish their Merkle tree logs similarly to CT, > right? Merkle Tree CAs would need to publish some state described in sections 5.2 and 8. This document doesn't affect existing X.509 CAs. The new state is similar to CT in that it is a Merkle Tree and aims to provide a transparency property. It differs from CT in that: - Rather than appending to a single tree, with consistency proofs, each batch forms an independent tree. The tradeoffs we make reduce the number of valid trees enough that there's no need to link them together into a larger structure to optimize consistency checks. - CT logs attest that something was logged. By putting an assertion in a tree and signing the root, Merkle Tree CAs are certifying the assertions themselves. - CT logs are operated separately from X.509 CAs. In this design, the Merkle Tree CA logs its own assertions, and the TS is just a mirror of
Re: [TLS] Merkle Tree Certificates
akis, Panos > 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 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 > >&g
Re: [TLS] Merkle Tree Certificates
On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: 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. Sorry, but as long as the browsers are willing to perform session resumption I'm not buying the "cached info is a privacy problem". It also completely ignores the encrypted client hello Browser doesn't have to cache the certs since the beginning of time to be of benefit, a few hours or even just current boot would be enough: 1. if it's a page visited once then all the tracking cookies and javascript will be an order of magnitude larger download anyway 2. if it's a page visited many times, then optimising for the subsequent connections is of higher benefit anyway 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. it does depend on complex code instead, that effectively duplicates the functionality of existing code 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. web browser could get a list of most commonly accessed pages/cert pairs, randomised to some degree by addition of not commonly accessed pages to hide if the connection is new or not, and make inference about previous visits worthless On Tue, Mar 14, 2023 at 9:46 AM Kampanakis, Panos 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 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 (t
Re: [TLS] Merkle Tree Certificates
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 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 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 a
Re: [TLS] Merkle Tree Certificates
re 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 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
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
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 sign
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.
Re: [TLS] Merkle Tree Certificates
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-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 -- 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
Re: [TLS] Merkle Tree Certificates
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.) - I do think the trust_anchors extension values might be better off as e.g. truncated hashes of public keys or something like that. - 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 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 OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Merkle Tree Certificates
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-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
