I support adoption of this document. On Tue, 26 Sept 2023 at 20:46, 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
