Re: New version of draft-altman-tls-channel-bindings

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Fri, Jun 12, 2009 at 11:23:33AM +0200, Simon Josefsson wrote:
> The registration sections 3-5 looks fine to me.
> 
> I have two mild concerns on section 6 and 7:
> 
> Section 6 mandate rather general restrictions on application protocol
> specifications that appear to apply beyond the channel binding types
> defined in the document.  It this the document to do that?  It appears
> as if the text is written to apply to draft-josefsson-sasl-tls-cb too.

What it mandates should be entirely non-controversial, I thought:

   Specifically, application protocol specifications MUST indicate at
   least one mandatory to implement channel binding type, MAY specify a
   negotiation protocol, MAY allow for out-of-band negotiation or
   configuration, and SHOULD prefer 'tls-unique' over 'tls-server-end-
   point'.

This doesn't say what the apps must require, just that they must require
something.  It doesn't dictate specifics.

There's also a recommendation:

                                      ...  However, it is RECOMMENDED
   that application protocols making use of TLS channel bindings, use
   'tls-unique' exclusively, except, perhaps, where server-side proxies
   are common in deployments of an application protocol.  ...

I thought that too would be non-controversial as it is just a
recommendation.

> Section 7 suggests implementation requirements on TLS implementations.

Yes.

> GnuTLS has APIs that allows applications to implement tls-unique and
> tls-server-end-point, but these interfaces would not follow the MUST in
> section 7 at least the way I read them.  I'd prefer to leave API design
> to implementers, and hence remove the RFC 2119 keywords from this
> section, and have the section provide guidance rather than norms.

The section 7 text says that either the TLS implementation must either
provide an interface for extracting channel bindings by channel binding
type (something like: getCB(connection, cb_type) -> CB data), or
interfaces for extracting those items that are used to construct the CB
data (something like: getFirstClientFinishedMsg(connection),
getFirstServerFinishedMsg(connection), getServerEECert(connection)).

Are there other possibilities that I did not consider?  Why is what I
wrote controversial?

Nico
--