Re: [Gen-art] Genart last call review of draft-ietf-kitten-tls-channel-bindings-for-tls13-09

[Benjamin Kaduk <[e-mail]>]

On Fri, Oct 15, 2021 at 11:25:01PM -0400, Dale R. Worley wrote:
> "Sam Whited" <[e-mail]> 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