[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel
On Sun, Jun 2, 2024 at 10:17 AM Russ Housley wrote: > EKR: > > I agree with most of your points about the process, but I want to respond > to this paragraph in particular. > > Similarly here, if the WG feels that a change is sufficiently large to > require formal analysis then the WG -- and more specifically those who > want the work to move forward -- need to figure out how to get that > analysis done, though of course the triage panel or the broader > community might help facilitate if there is enough demand or interest > in the work. > > > There was no consensus call by the WG Chairs. During WG Last Call, a few > people asked for formal analysis, but others felt that the informal > analysis in the document was good enough. > Agreed. The WG now needs to make a determination if one is required (unsurprisingly I think the answer should be yes), but I agree that has not happened. Sorry if my message gave a different impression. I realize that we are quite purposefully embracing formal analysis. It is > a good thing. The number of people that have experience with the tools is > very small. If this is going to be successful enough to expand to other > protocols, then we need to find ways to expand the size of this group. > I agree. I am hoping that if we are successful with routine use of formal analysis with TLS this will make the path easier for other protocols. -Ekr ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
I expect X25519 to be the most commonly *selected *(as opposed to supported) TLS key exchange on the open Internet, due to browsers preferring it for its marginal performance benefit. This is not a popularity contest though and that's not the most useful metric for choosing the ECC component of a PQC hybrid. The most important performance consideration in TLS is avoiding Hello Retry Request round-trips due to the server supporting none of the client's key shares. Moreover, clients want to reuse the ECC component of the hybrid key share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, X25519+ML-KEM-768 so that the X25519 key generation can be reused). Given those goals, the important metric is server support. *We should indeed collect data on what are the most supported key exchanges server-side*, probably weighted by website or implementation popularity. (I expect X25519 and P-256 to have nearly equivalent support, maybe with some FIPS-related delta in favor of P-256.) I actually meant to bring this up, because as an implementer I also want to avoid proliferation of hybrid options, but *it would actually make my life much easier if the one universal hybrid (and/or default client key share) was P-256+ML-KEM-768*. The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by the CA/B Baseline Requirements. This is not changing soon. That means I am on the hook to carry an optimized and secure P-256 implementation no matter what. If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am *also *on the hook to carry an optimized and secure X25519 implementation. That's double the work, double the opportunity for mistakes, double the complexity, double the attack surface. If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 becomes much less important, and I can carry a simpler less efficient (e.g. without assembly) implementation for it, and focus my limited resources on P-256. P-256+ML-KEM-768 also has the added benefit of being FIPS 140 compliant today, without waiting for ML-KEM-768 modules to get certified (which can take years), speeding up PQC adoption in settings that—unfortunately—are constrained by FIPS 140. It also avoids divergence between regular and compliance modes, again reducing implementer workload and attack surface. For what it's worth, implementing P-256 these days is way easier than when X25519 was designed. First, Renes, Costello, and Batina published complete formulas for it in https://eprint.iacr.org/2015/1060 (although interestingly P-256 still has a red False in the "complete" column in version 2017.01.22 of https://safecurves.cr.yp.to, which maybe I am misinterpreting). Second, we have formally verified field implementation generators such as fiat-crypto. Third, we learned to make key shares always ephemeral which makes invalid curve attacks irrelevant. 2024-06-02 20:47 GMT+02:00 D. J. Bernstein : > Information about the popularity of specific cryptosystems plays a role > in decisions of what to standardize and deploy. I've been pointed to a > surprising statement (quoted below) regarding popularity of curves, in > particular in TLS handshakes. The statement is from one of the current > TLS co-chairs, a month before the co-chair appointment. I'm wondering > what data the statement is based on; the statement doesn't have a > description of the data sources, and the statement seems impossible to > reconcile with various public statements that have clear data sources. > > A specific reason that I'd like to resolve this is that I'm concerned > about the impact on post-quantum deployment. To explain: > >* We're failing to protect confidentiality of most user data against > future quantum attacks---but switching to a post-quantum system has > an unacceptably high chance of making security even worse. See > https://cr.yp.to/papers.html#qrcsp for how much has been broken. > >* The obvious path forward is to immediately roll out ECC+PQ hybrids, > as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701 > in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024, > X25519+kyber512 in > https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/, > etc. Then we're not making security worse, and _hopefully_ we're > making it better. > >* This still leaves the challenge of minimizing post-quantum risks. > That's hard enough without the combinatorial explosion of combining > each post-quantum option with a profusion of curves. Adding many > curve choices is the sort of thing that _sounds_ simple until you > start writing software, tests, etc. (I designed X25519 after > suffering through implementing an example of NSA/NIST ECDH; see > https://cr.yp.to/nistp224.html and the accompanying talks. NSA's > harder-to-implement approach to ECC also ends up
[TLS]Curve-popularity data?
Information about the popularity of specific cryptosystems plays a role in decisions of what to standardize and deploy. I've been pointed to a surprising statement (quoted below) regarding popularity of curves, in particular in TLS handshakes. The statement is from one of the current TLS co-chairs, a month before the co-chair appointment. I'm wondering what data the statement is based on; the statement doesn't have a description of the data sources, and the statement seems impossible to reconcile with various public statements that have clear data sources. A specific reason that I'd like to resolve this is that I'm concerned about the impact on post-quantum deployment. To explain: * We're failing to protect confidentiality of most user data against future quantum attacks---but switching to a post-quantum system has an unacceptably high chance of making security even worse. See https://cr.yp.to/papers.html#qrcsp for how much has been broken. * The obvious path forward is to immediately roll out ECC+PQ hybrids, as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701 in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024, X25519+kyber512 in https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/, etc. Then we're not making security worse, and _hopefully_ we're making it better. * This still leaves the challenge of minimizing post-quantum risks. That's hard enough without the combinatorial explosion of combining each post-quantum option with a profusion of curves. Adding many curve choices is the sort of thing that _sounds_ simple until you start writing software, tests, etc. (I designed X25519 after suffering through implementing an example of NSA/NIST ECDH; see https://cr.yp.to/nistp224.html and the accompanying talks. NSA's harder-to-implement approach to ECC also ends up more likely to fail later; see, e.g., https://blog.cr.yp.to/20191024-eddsa.html.) Here's the specific statement I'm asking about: P 256 is the most popular curve in the world besides the bitcoin curve. And I donât have head to head numbers, and the bitcoin curve is SEC P, but P 256 is most popular curve on the internet. So certificates, TLS, handshakes, all of that is like 70 plus percent negotiated with the P 256 curve. Last I heard, _certificates_ hadn't upgraded to allowing Ed25519 yet. My question is about the "handshake" claim, and more broadly about the "internet" and "world" claims. Examples of why I find the above TLS-handshake claim surprising: * https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ (2019) says that "the most commonly used key exchange algorithm (according to Cloudflare's data) is the non-quantum X25519". * https://blog.cloudflare.com/post-quantum-for-all/ (2022) says that "Almost every server supports the X25519 key-agreement and almost every client (98% today) sends a X25519 keyshare." * https://eprint.iacr.org/2023/734 recorded TLS connections from many different apps and noted that X25519 was used in "the vast majority of the recorded handshakes". * https://blog.cloudflare.com/pq-2024 says "Today almost all traffic is secured with X25519, a DiffieâHellman-style key agreement". * The handshake simulations in, e.g., https://www.ssllabs.com/ssltest/analyze.html?d=google.com=142.250.217.142=on=on show current browsers using X25519 (while showing older client software using P-256). Clicking on random servers listed on the same site also consistently shows X25519. To be clear, this isn't saying that _all_ handshakes are using X25519. NIST didn't manage to standardize Ed25519 until 2023, and still hasn't managed to standardize X25519, so probably it's not too hard to find servers that insist on P-256 for "FIPS compliance". I figured I'd be able to give easy examples of this by trying nist.gov and nsa.gov--- https://web.archive.org/web/20240602150722/https://www.ssllabs.com/ssltest/analyze.html?d=nist.gov=129.6.13.49 https://web.archive.org/web/20240602151119/https://www.ssllabs.com/ssltest/analyze.html?d=nsa.gov ---but it turns out that both of them end up using X25519, unless you're connecting to nsa.gov with a client that doesn't support TLS 1.3. More broadly, Nicolai Brown's pages https://ianix.com/pub/curve25519-deployment.html https://ianix.com/pub/ed25519-deployment.html include a long list of applications of X25519 and Ed25519. Spot-checks confirm the overall accuracy of the list, and find many applications where Curve25519 is the only curve, including big applications such as WhatsApp and WireGuard. I'm also aware of some applications where P-256 is the only option. I would guess that https://security.apple.com/blog/imessage-pq3/ is now the biggest P-256 application. But I don't know how one would reach a conclusion that "P 256 is most
[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel
On Sun, 2 Jun 2024, 19:17 Russ Housley, wrote: > EKR: > > I agree with most of your points about the process, but I want to respond > to this paragraph in particular. > > Similarly here, if the WG feels that a change is sufficiently large to > require formal analysis then the WG -- and more specifically those who > want the work to move forward -- need to figure out how to get that > analysis done, though of course the triage panel or the broader > community might help facilitate if there is enough demand or interest > in the work. > > > There was no consensus call by the WG Chairs. During WG Last Call, a few > people asked for formal analysis, but others felt that the informal > analysis in the document was good enough. > > I realize that we are quite purposefully embracing formal analysis. It is > a good thing. The number of people that have experience with the tools is > very small. If this is going to be successful enough to expand to other > protocols, then we need to find ways to expand the size of this group. > The group is probably large enough? > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel
EKR: I agree with most of your points about the process, but I want to respond to this paragraph in particular. > Similarly here, if the WG feels that a change is sufficiently large to > require formal analysis then the WG -- and more specifically those who > want the work to move forward -- need to figure out how to get that > analysis done, though of course the triage panel or the broader > community might help facilitate if there is enough demand or interest > in the work. There was no consensus call by the WG Chairs. During WG Last Call, a few people asked for formal analysis, but others felt that the informal analysis in the document was good enough. I realize that we are quite purposefully embracing formal analysis. It is a good thing. The number of people that have experience with the tools is very small. If this is going to be successful enough to expand to other protocols, then we need to find ways to expand the size of this group. Russ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-esni (+0/-1/0) 1 issues closed: - Mention that the server identity may be revealed by ServerHellp https://github.com/tlswg/draft-ietf-tls-esni/issues/612 Pull requests - * tlswg/draft-ietf-tls-esni (+2/-2/4) 2 pull requests submitted: - Don't retry from retry (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/616 - Explain about reused keyshares. Fixes #612 (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/615 3 pull requests received 4 new comments: - #616 Don't retry from retry (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/616 - #615 Explain about reused keyshares. Fixes #612 (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/615 - #609 Explain when clients can remember rejected ECH. Fixes #604 (2 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/609 2 pull requests merged: - Explain about reused keyshares. Fixes #612 https://github.com/tlswg/draft-ietf-tls-esni/pull/615 - Correct `ECHConfigList` length bounds https://github.com/tlswg/draft-ietf-tls-esni/pull/614 * tlswg/tls13-spec (+0/-1/1) 1 pull requests received 1 new comments: - #1354 Forbid the sender from sending duplicate supported groups entries. (1 by ekr) https://github.com/tlswg/tls13-spec/pull/1354 1 pull requests merged: - Update HTTP/1.1 ref https://github.com/tlswg/tls13-spec/pull/1350 Repositories tracked by this digest: --- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/external-psk-design-team ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
