Re: [TLS] TLS Export Channel Binding

[Sam Whited <[e-mail]>]

On Fri, May 1, 2020, at 14:08, Jonathan Hoyland wrote:
> 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.

The draft just registers a method of using it with the IANA Channel
Binding Types registry so that you can negotiate and use exported keying
material in eg. SCRAM based SASL auth. Right now if I wanted to use EKM
for channel binding, what would I negotiate (ie. what would I set the p
field of a gs2 header to in SASL based auth?)


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

Yes, that's the idea. This registers the "tls-exporter" channel binding
type in the registry, and the label EXPORTER-Channel-Binding to use with
it. This is supposed to be a generic channel binding type that can be
used to negotiate channel binding when multiple are available, eg. if
the server supports both tls-unique (the last TLS finished message) and
exporter data, we need an identifier to decide that we want to use
exporter data. That also means having a label that we can associate with
this context.

I'd be happy to change the name if the consensus is that this is too
general, but I didn't think it made sense to make this SASL or <other
auth system> specific.

—Sam