[Prev] Thread [Next] |
[Prev] Date [Next]
Re: New version of draft-altman-tls-channel-bindings
Fri Jun 12 12:00:55 2009
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-
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
> Section 7 suggests implementation requirements on TLS implementations.
> 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),
Are there other possibilities that I did not consider? Why is what I