tl;dr: With the caveat that the text that might go in 8446bis is more important, I think kitten should probably follow tls’ lead here and not include the header.
The updates header has been the source of numerous debates for over a decade. It has been used to indicate critical normative updates, optional extensions, and what I would call “bread crumbs” to find related RFCs. In tls, we have probably used each of these [0]. But, the new normal is not including the updates header. RFC 8773, which is experimental, changes the behavior of TLS 1.3 to permit the server to send a CertificateRequest message when a PSK is being used and it did not get an updates header. draft-ietf-tls-subcerts is adding a mechanism to allow servers to use a delegated credential and it’s not got an updates header. EAP-TLS 1.3 doesn’t have an updates header. I feel your pain about needing to get the word out, but I am not sure where it stops. If everybody wants a breadcrumb, the splash page for the RFC will be about 3 pages long as it references all of the RFCs that now refer to it and the I-Ds that do. Check out the lengthy list here: https://datatracker.ietf.org/doc/rfc8446/referencedby/ Finally, even with the “liberal" policy back when TLS 1.2 was newer, the original tls-unique didn’t get an updates header. If you really want bread crumbs, what I would do is find all the places tls-unique is used (https://datatracker.ietf.org/doc/rfc5929/referencedby/) in TLS 1.2 and make sure for the TLS 1.3 a reference to this I-D gets in. Sorry I just noticed this now, but top ‘o the list would be: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ This I-D references possibly including an updated tls-unique mechanism for 1.3 (see s10.1) and is therefore ripe for a reference. I will note it is in the RFC editor’s queue awaiting publication but Ben can work magic. spt [0] The extreme case is probably where TLS 1.2 [RFC5246] is “updated" by an experimental RFC from the ISE stream. > On Oct 2, 2021, at 21:29, Sam Whited <[email protected]> wrote: > > Even if linking this in updates implied confidence (though I don't think > it does), TLS alread implies confidence in its own EKM mechanism. I > don't believe this document expands on that. For example, it does not > detail any particular use of channel binding. > > —Sam > > > On Sat, Oct 2, 2021, at 13:12, Eric Rescorla wrote: >> I want to be clear that I don't think this is about credit. My concern >> is purely about accurately reflecting the level of confidence one >> should have in this mechanism. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
