(not speaking as a chair of anything here)
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.
Agreed. A ML-KEM only code point can exist for the vendors that need it
without the need of a IETF standarised document.
I think that the decision of standarising and allowing only one PQ KEM
algorithm is more of the area of IRTF, as it might need the analysis.
The complexity of hybrids seems minimal imho specially for some
protocols. As Denis points out, switching to PQ-only seems strictly less
secure given the decades long research that ECDH has had (with this I'm
not implying that this means that ML-KEM or anything other of the
PQ-KEMs are insecure, though).
I think we eventually will get there to only having the PQ algos, but
right now it seems perhaps too soon ;). If right now is needed for
experimentation or for some vendors, registering the code point without
an IETF standard seems advisable.
Thank you,
____
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 <mailto:tls-boun...@ietf.org>> *On
Behalf Of * Deirdre Connolly
*Sent:* Tuesday, March 5, 2024 9:15 PM
*To:* TLS@ietf.org <mailto: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 <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
she/her, they/them.
Chair of hprc at IRTF, pquip at IETF, and anti-fraud at W3C.
Reach me out at: cheren...@riseup.net
Website: https://sofiaceli.com/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
