[TLS]Re: TLS trust expressions and certificate_authorities
On Tue, Jun 11, 2024 at 02:36:50AM +0100, Stephen Farrell wrote: > > Hiya, > > On 11/06/2024 02:24, Devon O'Brien wrote: > > > > I realize there has been extensive discussion about trust expressions > > Just checking - does your mail amount to "we heard your well-intentioned > but misplaced opposition, but we're not (yet) for changing"? I think the main points were: - TLS 1.3 already defined an extension to perform trust anchor negotiation, but it is too size-inefficient to use in practical usecases. - The goal of Trust Expressions is to have trust anchor negotiation that supports practical usecases of trust anchor negotiation with practical message size. - If size was no limitation (including the hard 64kB limit), then the existing extension could do everything Trust Expressions does, and more. - There could be very different way of compressing down the the trust anchor information from TLS client to server than what is presently in the draft. (However, I don't think anyone has come up with anything that could be competitive with what's in the draft now.) -Ilari ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
Hi Devon, I'm a bit disappointed in how you've characterized the earlier discussion, but I appreciate the attempt to move the conversation on to new technical ground. I previously started a thread on the problems with the proposed uses of Trust Expressions for PQC-transition [1] in a similar effort to move the conversation on. It would be good to see a response from the TE authors to that thread. Focusing on the actual draft text, the TLS trust expressions extension does not represent any kind of major paradigm shift, primarily due to its strong similarity to the existing certificate_authorities TLS extension. [...] There is no fundamental capability offered by trust expressions that isn’t already available by certificate_authorities. I think the above captures the main thrust of your argument in this thread, but it seems like quite a flawed analysis. If T.E. does not offer any new capabilities over certificate_authorities, then there is no point in standardizing it at all. Conversely, arguments that T.E. is a much more effective mechanism for deploying trust negotiation than certificate_authorities undermines the claim that T.E. doesn't introduce new risks that merit discussion. In terms of the differences between the existing certificate_authorities extension and Trust Expressions, I want to enumerate a few: Firstly, certificate_authorities is impractical at any kind of scale because it requires listing the distinguished name of every CA in the ClientHello (as you noted). This makes the size blowup is a huge impediment to actually using it for anything other than in a private PKI setting e.g. for indicating which client_certs a server would like to see. Secondly, certificate_authorities is very poorly supported today. TLS libraries typically ignore it e.g. OpenSSL requires custom callbacks to integrate it [2] - I couldn't find anything actually calling this function. Neither BoringSSL nor NSS support it in ClientHellos as far as can tell. Thirdly, certificate_authorities doesn't have any of the machinery necessary to orchestrate deploying it. Trust Expressions envisions ACME / TLS Servers implementations and CAs cooperating to distribute these trust labels to subscribers without requiring them to do any configuration themselves. Trust Expressions proposes to solve all of these drawbacks with certificate_authorities. The first is achieved by replacing the long list of distinguished names with a single identifier. The second is to ship support across servers and clients and make sure it is well exercised and indeed required. The third is to ensure that CAs can deliver multiple certificate chains to clients and that clients can transparently select between them based on a trust label. Consequently, T.E. does meaningfully change the calculus over certificate_authorities and so there are number of active threads discussing the risks of enabling trust negotiation and evaluating how it can be abused. Best, Dennis [1] https://mailarchive.ietf.org/arch/msg/tls/b_S23Rk0yvleoT3D0BGUTYFut80/ [2] https://github.com/openssl/openssl/issues/13453 On 11/06/2024 02:24, Devon O'Brien wrote: Hello, I realize there has been extensive discussion about trust expressions and a variety of hypothetical scenarios that some believe will play out should this draft get adopted and implemented. I would like to start this out with a clear statement: we hear these criticisms and are paying very close attention to them in order to help ensure this working group does not ship an irresponsible standard that causes any of the possible doomsday scenarios sketched out. The crux of this disagreement isn’t whether the outlined hypotheticals are bad; we are in strong agreement on this point. Rather, the disagreement is about the causality being posited between a rather incremental extension mechanism and these outcomes. Here, we authors strongly disagree with the points that have been repeatedly mentioned by some working group members and I hope that a more careful analysis of what trust expressions actually provide over the status quo will help the working group work past these disagreements. I believe that, in our excitement at the opportunities that a more agile web PKI can provide, we did ourselves and the broader community a disservice by leaning too far into some of the far-reaching possibilities we envision from a world with trust expressions. While we remain excited about a more agile and less-ossified PKI, it’s now clear that such emphasis caused the conversation to shift dramatically away from what the draft actually says and towards a variety of opinion-based arguments about what laws may be written by various world governments in the coming years and decades. Focusing on the actual draft text, the TLS trust expressions extension does not represent any kind of major paradigm shift, primarily due to its strong similarity to the existing cer
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
Hi Watson, Ilari, Watson wrote: Wait, I don't think the example's quite right (or maybe I'm just confused). How can two intermediates sign the "same" leaf? Or is the idea that we have L1' and L1 X509 Certificates with the same public key presented in the chain but signed by different intermediates, and the verifier figures out which one to use for the key exchange. (Yes, this is really nitpicky, but there is a distinction between keys and certs here that matters when counting bytes). Also the intermediates aren't the roots, and I don't think we're relaxing that rule for purposes of this discussion. Yes, the L1, M1 and N1 are public keys rather than certificates in the example I sketched. I was trying to explain more around how particular signatures impacted the overall security (or didn't), rather than the concrete use case in my initial message. So in case (3) we'd send L1, M1, M1' where M1' is signed by the root N1, and M1 by some PQ root. In case (2) I'm not sure how this would work: the end entity cert must be first, but you're requiring two different ones (with the same key), and I don't know a way to find M1 and N1 from that single cert. Yeah, in case (2) in practice we'd want two intermediate certificates rather than two end-entity certificates as I sketched in the first mail, but I felt having the extra identical signature hop in both examples might be confusing from the security perspective. Anyway your point remains valid: cross-signing doesn't hurt clients that only trust the new algorithm. :-) Just to make sure things are clear, I've laid out the certificate chains from my initial message again. We have a new PQC root X3, plus an existing classical root X2. *Option 1* We create a new PQC Public Key M1 and produce two intermediate certificates for this public key, over X2 and X3 and use them to produce: * L1 := User's Leaf key signed by M1. * F1 := M1 signed by X3 * H1 := M1 signed by X2 The certificate chain is then: L1 + F1 + H1. Benefits: * PQ Security for clients that have X3 * Classical Security and backwards compatibility for clients that only have X2 * Existing TLS Certificate Compression mechanisms like brotli will compress out the excess bytes (the repetition of M1) so overall the only size increase is the 32 byte ECDSA X2 signature. Drawback: Relies on Clients doing the bare minimum of chain building. Interestingly you can choose whether its PQ clients or classical clients that need the chain building support by deciding whether to send F1 or H1 first in the order. *Option 2 *We cross sign X3 with X2 and use that to build a single longer chain: * L1 := User's Leaf Key signed by M1 * F1 := M1 signed by X3 * X3' := X3 signed by X2. The certificate chain is then L1 + F1 + X3' Benefits: * PQ security for clients that have X3 * Classical Security and backwards compatibility for clients that only have X2 * No chain building support needed Drawback: You need Abridged Certs or AIA chasing (already deployed in Chrome) to avoid paying the byte cost of X3'. @Ilari - I think the size increase is much less than you might think, only 32 bytes for Option 1 and this is assuming no use of Abridged Certs, which would make either option completely free. Assuming we deployed Abridged Certs, then Option 2 has no size increase on today and does not need any path building support in clients. Best, Dennis ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
Hi Stephen, We added some text to the most recent draft that addresses some of the PKI dynamics that seem to underly the discussion. https://author-tools.ietf.org/iddiff?url1=draft-davidben-tls-trust-expr-02&url2=draft-davidben-tls-trust-expr-03&difftype=--html We've also been gradually updating the "explainer" with some discussion that didn't seem to fit in the draft, and will be updating it with some further discussion on alternatives and different scenarios when we've written all that up. https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md And, of course, we're always interested in considering feedback and changes, where they make sense. As with any other protocol work, I'm sure the final mechanism will evolve significantly over time as the discussion shifts to different parts of it. David On Mon, Jun 10, 2024 at 9:38 PM Stephen Farrell wrote: > > Hiya, > > On 11/06/2024 02:24, Devon O'Brien wrote: > > > > I realize there has been extensive discussion about trust expressions > > Just checking - does your mail amount to "we heard your well-intentioned > but misplaced opposition, but we're not (yet) for changing"? > > I'm not saying that's a bad position to take, but it's not clear from > your mail, which in some parts sounds like changes may be considered, > but in other parts doesn't. > > I do plan to re-read this stuff in the run-up to the next IETF so it'd > be good to have a sense of how the authors are considering the list > feedback, and of course, if changes are planned, reviewing newer text > would likely be more useful all around. > > Thanks, > S. > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
> > There will be an annoyingly large number of options on the PQ side---for > > example, for different security levels and for patent avoidance---and > > I'd expect a tricky discussion of which options to recommend for TLS. > I'm not sure I buy this premise. Currently there seems to be an > overwhelming convergence on ML-KEM768 for this job, with the one exception > being ML-KEM1024 being favored by the CNSA 2, but the latter also does not > recommend hybrids, leaving us with really only one choice for the PQ hybrid > for at least the medium term. Within ML-KEM, NSA isn't just favoring 1024, but _forbidding_ sizes below 1024: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF The document doesn't forbid hybrids; on the contrary, it states that "NSA may allow or require hybrid solutions due to protocol standards, product availability, or interoperability requirements". So there isn't a clear dividing line between what NSA is doing and what the TLS WG will end up considering. Other people have already brought up NSA's ML-KEM requirements in TLS discussions, and people who don't think NSA should have control over IETF can still understand NSA's position as communicating security concerns relevant to TLS decisions. This by itself looks to me like a much more tricky discussion than any TLS curve discussions! Apple has rolled out ML-KEM-1024 in another protocol: https://security.apple.com/blog/imessage-pq3/ Meanwhile Meta says, regarding TLS, that they're rolling out ML-KEM-768 and, for performance reasons (TFO packet size), also ML-KEM-512: https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/ Sounds like big deployments of all three ML-KEM sizes already (times different Kyber versions, but let's assume all the different versions switch to the final version of ML-KEM after NIST posts that, which should happen any day now), and at least some of the underlying rationales are certainly applicable to TLS. As for the patent problem, one can _hope_ that Yunlei Zhao is wrong in writing "Kyber is covered by our patents" in https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ but I haven't seen any public analysis of, e.g., their patent https://patents.google.com/patent/CN107566121A/en concluding that Kyber _isn't_ actually covered, never mind the question of how convincing such a public analysis would be. This is just one example of the patent minefield. > If the only reason for revisiting the current choices in recommended curves > is an expected large number of PQ options (or even just more than one PQ > option), it might make sense to have that discussion first. The PQ security issues, performance issues, further software issues, and patent issues look much more complicated than the curve issues, and include various issues that I'd expect to be resolved in CFRG. It's clear that a big wave of specific PQ proposals is coming to the TLS WG soon; this doesn't mean the wave is here yet, beyond some initial work such as draft-ietf-tls-hybrid-design. The curve situation is different. There's lots of experience now with the interactions between curve choices and TLS software (and hardware). The TLS WG doesn't have curve questions for CFRG. So the TLS WG can settle now what it's going to look for on the curve side of PQ hybrids. ---D. J. Bernstein ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
On Tue, Jun 11, 2024 at 3:25 AM Dennis Jackson wrote: > I think the above captures the main thrust of your argument in this > thread, but it seems like quite a flawed analysis. If T.E. does not offer > any new capabilities over certificate_authorities, then there is no point > in standardizing it at all. Conversely, arguments that T.E. is a much more > effective mechanism for deploying trust negotiation than > certificate_authorities undermines the claim that T.E. doesn't introduce > new risks that merit discussion. > This is a false dichotomy. TE offers an incremental improvement on certificate_authorities. > > In terms of the differences between the existing certificate_authorities > extension and Trust Expressions, I want to enumerate a few: > > Firstly, certificate_authorities is impractical at any kind of scale > because it requires listing the distinguished name of every CA in the > ClientHello (as you noted). This makes the size blowup is a huge impediment > to actually using it for anything other than in a private PKI setting e.g. > for indicating which client_certs a server would like to see. > > Secondly, certificate_authorities is very poorly supported today. TLS > libraries typically ignore it e.g. OpenSSL requires custom callbacks to > integrate it [2] - I couldn't find anything actually calling this function. > Neither BoringSSL nor NSS support it in ClientHellos as far as can tell. > > Thirdly, certificate_authorities doesn't have any of the machinery > necessary to orchestrate deploying it. Trust Expressions envisions ACME / > TLS Servers implementations and CAs cooperating to distribute these trust > labels to subscribers without requiring them to do any configuration > themselves. > > Trust Expressions proposes to solve all of these drawbacks with > certificate_authorities. The first is achieved by replacing the long list > of distinguished names with a single identifier. The second is to ship > support across servers and clients and make sure it is well exercised and > indeed required. The third is to ensure that CAs can deliver multiple > certificate chains to clients and that clients can transparently select > between them based on a trust label. > > Consequently, T.E. does meaningfully change the calculus over > certificate_authorities and so there are number of active threads > discussing the risks of enabling trust negotiation and evaluating how it > can be abused. > If Trust Expressions does meaningfully change the calculus compared to certificate_authorities, it does it in a way that lessens risk. The certificate_authorities extension doesn't scale support the legitimate use case of trust negotiation/advertisement that Trust Expressions supports, but this problem doesn't exist for certificate_authorities advertising a single government CA. In your first example of how certificate_authorities differs from Trust Expressions, you've given an example of how Trust Expressions is less risky than certificate_authorities. The complexity of deploying certificate_authorities for the government CA "risky" use case is much less than it is for Trust Expressions. The "risky" use case requires clients advertise the name of the CA, and it requires servers to be able to match a name in the certificate_authorities extension against one of its multiple certificates. This deployment has no machinery with CAs, ACME servers, or root programs publishing manifests. When you say certificate_authorities doesn't have any of the machinery necessary, that's because it doesn't need any such machinery, as Devon explained in point 4. In the "risky" use case, Trust Expressions requires the government to implement or compel more actions than it would with certificate_authorities. Starting with the clients, it would need to compel root programs to manage and publish an additional trust store manifest (or manage its own trust store manifest and compel advertisement of that as part of compelling trust). It would also need to have its CA (and the CA's ACME server) support the government trust store in its CertificatePropertyList. It looks like there's a lot more compulsion involved in this government-forced trust use case when the government uses Trust Expressions instead of certificate_authorities. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
