[TLS] Re: I-D Action: draft-ietf-tls-mlkem-00.txt

[Viktor Dukhovni <[e-mail]>]

On Wed, Apr 16, 2025 at 09:37:22AM -0700, [e-mail] 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.