On Fri, Oct 1, 2021 at 8:04 PM Sam Whited <[email protected]> wrote:
> I have to respectfully disagree with this. > > Anecdotally, RFCs are hard to discover. Having them linked from a > logical place in other RFCs is one way that discovery happens, and if > you're looking for how to do channel bindings with TLS the first place > you're going to look is the TLS RFC (and its list of updates). > > Secondly, this is an update, not a retconn. It in no way implies that > TLS 1.3 always said this, or that the TLS 1.3 authors were involved in > the channel bindings spec. TLS 1.3 does an analysis of its own keying > material exporters and we rely on this and present a standard name for > one scenario where it may be used, this does not involve new technology > or even a novel use of EKM. > Well, perhaps it would be useful to step back for a moment from the implications of "updates". We are currently preparing an 8446-bis. What would you have that document say about this topic? -Ekr > —Sam > > > On Fri, Oct 1, 2021, at 18:49, Eric Rescorla wrote: > > I don't believe that this document should update 8446. As noted in S > > 1, we didn't define these bindings because we didn't have complete > > analysis. This document doesn't seem to either contain or reference > > such analysis and until we have that, I think RFC 8446 shouldn't be > > retconned into endorsing this construction. > > > > -Ekr > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
