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

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 10:25:36 -0500

Dave Cridland wrote:
> > - 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.

The lack of negotiability of which channel binding type to use makes
this not a good answer (but see below).

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

That doesn't mean it's negotiable.  GSS-API semantics do not allow the
acceptor to find out what channel binding type the client used.

We could put the channel binding type in the GS2 header -- that would
solve that problem.  But still, the server now has to support multiple
channel binding types and now we need a way to advertise that to the
client -- otherwise the client and server could disagree and fail to
authenticate.

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

Pasi's comment indicates that your premise for this thread is wrong.  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 seriously doubt that on the _client_ side, but also, I doubt it
on the server side.  Why would anyone want to write code to re-encode
certs on the fly when that can be done once at configuration time, or
never at all if the CA just does the right thing and issues a DER
certificate.

Also, even if there were implementations that re-encode non-DER certs
into DER for that API, surely, surely one could re-encode the cert at
configuration time so that it's in DER to begin with as far as the TLS
implementation goes -- then there's no need to re-encode as re-encoding
would be the identity function.

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Fri, 03 Apr 2009 17:31:41 +0100

On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> Pasi's comment indicates that your premise for this thread is wrong.

I certainly hope so. Nothing would please me more than being wrong  
here.

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

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 11:44:11 -0500

> the form in which they're signed.

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

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