On Sun, Mar 22, 2026 at 10:49:56AM -0700, Joseph Salowey wrote:
> We are working through issues brought up during the working group last
> call. We believe addressing these issues is necessary to determine if we
> have rough consensus to move forward. We expect the author to address the
> following points:
>
> * Key Reuse
> * Text for preferring Hybrids
> * Whether to include motivations (see Liaison Statement)
>
> We expect resolving these issues will take a few weeks after which we will
> run a targeted consensus call to see if text changes are acceptable to the
> working group.
FWIW, the essential question that might be answered is whether an
updated I-D would be less objectionable if:
- Advocacy for use of non-hybrid ML-KEM in some example use cases
were removed. Yes, that perhaps creates an opening to criticise
the draft as "lacking motivation", but I don't think that's a
substantive concern. The motivation is to publish a stable
specification of the how, not the why.
For an example of "jus the how", see "Elliptic Curve Cryptography
(ECC) Cipher Suites for Transport Layer Security (TLS) Versions
1.2 and Earlier": <https://datatracker.ietf.org/doc/html/rfc8422>,
in which I find just the nuts and bolts, apologies if I overlooked
the advocacy section.
Another "just the how", can be found in "Negotiated Finite Field
Diffie-Hellman Ephemeral Parameters for Transport Layer Security
(TLS)": <https://datatracker.ietf.org/doc/html/rfc7919>, there's
no advocacy there to use FFDHE over ECDHE, just a means to more
negotiate of the specified groups. Some (or many) now consider
negotiated FFDHE undesirable in both TLS 1.2 and 1.3, but if you
want to use it, there's a published reference.
- Clear guidance in the security considerations were added to
note that hybrid algorithms provide a recommended safety net,
in case the still novel ML-KEM construction succumbs to an
improved attack. That is, hybrids are recommended unless
the user fully understands and accepts the risk of relying
on ML-KEM alone.
- "Feel good" prohibition of reuse of its ephemeral key by the client
across multiple connections is added.
- The importance of non-reuse of the encapsulation random value by
the server is noted. This would allow the associated clients to
compute the shared secret the server negotiated with other clients
(provided the associated public keys, sent in the clear in the
client hello messages, are known).
This I-D presents an opportunity to those who would like to see a strong
recommendation in favour of hybrids across all IETF specifications to
test whether consensus for such a recommendation can at least be reached
in the context of this draft.
Given the extant IANA code points, and that support for non-hybrid
ML-KEM is already present (though typically either or both not
preferred, or enabled by default) in multiple TLS libraries, I see no
rational motivation to oppose publication "in any form". Surely, with
appropriate caveats there's a way to get this specification published
as an informational(!) RFC.
Blocking its publication changes little in practice, but creates some
confusion about whether the specification is still subject to change,
and may leave an impression that the IETF is out of touch. :-(
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
