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

[Nicolas Williams <[e-mail]>]

On Tue, Mar 24, 2009 at 10:37:37PM +0000, Dave Cridland wrote:
> Having carefully examined the tls-server-end-point channel binding,  
> I've a bit of a concern.

We should probably be having this discussion on the
[e-mail] list (cc'ed).  Also cc'ed are folks who
participated in the registration of tls-server-end-point.

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

File bugs against them!  If you have a list of such bindings I'll
volunteer to help file and track these bugs.

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

Questions:

1) Do many/most/all TLS implementations output the DER-encoded form of
   the server cert?  Which ones do/don't?

2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
   hard would it be to change this?  (e.g., re-encode the cert and
   restart apps?)

Notes:

 - By hard-coding a hash function we'd lose hash agility.  Hash agility
   is one of the features of the registered tls-server-end-point channel
   binding type.  OTOH, as you note, for SCRAM this is solved by the
   existing SCRAM hash agility approach (add a new mech).

 - We can't really negotiate which type of channel binding to use.  It's
   relatively easy to choose between unique and server-end-point, but to
   choose between two types of server-end-point bindings is much harder
   (unless it's a choice made at specification time, in this case for
   SASL/SCRAM).

   Neither modifying tls-server-end-point nor introducing a different
   variant of it seem particularly appealing.  The former may well be
   out of the barn's doors, which would leave us only with the latter
   choice (or fix the TLS frameworks :)

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

True.

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

Comments?

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


Nico
--