Hi Sam, If you wanted to use a SCRAM based SASL auth then you could pick `p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered string, and update the SCRAM RFC to require that string with TLS 1.3. You actively don't want for the same channel binding to be an input to multiple different protocols (or even the same protocol but with different parameters) because it opens the door to confusion attacks.
I've only skimmed the SCRAM RFC, but it might make sense to include `client-first-message` and `server-first-message` as context to the exporter interface, because it seems that the channel binding isn't needed until the `client-final-message`. The idea is to use the transcript to bind the channel binding to the negotiation of SCRAM parameters, and thus allow you to define a single "TLS-SASL-SCRAM" string (or whatever makes sense), rather than have one for each possible set of parameters. Obviously you'd need to think some more about whether that was actually secure, but at first glance it seems like a reasonable approach. Channel bindings that bind both the underlying channel and the higher-level protocol make more sense to me that channel bindings that only identify the underlying channel, because you don't have to worry about the (potentially pathological) behaviours of other users of the binding. Regards, Jonathan On Fri, 1 May 2020 at 19:16, Sam Whited <s...@samwhited.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
