> Can you say what the motivation is for being "fully post-quantum" rather than hybrid?
Sure: in the broad scope, hybrid introduces complexity in the short-term that we would like to move off of in the long-term - for TLS 1.3 key agreement this is not the worst thing in the world and we can afford it, but hybrid is by design a hedge, and theoretically a temporary one. In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> currently are a big 'maybe' at best for 'hybrid solutions', and the timetables for compliant browsers, servers, and services are to exclusively use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be demand for pure ML-KEM key agreement, not hybrid (with no questions that come along with it of whether it's actually allowed or not). Relatedly, the currently adopted -hybrid-design <https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html> outlines several combinations of ECDH and KEM, and allows computing the ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM share, but there is no equivalent for just using a KEM on its own, and computing its shared secret once and advertising it as both standalone and in a hybrid share. So I think defining these standalone ML-KEM `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design. On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla <e...@rtfm.com> wrote: > Deirdre, thanks for submitting this. Can you say what the motivation is > for being "fully post-quantum" rather than hybrid? > > Thanks, > -Ekr > > > > On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly <durumcrustu...@gmail.com> > wrote: > >> I have uploaded a preliminary version of ML-KEM for TLS 1.3 >> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> >> and have a more fleshed out >> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to >> be uploaded when datatracker opens. It is a straightforward new >> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a >> very similar style to -hybrid-design >> <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. >> >> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 >> compatible) ready to go when users are ready to use them. >> >> Cheers, >> Deirdre >> _______________________________________________ >> 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
