Subject: TLS endpoint channel bindings in SCRAM

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Mar 2009 22:37:37 +0000

Having carefully examined the tls-server-end-point channel binding,  
I've a bit of a concern.

One of the sticking points of the tls-unique channel binding is how  
easy it is to get at the data - OpenSSL provides an API, however it's  
often not exposed to language bindings such as Python, etc, and other  
TLS implementations may not provide it at all.

I can't find any way of getting at the on-wire representation of the  
server's certificate, and I can't immediately find a way of  
discovering which hash algorithm to use, either, in the vast majority  
of bindings.

So rather than expect all TLS implementations and bindings to change,  
I'd like to propose an alternate binding, for use where the server's  
certificate is an X.509v3 one.

Specifically, I'd like to use a fixed hash algorithm over the  
DER-encoded form of the certificate - I'll call this  
"tls-x509-end-point"

The DER form of the certificate is readily available through most  
bindings, in many cases in a single call, and gives exactly  
equivalent hash-input as the on-wire format, which is very likely  
[but not mandated, as far as I can find] to be DER anyway.

Fixing a hash algorithm simply makes this even easier - the current  
channel binding uses SHA-256 as a "minimum hash", I'd prefer to use  
SHA-1, as we're certain to have it for SCRAM.

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

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade