Filippo Valsorda wrote: >Third, we learned to make key shares always ephemeral which makes invalid >curve attacks irrelevant.
Have we? TLS 1.3 key shares are semi-static and may be reused an unlimited number of times. IKEv2 and (D)TLS 1.3 are doing quite a lot of questionable optimizations such as reuse of key shares, sending external PSK identifiers in cleartext, allowing replay protection to be turned off, and allowing symmetric key exchange instead of ECDHE. That TLS 1.3 has such high reputation makes it hard to argue against. As a result of TLS 1.3 marking psk_ke as RECOMMENDED, 3GPP ended up allowing it again. 3GPP had previously required ECDHE in TLS 1.2. I like that the CNSA RFCs provides additional hardening. That RFC 9206 states: "IKEv2 allows for the reuse of Diffie-Hellman private keys; see Section 2.12 of [RFC7296]. However, there are security concerns related to this practice. Section 5.6.3.3 of [SP80056A] states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of [SP80056A] states that any shared secret derived from key establishment MUST be destroyed (zeroized) immediately after its use. CNSA-compliant IPsec systems MUST follow the mandates in [SP80056A]." allowed me to forbid key reuse of ephemeral keys when IKEv2 is used in 3GPP. 3GPP already forbids turning off replay protection. I hope that the CNSA 2.0 RFCs for TLS, X.509, IPsec, SSH etc., will forbid even more weak configurations that does not belong in high-security deployments. Cheers, John From: Filippo Valsorda <fili...@ml.filippo.io> Date: Sunday, 2 June 2024 at 23:03 To: tls@ietf.org <tls@ietf.org> Subject: [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<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 <d...@cr.yp.to<mailto:d...@cr.yp.to>>: 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&s=142.250.217.142&hideResults=on&ignoreMismatch=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&s=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 popular curve on the internet". ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
