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

[Sam Whited <[e-mail]>]

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" <[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

-- 
Sam Whited