[TLS] Re: Concerns about the current draft.

[David Benjamin <[e-mail]>]

On Tue, Sep 2, 2025, 21:09 Martin Thomson <[e-mail]> wrote:

> On Wed, Sep 3, 2025, at 03:12, Tim Hollebeek wrote:
> > In particular, X-ECB is horribly broken and these days probably should
> > not be used by anyone, ever. That advice is already a decade old or
> > more, at this point.
>
> Total distraction, but RFC 9001 uses ECB.  Defensibly so, I believe.
> Though perhaps you might consider the use as part of a more advanced mode,
> HN-1.  Now for the tongue-in-cheek version: Absolute statements are always
> wrong.
>

To add to the distraction, this is really an example of compounded
confusion in how to define things, not a legitimately good use of ECB.

RFC 9001 doesn't really use ECB. It uses the AES block cipher, a function
that takes a fixed-length 16-byte input to a fixed-length 16-byte output.
It's just that some (but not all!) cryptography libraries don't have an API
for that, instead insisting on jamming unrelated objects into the same
interface. That leads to always having a variable-length Mode(TM) on
everything. (This kind of thinking leads to the infamous "RSA/ECB/..."
APIs.)

Then the (not common) applications that actually need the underlying
fixed-length block cipher are stuck using variable-length ECB as the only
way to get at it, even though actually making use of the variable-length
aspect would be a problem.

To that end, RFC 9001 would have been written better to say it used the
block cipher, with a little bit of implementation guidance that, if you
don't have an API for that, you might be able to call an ECB API instead.
Indeed I remember, when I was helping folks implement this, the ECB wording
caused a lot of confusion and I had to direct them to the block cipher
functions instead. No sense in materializing all the extra machinery for a
true variable-length ECB when you were just going to run the block cipher
once.

David

>