With the benefit of hindsight, it sounds like the registry for the
algorithms for TLS 1.2 should have included a column for planned / in
use / deprecated / prohibited, with a procedure for new RFCs to change
that column. It is much easier to see that after one has tripped over
the problem than it is during RFC development.
Yours,
Joel
On 7/5/2026 6:17 PM, Eric Rescorla wrote:
Hi Joel,
On Sun, Jul 5, 2026 at 3:02 PM Joel Halpern <[email protected]> wrote:
I read this note twice, and then went and reread the draft.
As far as I can tell, the "amends" tag is trying to do something that
the updates tag does not do today. There is a way to say that
efforts
to implement X MUST implement Y. That is not by "Updates". It is by
"Obsoletes." I grant that writing the full draft Y to obsolete X is a
pain. But having a set of draft that say if you do X, you must do Y,
and if you do Y, you must do Z, is simply a minefield asking folks to
get it wrong.
I think this is right. Asking people to chase a bunch of references to
know what they have to do is not good.
Note: I can believe we have sometimes abused "updates" when we should
have done a revision. That doesn't make it right. And very much
does
not make it something I think we should do as a matter of course. (I
think I had missed this because I simply did not believe we inte4nded
it. But Michael was quite clear that he intended it. Clarity is
good.)
I fear that we have done this fairly often. To use an example I am
familiar with, TLS 1.2 (RFC 5246) is updated by at least the following
RFCs which change its behavior:
* RFC 6176 forbids offering SSLv2
* RFC 7568 forbids offering SSLv3
* RFC 7465 forbids the use of RC4
* RFC 9155 forbids MD5 and SHA-1
-Ekr
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
