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

[Dennis Jackson <[e-mail]>]

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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls