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

[Deirdre Connolly <[e-mail]>]

Whoops, I copy-pasted the wrong section, this is the definition for
'decrypt_error':

> decrypt_error:  A handshake (not record layer) cryptographic

operation failed, including being unable to correctly verify a
signature or validate a Finished message or a PSK binder.



On Wed, Mar 13, 2024, 10:08 PM Deirdre Connolly <[e-mail]>
wrote:

> Thank you very much for the notes!
>
> 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.
>
>
> Noted, tweaked on github slightly.
>
>
>
>> 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."
>
>
> Good point, tweaked 👍
>
> 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.
>
>
> This is a good point: -hybrid-design allocates 0x6399 and 0x639A for the
> two hybrid `NamedGroup`s so far. I don't have a strong opinion here, I
> basically followed -hybrid-design's lead and picked 0x0768 and 0x1024 for
> ML-KEM-768 and ML-KEM-1024.
>
>
>
>> 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?
>
>
> Oh very good point, DH doesn't usually fail like this; either because of
> fundamental (incredibly unlikely) decapsulation failure rates, or just a
> bug, this is good to handle, and we should probably update -hybrid-design
> to match. I've tracked this in this GitHub issue
> <https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/issues/1>
> for now. For my own sake, here's the `decode_error` defintion from RFC
> 8446:
>
> decode_error:  A message could not be decoded because some field was
>
>       out of the specified range or the length of the message was
>
>       incorrect.  This alert is used for errors where the message does
>
>       not conform to the formal protocol syntax.  This alert should
>
>       never be observed in communication between proper implementations,
>
>       except when messages were corrupted in the network.
>
>
>
> 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.
>
>
> Noted
> <https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/issues/2>; I
> will either define in-line or consistently use 'bind' in the X-BIND-P-Q
> sense (RFC 8446 uses 'bind' with the same colloquial sense but does not
> appear to define it).
>
> On Wed, Mar 13, 2024 at 5:36 PM Rebecca Guthrie <[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).
>>
>>
>>
>> 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
>>
>