[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/tls13-spec (+0/-1/đź’¬2) 1 issues received 2 new comments: - #1359 Should x25519 be made MTI? (2 by ekr, legna37) https://github.com/tlswg/tls13-spec/issues/1359 1 issues closed: - Should x25519 be made MTI? https://github.com/tlswg/tls13-spec/issues/1359 Pull requests - * tlswg/draft-ietf-tls-esni (+1/-4/đź’¬1) 1 pull requests submitted: - Update the IANA considerations text to match our other TLS policies. (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/627 1 pull requests received 1 new comments: - #625 Remove extraneous registry reference (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/625 4 pull requests merged: - Remove extraneous registry reference https://github.com/tlswg/draft-ietf-tls-esni/pull/625 - Intro: Tweak grammar to improve flow https://github.com/tlswg/draft-ietf-tls-esni/pull/622 - remove disclaimer https://github.com/tlswg/draft-ietf-tls-esni/pull/623 - remove reference to draft 8 https://github.com/tlswg/draft-ietf-tls-esni/pull/624 * tlswg/tls13-spec (+0/-0/đź’¬2) 1 pull requests received 2 new comments: - #1360 X25519 MTI (2 by ekr, seanturner) https://github.com/tlswg/tls13-spec/pull/1360 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
[TLS] I-D Action: draft-ietf-tls-esni-22.txt
Internet-Draft draft-ietf-tls-esni-22.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: TLS Encrypted Client Hello Authors: Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Name:draft-ietf-tls-esni-22.txt Pages: 52 Dates: 2024-09-15 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-esni-22 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-ietf-tls-key-share-prediction next steps
Thx Adrian for the reaction. > There is a considerable difference between loading large amounts of data for > a single site, which is a decision that is controllable by a site, and adding > a fixed amount of latency to _all_ connections to all sites to defend against > a computer that does not exist [3]. Fair. And draft-ietf-tls-key-share-prediction tries to address that. I like the draft. Btw, I have some disagreements to your “PQC Signatures damn too big” blog referenced in [3], but these are more or less similar to the ones I am sharing below. > Adding Kyber to the TLS handshake increased TLS handshake latency by 4% on > desktop [1] and 9% on Android at P50, and considerably higher at P95. In > general, Cloudflare found that every 1K of additional data added to the > server response caused median HTTPS handshake latency increase by around 1.5% > [2]. I have seen these arguments, but I am still skeptical. Your points focus on the TLS handshake which is not necessarily directly tied to Web experience. According to https://firefox-source-docs.mozilla.org/testing/perfdocs/perf-sheriffing.html , even the 4% (>2%) regression for Desktops would be unacceptable. So, why is 4% in the handshake acceptable, but 9% is not? If I am sending 100KB of data over the conn, 1 extra packet in the CH will not matter even for these mobile clients. We tried to make the point in https://www.ndss-symposium.org/ndss-paper/auto-draft-484/ . Ideally we should have proven it by measuring web metrics too (other than just the TTLB) but that requires more work. I am arguing that 5% or 10% or even 20% of TLS handshake slowdown does not equate to the same slowdown in the CrUX / web metrics. For example, the TLS handshake should not affect the INP or CLS metrics at all. The LCP or the FCP will not be affected be an extra packet if the server sends 50+ packets per connection. https://httparchive.org/reports/state-of-the-web says that each mobile connection transfers about 200KB. This means 150+ packets. Will an extra CH packet really show up in this connection’s performance impact? I doubt it. Another data point, https://httparchive.org/reports/loading-speed#fcp says that the median FCP and TTI for mobile is 3 and 16 seconds respectively. Will an extra packet in the CH really affect the multisecond FCP or TTI even in a slow connection at 1Kbps? That is questionable as well. So, respectfully, is your assertion that ML-KEM768 will have noticeable impact for mobile based on measurable web metric data, or is it just based on an intuition which is focusing on the TLS handshake and could be overestimating the impact on real web metrics? From: David Adrian Sent: Thursday, September 12, 2024 11:26 PM To: Kampanakis, Panos Cc: David Benjamin ; Subject: RE: [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-prediction next steps 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. > Any numbers you have to showcase the regression and the relevant affected web > metrics? Adding Kyber to the TLS handshake increased TLS handshake latency by 4% on desktop [1] and 9% on Android at P50, and considerably higher at P95. In general, Cloudflare found that every 1K of additional data added to the server response caused median HTTPS handshake latency increase by around 1.5% [2]. > I have seen this claim before and, respectfully, I don’t fully buy it. A > mobile client that suffers with two packet CHs is probably already crawling > for hundreds of KBs of web content per conn. There is a considerable difference between loading large amounts of data for a single site, which is a decision that is controllable by a site, and adding a fixed amount of latency to _all_ connections to all sites to defend against a computer that does not exist [3]. [1]: https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html [2]: https://blog.cloudflare.com/pq-2024/ [3]: https://dadrian.io/blog/posts/pqc-not-plaintext/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: draft-ietf-tls-key-share-prediction next steps
On Wed, Sep 11, 2024 at 12:41 AM John Mattsson wrote: > "To avoid downgrade attacks, the client MUST continue to send its full > preferences in the supported_groups extension." > > > > I don't think sending full preferences is a requirement in RFC 8446. As > far as I can see there is no normative text in RFC 8446 forbidding the > client to change the "supported_groups" extension based on unauthorized > data such as the domain name, IP address, etc. > > > > I think RFC 8446 should be update to state: > > > > The client MUST NOT change the content of the "supported_groups" extension > based on unauthenticated information. > > > > > > > > "DNS responses are unauthenticated in many deployments." > > > > I think the draft should describe the two cases "authenticated DNS" and > "unauthenticated > DNS" separately. The security considerations are very different. > > > > > > > > I think the security considerations are way too optimistic and need major > work. > > > > "To avoid downgrade attacks, the client MUST continue to send its full > preferences in the supported_groups extension." > > "it is safe for clients to admit attacker control over the set of named > groups preferred in key_share, provided supported_groups always reflects > the true client preference." > > > > This relies on servers ignoring performance and always chosing security. > My understanding is that there is nothing in RFC 8446 saying that servers > should behave like this. I think the only reasonable assumption in case of > unauthenticated DNS is that the weakest group supported by the client will > be used. This is problematic. > > > > If a server is not doing point validation on P-256 (which we know happens), > an attacker can find the private key. As TLS key shares unfortunatly are not > ephemeral (TLS 1.3 allows reuse), an attacker can downgrade a real > connection from x25519 to P-256 (which is unfortunatly MTI) and then > completely compromise the connection with the key share private key it > got from earlier connections with the server. > Hmmm... Isn't the correct statement here that if the server; 1. Reuses keys 2. Does not do point validation Then the attacker can compromise one key share and attack future connections that use the affected key? If the server does not reuse keys, then this attack doesn't work regardless of TLS not prohibiting reuse Ekr > > Cheers, > > John > > > > *From: *David Benjamin > *Date: *Tuesday, 10 September 2024 at 23:41 > *To: * > *Subject: *[TLS] draft-ietf-tls-key-share-prediction next steps > > Hi all, > > > > Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's > awkwardness around key share prediction is becoming starkly visible. (It is > difficult for clients to efficiently offer both Kyber and ML-KEM, but a > hard transition loses PQ coverage for some clients. Kyber was a draft > standard, just deployed by early adopters, so while not ideal, I think the > hard transition is not the end of the world. ML-KEM is expected to be > durable, so a coverage-interrupting transition to FancyNewKEM *would* be > a problem.) > > > > We adopted draft-ietf-tls-key-share-prediction in June to address this. > There hasn't been a whole lot to do on it since. I've cut a new draft, > draft-ietf-tls-key-share-prediction-01, with some very minor changes that > were queued up in GitHub. I'd like to sort out next steps and move forward. > > > > Beyond that, there are a couple of minor issues in the issue tracker. I > don't believe either of these need to block getting a codepoint. > > https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless > folks think otherwise, I plan to just leave this alone and close this > > https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks > think otherwise, I plan to just leave this alone and not require the > receiver to check > > > > Finally, there's the question of downgrade protection: > > https://github.com/tlswg/tls-key-share-prediction/issues/11 > > > > For some background if folks have forgotten, the original key share > prediction draft included a ton of complexity to accommodate existing > server behavior that would preferentially pick groups out of key_share even > if an otherwise more preferred group was in supported_groups. Depending on > what the server was trying to do there, this could be perfectly fine (if > the server believes the groups are comparable in security) or a downgrade > risk (if the server actually believed they were in different security > classes---PQ vs classical---but implemented a key_share-first selection > algorithm anyway). Pre-adoption, my original draft took the position that > it was ambiguous and we cannot safely assume the server knew what it was > doing. It designed a scheme to clarify the semantics going forward and use > codepoints to ratchet in whether the server implemented the new semantics. > > > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-pr
