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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
