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
