Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM

[Simon Josefsson <[e-mail]>]

Nicolas Williams <[e-mail]> writes:

>> Finally, I'd propose that SCRAM mandates support for the  
>> 'tls-x509-end-point' channel binding for the applicable cases as a  
>> reasonable fallback when support for the more flexible and  
>> future-proof tls-server-end-point binding is not available.
>> 
>> Now I'll wait to get shot down in flames. :-)
>
> No flames.  I think we could do a channel binding type just for SCRAM
> (we did one just for TELNET, after all).  But I think I'd want "DER" in
> the name, that and the hash function name too.

I don't think that will work -- TLS isn't just X.509.  TLS supports
OpenPGP server certs.  Generally, TLS can support other forms of server
authentication too.

I don't want to see SCRAM require use of X.509 server certificates if we
can avoid it.

It seems simple to avoid that here: just request the necessary features
from TLS stacks.  If we don't do that now, we likely won't do it next
time we need a channel binding for some application protocol, and then
TLS interfaces will never have this feature.  Nico volunteered to help
with this for OpenSSL, and I can volunteer to do it for GnuTLS.  We knew
from the start that channel bindings would require changes to TLS
stacks.  The major native C libraries have already been adapted, I
believe, so what remains are any language bindings.  That seems like
Just A Simple Matter Of Programming.

The alternative is to make channel binding type negotiable, something I
recall discussing at lengths earlier.  Nothing came out of that, so RFC
5056 does not support any negotiation.  I'm not sure how well it would
work to add that feature for SCRAM?  But it could be explored.

/Simon