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

[Dave Cridland <[e-mail]>]

On Wed Apr  1 23:52:20 2009, Nicolas Williams wrote:
> 1) Do many/most/all TLS implementations output the DER-encoded form  
> of
>    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.


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

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


>  - 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).
> 
> 
But clients must stipulate which they have used.


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

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