Re: [kitten] Comments on draft-tls-channel-bindings-for-tls13

[Sam Whited <[e-mail]>]

Responses inline:

On Thu, Nov 26, 2020, at 02:21, Benjamin Kaduk wrote:
> I would have to go trawl through the archives to be sure, but in TLS
> 1.3 the first Finished is sent by the server, and does not cover the
> client Certificate.  So the RFC 5929 tls-unique is not fit …

Not to mention that in some situations it may not even exist (ie. when
0-RTT is enabled). If you find a citation for this I'm game to expand
this section a bit to cover why it wasn't great for TLS 1.3
specifically.

> It may (or may not) be worth a reminder that any renegotiation is
> pre-TLS-1.3.

Probably a good idea; I'll ear-mark that for the next version. I don't
have it in front of me, but I vaguely remember mentioning that it
wasn't defined when renegotiation was in use, but since we don't define
it for TLS 1.2 anyways that's probably redundant. I'll try to clear
that up anyways.


> Indeed, and I've been attempting to promote this unified usage.

If you can think of a way to do it safely I'm not against defining this
for TLS 1.2, I just don't think I personally have the expertise to do so
since the key exchange mechanisms may or may not be safe for channel
binding and it feels bad to have a CB mechanisms that has to have a big
allow list of ciphers and lots of warnings like "Don't do this if you're
using RSA key exchange, it won't actually be a valid binding", etc.

—Sam