On Wed, Apr 16, 2025 at 09:37:22AM -0700, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-tls-mlkem-00.txt is now available. It is a work item
> of the Transport Layer Security (TLS) WG of the IETF.
>
> Title: ML-KEM Post-Quantum Key Agreement for TLS 1.3
> Author: Deirdre Connolly
> Name: draft-ietf-tls-mlkem-00.txt
> Pages: 11
> Dates: 2025-04-16
Thanks for posting the draft. Initial review comments:
Section 3. Key encapsulation mechanisms
----------
The text feels somewhat clumsy, and it is not clear that framing
the steps as algorithms/APIs is helpful. APIs vary, and I don't
believe that the details matter here.
Original: This document models key agreement as key encapsulation
mechanisms (KEMs), which consist of three algorithms:
...
Suggested: Obtaining a shared secret via Key Encapsulation Mechanism
(KEM) entails three logical steps:
* Key Generation: Alice generates a public encapsulation
key ek and a secret decapsulation key dk. The
encapsulation key ek is sent to Bob.
* Encapsulation: Bob uses Alice's public encapsulation key ek
to obtain a shared secret and a ciphertext ct to send to
Alice that enables the holder (Alice) of the decapsulation
key dk to obtain the same shared secret.
* Decapsulation: Alice uses the ciphertext ct and her private
decapsulation key dk to obtain the same shared secret as Bob.
The text then goes on to describe the three paramer sets, but I don't
see that the private key sizes and seed vs. expaneded forms are relevant
in TLS. It probably makes sense to say little about the private keys.
Original: ML-KEM-512, ML-KEM-768 and ML-KEM-1024 conform to this API:
...
Sugested: FIPS 203 specifies three ML-KEM parameters sets:
* ML-KEM-512 has encapsulation keys of size 800 bytes,
ciphertext size of 768 bytes, and shared secrets of size
32 bytes
* ML-KEM-768 has encapsulation keys of size 1184 bytes,
ciphertext size of 1088 bytes, and shared secrets of size
32 bytes
* ML-KEM-1024 has encapsulation keys of size 1568 bytes,
ciphertext size of 1568 bytes, and shared secrets of size
32 bytes
Section 4. Construction
----------
Original: We define the KEMs as NamedGroups, sent in the
supported_groups extension.
Suggested: Each of the three ML-KEM parameter sets is assigned its
own NameGroup codepoint, for use with the supported_groups
TLS extension.
Section 4.1. Negotiation
------------
Original: Each method is its own solely post-quantum key agreement
method, which are assigned their own identifiers, registered
by IANA in the TLS Supported Groups registry:
Suggested: This document extends NamedGroup (Section 4.2.7 of RFC8446)
with three additional values, to be added to the IANA
TLS Supported Groups registry:
Section 4.2. Transmitting encapsulation keys and ciphertexts
-------------
The first sentence seems redundant:
The encapsulation key and ciphertext values are directly encoded
with fixed lengths as in [FIPS203]; the representation and length of
elements MUST be fixed once the algorithm is fixed.
TLS encodes the length of the keyshare, and once its content is
specified below that text, there is nothing useful normative to say
about fixed lengths, ... that MUST adds nothing IMNSHO. Just
deleting that sentence I think improves the section.
The text that matters is basically fine, but should of course match
any changes in the Section 3 text, so perhaps:
Original: For the client's share, the key_exchange value contains the pk
output of the corresponding KEM NamedGroup's KeyGen algorithm.
Suggested: For the client's share, the key_exchange value contains the
encapsulation key ek generated by the client as described
in Section 3 in the format specified in FIPS 203 for the
associated parameter set (800 bytes for ML-KEM-512, ...).
Original: For the server's share, the key_exchange value contains the
ct output of the corresponding KEM NamedGroup's Encaps
algorithm.
Suggested: For the server's share, the key_exchange value contains the
encapsulation ciphertext ct computed by the server as
described in Section 3 in form the format specified in FIPS
203 for the associated parameter set (768 bytes for
ML-KEM-512, ...).
Is section 6.1 (Fixed Lengths) needed? Given this is not an issue for
ML-KEM, it is unclear why this is worthy of discussion.
Similarly, it is unclear that most of 6.2 is useful. ML-KEM satisfies
IND-CCA2. If the intent is to discourage key reuse despite the fact
that ML-KEM is believed to satisfy IND-CCA2, then a brief not just to
that effect may be sufficient.
And along the same lines, I don't see much point in section 6.3.
Security considerations might instead mention concerns that
ML-KEM is a comparatively new algorithm, and a hybrid construction might
defend against the risk that as yet unknown attacks might render pure
ML-KEM insecure, compromising past traffic even before CrQCs may turn
up. Concerned users might therefore want to use or prefer a hybrid.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
