Yup, that's right! (Ah yeah, it was confusing to talk about key shares reflecting preferences because we might be talking about the relative order or which were included or omitted. I was thinking the latter since the relative order already comes from supported_groups. I.e. I was thinking of the key_share order as just a syntactic restriction.)
On Mon, Nov 6, 2023, 05:55 Eric Rescorla <e...@rtfm.com> wrote: > Hi David, > > Thanks for posting this and for the discussion on the list. > > Before commenting on this proposal, I'd like to make sure we're all > on the same page about the situation. > > > # Background > > 1. RFC 8446 states that both supported_groups and key_shares > are in client's preference order but doesn't say what it > means for a value to be omitted from key_shares. > > When sent by the client, the "supported_groups" extension indicates > the named groups which the client supports for key exchange, ordered > from most preferred to least preferred. > > ... > > client_shares: A list of offered KeyShareEntry values in descending > order of client preference. > > 2. Some clients only send a subset of their supported groups in key > shares, either to save space/computation or because they are > concerned about compatibility. > > 3. Some servers negotiate by picking the most preferred key_share > that is present rather than the most preferred common group in > supported groups. > > > When we combine (2) and (3), the result is that the server may > choose a group which is less preferred by both the client and > server because it is included in the key_shares whereas the > more preferred group is not. > > > # Downgrade > > The draft here talks about there being a downgrade issue. ISTM > that there are two things going on here. > > 1. If the client chooses its key_shares based solely on authenticated > signals, or, as is presently common, consistently for every server, > then the server may choose a suboptimal combination (from the perspective > of group selection, though not from the perspective of latency), but > the attacker cannot influence this selection. > > 2. If the client chooses its key_shares based on unauthenticated > signals, such as DNS or falling back on apparent network error > (e.g., due to apparent intolerance of large CH), then the attacker > can exploit the behavior described in (3) to downgrade the selected > groups. > > > Is this a reasonably accurate summary of the situation? > > -Ekr > > > > > On Tue, Sep 26, 2023 at 9:46 AM David Benjamin <david...@chromium.org> > wrote: > >> Hi all, >> >> A while back, we discussed using a DNS hint to predict key shares and >> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In >> thinking through post-quantum KEMs and the various transitions we'll have >> in the future, I realized we actually need to address those downgrade >> issues now. I've published a draft below which is my attempt at resolving >> this. >> >> We don't need a DNS hint for the *current* PQ transition—most TLS >> ecosystems should stick to the one preferred option, and then clients can >> predict that one and move on. However, I think we need to lay the >> groundwork for it now. If today's round of PQ supported groups cannot be >> marked "prediction-safe" (see document for what I mean by that), >> transitioning to the *next* PQ KEM (e.g. if someone someday comes up >> with a smaller one that we're still confident in!) will be extremely >> difficult without introducing downgrades. >> >> Thoughts? >> >> David >> >> ---------- Forwarded message --------- >> From: <internet-dra...@ietf.org> >> Date: Mon, Sep 25, 2023 at 6:56 PM >> Subject: New Version Notification for >> draft-davidben-tls-key-share-prediction-00.txt >> To: David Benjamin <david...@google.com> >> >> >> A new version of Internet-Draft >> draft-davidben-tls-key-share-prediction-00.txt >> has been successfully submitted by David Benjamin and posted to the >> IETF repository. >> >> Name: draft-davidben-tls-key-share-prediction >> Revision: 00 >> Title: TLS Key Share Prediction >> Date: 2023-09-25 >> Group: Individual Submission >> Pages: 11 >> URL: >> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ >> HTML: >> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction >> >> >> Abstract: >> >> This document clarifies an ambiguity in the TLS 1.3 key share >> selection, to avoid a downgrade when server assumptions do not match >> client behavior. It additionally defines a mechanism for servers to >> communicate key share preferences in DNS. Clients may use this >> information to reduce TLS handshake round-trips. >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
