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 list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
