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

[Sam Whited <[e-mail]>]

Thank you for the detailed review! I believe I have addressed your
feedback in a draft that I will upload shortly, but have a few
comments (inline).

On Thu, Oct 14, 2021, at 20:20, Dale Worley via Datatracker wrote:
> Given that this is the introduction and RFC 5929 is referenced without
> its title, it would help the naive reader to change "channel binding
> types" to "channel binding types for TLS".

Since this document only updates the general-purpose "tls-unique" and
does not specifically define a new version of "tls-unique-for-telnet" I
have just changed the use of "unique" here to "tls-unique" to refer to
the specific channel binding type. Hopefully this makes it clear that it
is a TLS channel binding without the redundant "tls-unique channel
binding for TLS", but I'm happy to work on this further.

> It seems worthwhile to provide the name of the new binding type here.
> (And notice that it is "unique" in the sense of RFC 5056 but does not
> contain "unique" in its name.  I'm a little surprised you didn't name
> it "tls-unique-exporter" to maintain the parallelism.)

I'd be happy to change that if everyone wants, I have no preference.


> 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?

—Sam

-- 
Sam Whited