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

[Sam Whited <[e-mail]>]

Responses inline:

On Wed, Nov 18, 2020, at 14:49, Robbie Harwood wrote:
> This document doesn't seem to address what the problems with the
> previous channel binding types were.

I'll add some text here. The TL;DR is that without the extended master
secret fix from RFC7627 tls-unique is not actually unique. I also recall
someone suggesting that the unique data really wasn't long enough, which
seems likely, but I don't have a citation for that off the top of my
head so I'll stick to mentioning the triple handshake vulnerability and
the extended master secret extension and leave it at that.


> It also doesn't appear in the referenced section (i.e., RFC 8446
> section 7.5 doesn't seem to have this information; moreover, that
> section doesn't reference RFC 5929).
>
> RFC 8446 section C.5 does call out cbs as a protection mechanism, but
> merely notes that they're not implemented for 1.3, so it's probably
> not a case of wrong section.

That was indeed supposed to be a reference to C.5. That's the only
reference I'm aware of for why the two CB mechanisms from 5929 aren't
defined in 1.3. This is a very confusing off-the-cuff reference in the
TLS 1.3 spec, but it's what I'm basing the entire need for a new CB
mechanism on.


> In "2. The 'tls-exporter' Channel Binding Type": … This feels
> redundant with the formal IANA considerations section later in the
> document.  I think it would be more helpful to orient it toward
> explaining the cb type as pertains to RFC 5705 and RFC 8446.

I did it this way because RFC5929 did it this way, but I agree it's
awkward. I'll rewrite this to be descriptive and give a bit of
background on EKM and TLS 1.3 instead.


> Hmm, this text is a bit awkward right now.  I suggest something like:
>
>     When TLS renegotiation is enabled, implementations MUST NOT
>     support channel binding using the "tls-exporter" type as it is not
>     defined.

Sounds good to me; thanks.


> Curious - is there a practical reason to want this CB type with TLS <=
> 1.2?

Not that I can think of. I suppose it would be nice to have a single
channel binding type that works regardless of the TLS version being
used, but it seems simpler to just let TLS 1.2 die and not worry about
it since channel binding isn't widely supported right now anyways.


> Please also see the idnits here:

Will do, thanks.

I'll have a new version up soon.

—Sam

-- 
Sam Whited