Re: [TLS] ML-KEM key agreement for TLS 1.3

> 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 <ekr@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 <durumcrustulum@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
>>
>