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

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 17:52:20 -0500

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
[email-masked] 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:[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

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Apr 2009 10:27:18 +0200

> 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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 02 Apr 2009 12:32:21 +0100

>    the server cert?  Which ones do/don't?
Somewhere between many and most. I suspect all the low-level TLS  
stacks (OpenSSL etc) will do. It's the bindings and suchlike I'm more  
concerned with.

In the bindings, however, it's pretty trivial to find a function  
which either hands back the DER form, or else hands back PEM (base64  
of DER), which developers can also use.

>    hard would it be to change this?  (e.g., re-encode the cert and
I have absolutely no idea. If I could rely on the cert being DER on  
the wire, we could reduce this to implementation notes, aside from  
the hash issue. I have no idea how to extract that hash algorithm,  
currently, but I could probably figure that out eventually.

If it turns out that tls-server-endpoint *can* be readily implemented  
at least for the common case of X.509 certificates, then I'd be very  
much happier with this outcome.

>    existing SCRAM hash agility approach (add a new mech).
Yes - it's not ideal, but I'm hoping that by the time hash agility  
becomes an issue, then we'll have support for the more generic form  
of the channel binding.

>    (unless it's a choice made at specification time, in this case  
But clients must stipulate which they have used.

>    choice (or fix the TLS frameworks :)

I think tls-server-end-point is a fine binding.

My problem is that it'll be years before it's available on many  
platforms, and I think we can provide more immediately implementable  
security than that.

Dave.

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 14:33:47 +0200

>    hard would it be to change this?  (e.g., re-encode the cert and

Although the TLS spec doesn't explicitly say this, the on-the-wire
certificate is DER encoded. There's no field specifying what the
encoding is, so if you attempt sending PER or XER, it simply won't
work.

Some implementations might accept some limited subset of BER (to
work around CA bugs), but even in those cases, nobody's going to
re-encode it to DER (most likely the CA calculated the signature over
BER encoded version -- violating all possible standards -- and the
API would return the octets sent on the wire).

So I don't see any problem in using the tls-server-end-point channel
binding... (and it seems it would work for OpenPGP, too)

Best regards,
Pasi

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 09:47:52 -0500

> encoding is, so if you attempt sending PER or XER, it simply won't

Right, I doubt anyone re-encodes certs in PER or XER :)

It's BER that one should worry about.

> API would return the octets sent on the wire).

OK, thanks.

> binding...

Excellent.  Thanks!

>            (and it seems it would work for OpenPGP, too)

It could be made to, but tls-server-end-point refers to the first cert
in the 'certificate_list' field of the server's Certificate message --
there's no such field in the OpenPGP case.  It'd be a trivial updat to
tls-server-end-point to allow the use of a server's OpenPGP cert though.

Nico
--