On Fri, Oct 1, 2021 at 8:04 PM Sam Whited <s...@samwhited.com> wrote:
> I have to respectfully disagree with this. > > Anecdotally, RFCs are hard to discover. What do you mean, exactly, here? Are you saying that this draft “update” 8446 in order for readers to understand it and 8446 itself? thanks, Rob 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. > > —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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
