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

[Eric Rescorla <[e-mail]>]

On Thu, Mar 7, 2024 at 1:47 AM Dennis Jackson <ietf=
[e-mail]> wrote:

> On 07/03/2024 03:57, Bas Westerbaan wrote:
>
> We think it's worth it now, but of course we're not going to keep hybrids
> around when the CRQC arrives.
>
> Sure, but for now we gain substantial security margin* against
> implementation mistakes, advances in cryptography, etc.
>
> On the perf/cost side, we're already making a large number of sub-optimal
> choices (use of SHA-3, use of Kyber in TLS rather than a CPA scheme,
> picking 768 over 512, etc), we can easily 'pay' for X25519 if you really
> wanted. I think if handshake cycles really mattered then we'd have shown
> RSA the door much more quickly [1].
>
> Best,
> Dennis
>
> * As in, actual security from combination of independent systems, not the
> mostly useless kind from using over-size primitives.
>
In a world where there is a CRQC, there are two distinct costs to
continuing to support hybrids:

1. The computational cost of actually doing X25519 (or whatever)
2. The software complexity cost of the code to do the hybrid and to
negotiate it.

>From the perspective of an implementation the computational cost scales
with the
number of handshakes it has to do with the hybrid rather than pure ML-KEM.
The complexity cost, however, is constant up to the point where you can
remove it
entirely. Because of the highly centralized structure of the TLS browser
and server
ecosystem, these timelines can be very different: it's relatively fast to
get to high
levels of deployment so that most handshakes are "new", but can be quite
slow
to eliminate the last "old-only" peers.

So, the question I have is whether having a code point for pure ML-KEM now
advances the project of deprecating hybrids at the point where the X25519
part
isn't doing anything meaningful (again, assuming that point eventually
comes).
My sense is that it largely does so if fielded implementations are willing
to do
pure-ML-KEM, because, as above, it's that quantity that dominates the
decision
of whether you can remove the hybrid code entirely. Personally, I'd still
be quite
uncomfortable with allowing pure ML-KEM negotiation in a major product. If
others
feel the same way, I'm not quite sure what it gets us, other than saving us
the
fairly small amount of specification effort of doing the pure version.

It's of course worth noting that a CRQC might be very far in the future and
we
might get better PQ algorithms by that point, in which case we'd never
deploy
pure ML-KEM.

-Ekr


> [1] https://blog.cloudflare.com/how-expensive-is-crypto-anyway
>
>
> Best,
>
>  Bas
>
> On Thu, Mar 7, 2024 at 1:56 AM Dennis Jackson <ietf=
> [e-mail]> wrote:
>
>> I'd like to understand the argument for why a transition back to single
>> schemes would be desirable.
>>
>> Having hybrids be the new standard seems to be a nice win for security
>> and pretty much negligible costs in terms of performance, complexity and
>> bandwidth (over single PQ schemes).
>>
>> On 07/03/2024 00:31, Watson Ladd wrote:
>> > On Wed, Mar 6, 2024, 10:48 AM Rob Sayre <[e-mail]> wrote:
>> >> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla <[e-mail]> wrote:
>> >>>
>> >>>
>> >>> 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.
>> >>
>> >> Also, the ship has sailed somewhat, right? Like Google Chrome,
>> Cloudflare, and Apple iMessage already have hybrids shipping (I'm sure
>> there many more, those are just really popular examples). The installed
>> base is already very big, and it will be around for a while, whatever the
>> IETF decides to do.
>> > People can drop support in browsers fairly easily especially for an
>> > experimental codepoint. It's essential that this happen: if everything
>> > we (in the communal sense) tried had to be supported in perpetuity, it
>> > would be a recipe for trying nothing.
>> >
>> >> thanks,
>> >> Rob
>> >>
>> >> _______________________________________________
>> >> TLS mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/tls
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>