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= 40dennis-jackson...@dmarc.ietf.org> 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 <durumcrustu...@gmail.com> > 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...@rtfm.com> wrote: >> >>> >>> >>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie <rmguthr= >>> 40uwe.nsa....@dmarc.ietf.org> 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 <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 >>>> >>> > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls