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

[Nicolas Williams <[e-mail]>]

On Fri, Apr 03, 2009 at 05:31:41PM +0100, Dave Cridland wrote:
> On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> >  I
> >don't know though.  Can you comment on Pasi's comments?  Are there  
> >any
> >commonly used TLS implementations that encode the server cert
> >differently on the wire than in their APIs for getting at the server
> >cert?
> 
> I have no idea at all, I'm sorry to say. It makes sense to me that  
> X.509 certs, at least, would always be encoded in DER, since that's  
> the form in which they're signed.

Between this and my other comment I'm willing to close this as a
non-issue.

> That then reduces the problem of the existing channel binding to  
> being figuring out which hash to use, and I strongly suspect that  
> just using SHA-256 is sufficient for now. (it's unfortunate this is  
> different to the hash algorithm we seem to have settled on for SCRAM,  
> but it's far from a blocker, merely a mild inconvenience).

Right, we chose SHA-256 for tls-server-end-point because it should
future proof us for long enough that people will be able to implement a
cert->hash API as described in tls-server-end-point.  I think that's
fine.  We couldn't use SHA-1 because we're not using HMAC here, so
there's no mitigation against SHA-1 breaks.  SHA-256 implementations,
including open source ones in various licenses, exist.  So I'm going to
consider this a non-issue also.

Nico
--