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

[Eric Rescorla <[e-mail]>]

On Thu, Mar 14, 2024 at 5:53 AM Deirdre Connolly <[e-mail]>
wrote:

> I would argue adding `ML-KEM` as a standalone NamedGroup is not more
> complex than adding ECDH groups, the hybrid part is the already complex
> part. To minimize complexity even more, one can 'just' do the X-Wing style
> of having a hybrid NamedGroup that doesn't know anything about the other
> available component NamedGroups, ie, no shared ephemeral ECDH or KEM
> keypairs: less complex, a little more compute.
>

I don't quite understand what complexity you are concerned with here in
terms of reuse.

As I understand it, S 3.2 of draft-hybrid permits the reuse of key shares
for a given group across hybrids, but does not require it. This means that:

1. You're free to generate your keys independently without reusing them.
2. Your behavior is the same even if the other side chooses to reuse keys.

The point being that implementations which want to save some compute can
absorb some complexity, but nobody is forced to. Am I misunderstanding?

-Ekr

I want there to be an option to negotiate ML-KEM alone, and turn off / not
> compile in the hybrid NamedGroups if I want to in my TLS 1.3 stack, and I
> think there will be a non-trivial user base for such an option very soon.
>
>
>
>
> On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson <ietf=
> [e-mail]> wrote:
>
>> On 14/03/2024 01:41, Deirdre Connolly wrote:
>>
>> Oh and one more consideration: hybrid brings complexity, and presenting
>> the pure-PQ solutions and their strictly lesser complexity (at the tradeoff
>> of maybe taking more risk against newer schemes no matter how good we feel
>> about their fundamental cryptographic foundations) is worthwhile in my
>> opinion.
>>
>> On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly <
>> [e-mail]> wrote:
>>
>>> [...] Shaking out all the negotiation decisions is desirable as well as
>>> 'drawing the rest of the owl' for the pure PQ option implied in the
>>> negotiation (are we going to copy the same ~1000 bytes for the PQ and
>>> hybrid name groups, when sharing an ephemeral KEM keypair?).
>>>
>> This is an argument that supporting PQ-only and PQ-hybrid simultaneously
>> will be more complex than just PQ-hybrids and require further changes at
>> the TLS layer.
>>
>> Given we've already paid the (minimal) complexity cost of hybrids and
>> switching to PQ-only seems strictly less secure, I'm really struggling to
>> see the motivation at this point in time. Once we're in a position to
>> remove the classical key exchanges from TLS entirely because we know
>> they're ineffective, switching to PQ-only might then have more benefit
>> since we could retire a lot of old code.
>>
>>
>>> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS,
>>> but a note that a non-trivial segment of users of standard TLS that have
>>> been traditionally compliant will not be in a few years, and they will come
>>> knocking anyway. This is trying to skate where the puck is going.
>>>
>>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>>> agreement in the next ~6-9 years is a strong vote of confidence in any
>>> protocol doing this at all, so, TLS wouldn't be out on a limb to support
>>> this, basically.
>>>
>>> I don't have a strong opinion on whether this should be Recommended = Y.
>>>
>>> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie <rmguthr=
>>>> [e-mail]> wrote:
>>>>
>>>>> Greetings Deirdre and TLS,
>>>>>
>>>>>
>>>>>
>>>>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>>>>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>>>>> and I have a few comments. First, though, I want to say thank you for
>>>>> writing this draft. I'll echo some of what has already been voiced on this
>>>>> thread and say that, while some plan to use composite key establishment, it
>>>>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>>>>> another option. Other WGs (lamps and ipsecme) have already begun to specify
>>>>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>>>>> respect to this draft, there is certainly interest from National Security
>>>>> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
>>>>> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
>>>>> security).
>>>>>
>>>>
>>>> I wanted to address this CNSA 2.0 point, as I've now seen it brought up
>>>> a couple of times.
>>>>
>>>> The IETF, together with the IRTF, needs to make an independent
>>>> judgement on whether using PQ-only algorithms is advisable, and if we do
>>>> not think so, then we should not standardize them, regardless of what CNSA
>>>> 2.0 requires. The supported groups registry policies are designed
>>>> explicitly to allow people to register non Standards Track algorithms, so
>>>> nothing precludes the creation of an ML-KEM only code point if some vendors
>>>> find that necessary, without the IETF standardizing them or marking them as
>>>> Recommended=Y.
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> A few specific comments:
>>>>>
>>>>>
>>>>>
>>>>> 1. In Section 1.1 (or Introduction - Motivation in the github
>>>>> version), I would suggest that the second sentence ("Having a fully
>>>>> post-quantum...") is not needed, i.e. that there need not be a
>>>>> justification for why it is necessary to specify how to use ML-KEM in TLS
>>>>> 1.3 (vs. hybrid). It could be appropriate to contextualize the
>>>>> specification of ML-KEM w.r.t the advent of a CRQC, though I also don't
>>>>> think that is necessary. As an example, we can compare to the Introduction
>>>>> in draft-ietf-lamps-cms-kyber-03.
>>>>>
>>>>>
>>>>>
>>>>> 2. Section 3 (Construction on github) currently reads, "We align with
>>>>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>>>>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>>>>> this specification (for the use of a standalone algorithm) off of RFC 8446
>>>>> instead of the draft spec for a hybrid solution. I understand wanting to
>>>>> align the approach with the approach taken for the hybrid solution, but I
>>>>> don't think that fact needs to be explicitly documented in this draft. When
>>>>> this draft is standardized, I think it's important that it is able to be
>>>>> read, understood, and implemented without needing to refer to the hybrid
>>>>> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
>>>>> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
>>>>> sent in the supported_groups extension."
>>>>>
>>>>>
>>>>>
>>>>> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses
>>>>> the phrase "groups" to refer to key exchange algorithms -- for example, the
>>>>> supported_groups extension -- since all key exchange algorithms in TLS 1.3
>>>>> are Diffie-Hellman-based.  As a result, some parts of this document will
>>>>> refer to data structures or messages with the term "group" in them despite
>>>>> using a key exchange algorithm that is not Diffie-Hellman-based nor a
>>>>> group."
>>>>>
>>>>> This seems okay, but on the IANA registry for TLS Supported Groups, it
>>>>> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
>>>>> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
>>>>> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
>>>>> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
>>>>> to accommodate QR KEMs.
>>>>>
>>>>>
>>>>>
>>>>> 4. In the Discussion section (on github), does the portion on failures
>>>>> need to contain more information about how a failure should be handled in
>>>>> TLS? Should a decrypt_error alert be sent?
>>>>>
>>>>>
>>>>>
>>>>> 5. In Section 4 (or Security Considerations on github), this may be a
>>>>> silly question, but is the definition of "commits" well-understood (in the
>>>>> first sentence on datatracker; in the first sentence of Binding properties
>>>>> on github)? It is not used in RFC 8446 so it might be worth explaining the
>>>>> meaning or using different phrasing in this sentence.
>>>>>
>>>>>
>>>>>
>>>>> Also, what are the WG's thoughts on including standalone PQC
>>>>> signatures in the same draft?
>>>>>
>>>>>
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>>
>>>>>
>>>>> Rebecca
>>>>>
>>>>>
>>>>>
>>>>> Rebecca Guthrie
>>>>>
>>>>> she/her
>>>>>
>>>>> Center for Cybersecurity Standards (CCSS)
>>>>>
>>>>> Cybersecurity Collaboration Center (CCC)
>>>>>
>>>>> National Security Agency (NSA)
>>>>>
>>>>>
>>>>>
>>>>> *From:* TLS <[e-mail]> *On Behalf Of * Deirdre Connolly
>>>>> *Sent:* Tuesday, March 5, 2024 9:15 PM
>>>>> *To:* [e-mail]
>>>>> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>
>> _______________________________________________
>> TLS mailing [e-mail]://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
>