[TLS] draft-kwiatkowski-tls-ecdhe-mlkem at IETF 121
Hi, I just looked at the presentation from the TLS session. My views: - I think the order of P256 and MLKEM should be switched, irrespectively of NIST's current discussion. Even if NIST do not change their current specifications, I think long-term FIPS compliance is much more important then short-term FIPS compliance. - Don't touch X25519MLKEM768, not even the name. Just make it a rule that the name is in the opposite order. - I think the draft should be adopted - I think the draft should be standards track - I think all three code points should be RECOMMENDED=Y - I think the draft should update RFC8446bis to make X25519MLKEM768 MTI. I think IETF should send a clear message that TLS implementations should migrate to quantum-resistant key exchange asap. X25519MLKEM768 is already the de facto standard. At some point we need a quantum-resistant MTI and I don't see any other option than X25519MLKEM768 and I don’t see any reason to wait. Key exchange and signatures can be handled independently. Cheers, John ___ 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/-0/💬4) 3 issues received 4 new comments: - #630 Extraneous configurations MUST have invalid DNS names? (1 by seanturner) https://github.com/tlswg/draft-ietf-tls-esni/issues/630 - #629 Should we recommend how often to rotate keys? (2 by enygren, seanturner) https://github.com/tlswg/draft-ietf-tls-esni/issues/629 - #628 DNS issues from AD review. (1 by seanturner) https://github.com/tlswg/draft-ietf-tls-esni/issues/628 Pull requests - * tlswg/draft-ietf-tls-cert-abridge (+8/-0/💬0) 8 pull requests submitted: - Add a listing of certificates (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/33 - Update acknowledgements (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/32 - Describe server side footprint (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/31 - Adopt 0xab00 identifier from the experimental range (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/30 - Update benchmarks (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/29 - Remove old DISCUSS tags which have been migrated to issues. (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/28 - Require unrecognised identifiers to be decompression failures. (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/27 - Change Pass 2 to Brotli with no dictionary (by dennisjackson) https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/26 Repositories tracked by this digest: --- * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/dnssec-chain-extension * https://github.com/tlswg/draft-deprecate-obsolete-kex * https://github.com/tlswg/draft-ietf-tls-cert-abridge * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead * https://github.com/tlswg/draft-ietf-tls-ech-keylogfile * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-grease * https://github.com/tlswg/draft-ietf-tls-iana-registry-updates * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-svcb-ech * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/draft-ietf-tls-tls13-vectors * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/dtls-rrc * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/rfc4492bis * https://github.com/tlswg/rfc8447bis * https://github.com/tlswg/sniencryption * https://github.com/tlswg/sslkeylogfile * https://github.com/tlswg/sslv3-diediedie * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/tls-flags * https://github.com/tlswg/tls-key-share-prediction * https://github.com/tlswg/tls-key-update * https://github.com/tlswg/tls-record-limit * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/tls12-frozen * https://github.com/tlswg/tls13-pkcs1 * https://github.com/tlswg/tls13-rfc ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Bytes server -> client
> This vast difference between median and average indicates that a small > fraction of data-heavy connections skew the average. Hmmm. Why not describe this as "a large number of short sessions skew the median, making the median fail to reflect total data usage"? The total cost of all sessions is the _average_ cost per session times the number of sessions. The total cryptographic cost of all sessions is the average cryptographic cost per session times the number of sessions. Example: * A news site sends you a 20MB video in 1 big session, plus 99 tiny sessions each with 0.01MB. The total data it's sending is 21MB. * If you add 0.01MB to each session for crypto, then you're adding 1MB across the 100 sessions. That's not much compared to 21MB. * In terms of averages, the average data per session is 0.21MB, and you're adding 0.01MB on top of that. Same 1/21 ratio (although if you don't know the total number of sessions then you can't compare this to other expenditures). * The _median_ data per session is just 0.01MB. This is wildly misleading: it completely misses the big video, while incorrectly making the crypto sound as if it's doubling costs. To be clear, I do recommend looking at more of the distribution than just the average. Seeing variations opens up possibilities such as (1) being able to convince people to use stronger crypto for the longer sessions, and (2) batching the short sessions to reduce their overhead (not just for crypto), in cases where aggregate overhead is an issue. ---D. J. Bernstein ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem at IETF 121
On Sat, Nov 9, 2024, 1:34 AM John Mattsson wrote: > Hi, > > > > I just looked at the presentation from the TLS session. My views: > > > > - I think the order of P256 and MLKEM should be switched, irrespectively > of NIST's current discussion. Even if NIST do not change their current > specifications, I think long-term FIPS compliance is much more important > then short-term FIPS compliance. > > > If MLKEM is approved then X25519MLKEM768 would work. Yes this is a bit ugly but most devices can handle the extra code for both. - Don't touch X25519MLKEM768, not even the name. Just make it a rule that > the name is in the opposite order. > > > > - I think the draft should be adopted > > > > - I think the draft should be standards track > > > > - I think all three code points should be RECOMMENDED=Y > > > > - I think the draft should update RFC8446bis to make X25519MLKEM768 MTI. > I think IETF should send a clear message that TLS implementations should > migrate to quantum-resistant key exchange asap. X25519MLKEM768 is already > the de facto standard. At some point we need a quantum-resistant MTI and I > don't see any other option than X25519MLKEM768 and I don’t see any reason > to wait. Key exchange and signatures can be handled independently. > > > > Cheers, > > John > > > ___ > 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: Bytes server -> client
> > > > On average, around 15 million TLS connections are established with > > Cloudflare per second. Upgrading each to ML-DSA, would take > > 1.8Tbps, which is 0.6% of our current total network capacity. No > > problem so far. The question is how these extra bytes affect > > performance. > > Back in 2021, we ran a large-scale experiment to measure the > > impact of big post-quantum certificate chains on connections to > > Cloudflare’s network over the open Internet. There were two > > important results. First, we saw a steep increase in the rate of > > client and middlebox failures when we added more than 10kB to > > existing certificate chains. > > > Would you be willing to share some numbers around the increase in > failures? Details are in our 2021 blog post https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ > What do you think might've been the cause for increased > failures at clients and middleboxes? One hypothesis I have is > TLS-related DPI might allocate a certain buffer to capture the > handshake, which was now being crossed. > That could well be one cause. 16MB chains are allowed by the spec, but most TLS libraries reject shorter chains. Back in 2021 I saw that OpenSSL rejected chains longer than 106kB, and Go rejects them if they're longer than 64kB. That's still well above 13kB, but there could be middleboxes that picked a shorter buffer length. Note that this is problematic for those that only want to deploy a single certificate "chameleon hybrids". Best, Bas > > Regards, > > Raghu Saxena > > ___ > 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
