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

[Eric Rescorla <[e-mail]>]

On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly <[e-mail]>
wrote:

> > 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.
>

My view is that this is likely to be the *very* long term.

I'm open to being persuaded, but at the moment, I don't think there is
anywhere near enough confidence in any of the PQ algorithms to confidently
use it standalone, which means we're going to see a lot of hybrid
deployment sooner rather than later. This also means that we're going to
have a long tail of clients and servers which only do hybrid and not
PQ-only, so that complexity is baked in for quite some time to come.


> 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).
>

I'm honestly not moved by this very much. IETF should form its own opinion
about the security of algorithms, not just take whatever opinions are
handed down from NIST. If that means that IETF doesn't standardize what
NIST wants, then NIST is free to register its own codepoints and try to
persuade implementors to take them.

So I think the question here should be focused on "what level of confidence
would IETF need to specify ML-KEM standalone at Proposed Standard with
Recommended=Y".

-Ekr


> 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-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>