Re: [TLS] Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

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 <sam@samwhited.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls