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

[Nicolas Williams <[e-mail]>]

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