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

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Jun 2009 13:26:08 -0500

I've just posted draft-altman-tls-channel-bindings-04.  This version
re-submits the existing three TLS channel bindings types following
Larry's note to the IESG transferring "ownership" of his channel binding
types (Jeff will do so soon for his as well, I think).

References were added, applicability text (based, in part, on
discussions in this WG) and security considerations text was added, as
well as minor clarifications.

Please review.  Thanks,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Jun 2009 11:23:33 +0200

> well as minor clarifications.

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.

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.

Thanks,
/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Jun 2009 13:27:12 -0500

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

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