Looks like the same link got included twice? But thank you, I'll try to rework the language again to reference that. —Sam On Mon, Oct 18, 2021, at 00:50, Benjamin Kaduk wrote: > On Fri, Oct 15, 2021 at 11:25:01PM -0400, Dale R. Worley wrote: >> "Sam Whited" <sam@xxxxxxxxxxxxx> writes: >> >> The appearance of this paragraph in this section suggests (but >> >> does not assert) that in TLS 1.3, the cipher negotiation always >> >> results in unique master secrets. Indeed, it would be extremely >> >> convenient if (standard-conformant) use of TLS 1.3 always did so, >> >> and if so, it would be convenient to inform the user by asserting >> >> that at the end of section 2 (after moving the current last >> >> paragraph to a different section). >> > >> > This one I had a lot of trouble with. I tried to put in some new >> > language, but it feels out of place to me somehow. I'm not sure >> > that this document should make assertions about the correctness of >> > TLS 1.3, as well vetted as it has been, so I tried to phrase it in >> > terms of "this mechanism is useful so long as this property holds", >> > which seems like it might belong in security considerations, not >> > the registration section? >> >> This is probably the only really significant point in my review ... >> I can understand your caution here. It seems to me that the ideal >> solution is for TLS 1.3 to have been explicitly designed so that >> there are unique master secrets, and then you just reference that. >> Now it seems that everybody thinks TLS 1.3 has this property, so I'd >> expect that was an explicit design goal, and it would be documented >> somewhere. And then this document could just point to that. > > The last paragraph of > https://datatracker.ietf.org/doc/html/rfc8446#appendix-D > discusses how TLS > 1.3 should be treated as always providing the RFC 7627 "extended > master secret" behavior; that RFC, in turn, discusses the (non- > )uniqueness of the master secret in the absence of the "extended" > behavior. > > https://datatracker.ietf.org/doc/html/rfc8446#appendix-D also > discusses the uniqueness of TLS 1.3 secrets/keys. > > -Ben -- Sam Whited -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
