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 <rmgu...@uwe.nsa.gov> 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 <tls-boun...@ietf.org> *On Behalf Of * Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
