Re: [TLS] TLS Export Channel Binding

[Jonathan Hoyland <[e-mail]>]

Hi Sam,

I think the idea is that any unique¹ exporter _is_ an RFC
5056-compliant channel binding.

Maybe I'm missing something, but I don't see what your draft adds?
If someone wants to construct a channel binding then they agree with their
peer on a context and a label, and use that to construct an exporter key.

If they mix that key into the key schedule of some other protocol then that
second protocol is bound to the TLS session².

If they want to pick the label "EXPORTER-Channel-Binding" and the empty
context, then that's already covered by the spec.

Is the idea to reserve the string for some specific use? If so, then the
suggested string is far to general, as it describes _any_ use of the
interface.

What do you see as the difference between an Exporter key and a channel
binding?

Regards,

Jonathan

1. I'm assuming an exporter is unique within a given TLS session iff the
given label and context are unique.
2. Unless the second protocol does something stupid like leak the TLS
session's master secret.


On Fri, 1 May 2020 at 17:08, Sam Whited <[e-mail]> wrote:

> Hi Jonathan,
>
> On Fri, May 1, 2020, at 12:00, Jonathan Hoyland wrote:
> > I believe TLS Exporters are what you are looking for.
> > https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5
>
> Thanks for the follow up. That is indeed what the channel binding type
> I've created uses. Would the TLS working group be interested in
> standardizing such a document?
>
> I've gone ahead and uploaded my initial draft that I threw together here
> in case you're interested:
>
>
> https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/
>
> —Sam
>