David Benjamin wrote: >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
I completely agree, RFC 9001 does not actually use ECB. However, the fact that it mentions ECB is very problematic. As ECB is named in the QUIC RFC, people DO think it is acceptable to use it, when in fact they absolutely should not. The IETF should take responsibility not only for the security of QUIC itself, but also for the broader ripple effects that RFC wording cause. In my view, there is no valid reason for QUIC to mention ECB at all. If a library lacks AES-ENC, then AES-CBC or AES-CTR can be used instead. In fact, the following four formulations all produce the same result: 1. AES-ECB(P = X) 2. AES-ENC(P = X) 3. AES-CBC(P = X, IV = 0^16) 4. AES-CTR(P = 0^16, IV = X) Cheers, John From: David Benjamin <david...@chromium.org> Date: Wednesday, 3 September 2025 at 04:19 To: Martin Thomson <m...@lowentropy.net> Cc: Tim Hollebeek <tim.holleb...@digicert.com>, Sophie Schmieg <sschm...@google.com>, John Mattsson <john.matts...@ericsson.com>, <tls@ietf.org> Subject: Re: [TLS] Re: Concerns about the current draft. On Tue, Sep 2, 2025, 21:09 Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>> 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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
