Re: [TLS] TLS Export Channel Binding

[Sam Whited <[e-mail]>]

On Mon, May 4, 2020, at 09:14, Jonathan Hoyland wrote:
> 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.

I had originally written a long-ish reply about why we couldn't make
this SCRAM specific, but I've just realized after going back and
looking at the spec and one of my own implementations that I was
completely wrong.

This is a great idea, and I believe would be secure since the client-first-
message and server-first-message will contain their respective random
nonces. A malicious client or server *could* slip some arbitrary text
into either message, but if I understand TLS exporters security
properties correctly this should not pose a problem and the export data
should still be indistinguishable from random noise to someone without
the TLS master secret (a sanity check by an expert on this statement
would be appreciated).

I have updated the draft with these changes: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/

I'm still not entirely clear if this would be a better draft for the
KITTEN WG or this one. If we update the SCRAM RFCs I think it may be
better to go through KITTEN, but I'm not sure that they'll want to take
that work on. I'll ask. Any advice here would be appreciated since I
know almost nothing about IETF policy or procedures.

Thanks for your feedback!

—Sam