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

[Deirdre Connolly <[e-mail]>]

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