[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Benjamin Kaduk <[e-mail]>]

(again not quoting the text that was accompanied by a no-derived-works disclaimer)

For my present purposes of getting a general sense of the trend, I don't really
care if we assume 5000 bytes/second full-duplex or half-duplex, though my
understanding is that this type of unit has a single radio module that
functions as half-duplex.

Thanks for reframing the numbers to the smaller-scoped system.

Keygen times on the order of tenths of seconds may need closer analysis (and a
non-straw-man use-case) to really assess, if we're in a domain that only has
single- or two-digit numbers of seconds to achieve the entire higher-level
protocol action (over multiple round trips, etc).

And I assume that the bit where ML-KEM-768 is approximately 3% faster than
X25519 plus ML-KDM-768 is for a microbenchmark scenario where we are just doing
key exchanges and nothing else, so may end up in the noise for some traffic
patterns (but for an application protocol that's just a one-shot
request/response using small messages, might not be in the noise).

I 100% agree that there's a difference between having tangible use-cases for
which a protocol proposal provides clear benefit and hand-waving about
constrained devices.  I do think that constrained devices have several more
axes of "cost" to consider than are in play for the vast majority of devices
participating in the Web ecosystem, such as code footprint, but those different
axes of "cost" do not obviate the proposer of a protocol mechanism from
demonstrating that there is benefit along one or more such axes from the
proposal.  This ties back to my own review comment on the draft, in that the
draft does nothing to discuss the tradeoffs of hybrid vs non-hybrid or give
some justification for what secnario(s) might prompt someone to prefer the
non-hybrid ML-KEM.

John should be fairly well-posititioned to bring in some concrete
constrained-device use cases that would inform a more precise analysis, if he
wants to pursue constrained devices as an example use case that would justify
this protocol mechanism.  (I am not.)

Thanks,

Ben