Channel Bindings for TLS
draft-altman-tls-channel-bindings-10

[Ballot comment]
The second paragraph of the interoperability note in 3.1 only applies to connections that
have this channel binding type, but the text is written very generally. Perhaps a few words
for further context would be helpful so the MUST NOT and SHOULD NOT are clearer would
be in order.

[Ballot comment]
Juergen Quittek has made a number of non-blocking editorial comments in his OPS-DIR review. I suggest that these are taken into consideration by the RFC Editor:

1. Section 2, Introduction, line 1: [RFC5246] -> [RFC5056]
 
2. Sections 3.1, Description
Is it really necessary to keep the almost unreadable original text of the original IANA entry?  It is hard to parse and can easily be misunderstood.
It is an incomplete sentence with two notes embedded into it in brackets.
The following text that was added is readable, the original text has rather limited readability.
If there are strong reasons for keeping the original text, then I would suggest at least to add a line break or an empty line after the original text for marking the beginning of the new (readable) area.
But I would rather suggest to rephrase the first incomplete sentence.
Standards are written to achieve interoperability and this can only be achieved if all implementers read the same semantics from the standards text. My strong recommendation would be to turn this single incomplete sentence with two embedded notes into a few complete sentences of plain text covering also the notes without embedding them with brackets.
Currently, the note in "The first TLS Finished message sent (note:
the Finished struct)" is not very clear to me.
 
3. Section 4.1, Description:
For better readability I would suggest turning the note in brackets into a separate sentence. Different to Section 3.1, the text is clear as it is and no rewording is required, just replacing brackets by full stops.

4. Section 5.1 Description:
It starts with "There is a proposal for adding a "StartTLS" extension to TELNET ...".
It is not clear to the reader who made any proposal, where to find it and why it is relevant for this standard. Reporting about proposals does not seem to be very useful in a description that serves interoperability.

5. Section 6, second paragraph on page 13 starting with "Therefore
'tls-unique'":
The draft states "Therefore 'tls-unique' is generally better than 'tls-server-end-point'". What is generally better? This phrasing does not seem to be precise enough for a standards document.

6. Section 6, fourth paragraph on page 13 starting with "In other words":
The phrase "In other words" does not relate to the previous sentence but to some sentence earlier than that. It is not clear which sentence it refers to.

7. Section 6, fourth paragraph on page 13 starting with "In other words", lines 2-3:
"Channel binding is all or nothing" - this phrase deserves clarification.

8. Section 6, fourth paragraph on page 13 starting with "The specifics", lines
4:
the statement "it is RECOMMENDED that ..., except, perhaps, where ..."
appears to be not precise enough because you use "perhaps". Would it be possible to just remove "perhaps"? Using "Recommended, except, perhaps"
makes it hard for an implementer to understand what to do.

9. Section 7, 1st paragraph, lines 9 and 11: I would remove "(" and ")".

[Ballot discuss]
Because of the non-backwards compatible change made in the 'tls-unique' channel binding type I believe that it would ve very useful to warn readers of the document in the Abstract and mention that this document updates the content of the IANA Channel Binding Types.

[Ballot comment]
1) The abstract refers to RFC 5056 as "On Channel Binding".  Section 2 refers to "On Channel Bindings" as RFC 5246 (it's TLS 1.2) and it says the registration procedures for these channel bindings are in RFC 5246 (I think they're in 5056).  Should Section 2 read:

OLD:

Subsequent to the publication of "On Channel Bindings" [RFC5246],
three channel binding types for Transport Layer Security (TLS) were
proposed, reviewed and added to the IANA channel binding type
registry, all in accordance with [RFC5246]


NEW:

Subsequent to the publication of "Transport Layer Security (TLS)
Protocol Version 1.2" [RFC5246], three channel binding types for
Transport Layer Security (TLS) were proposed, reviewed and added
to the IANA channel binding type registry, all in accordance
with [RFC5056].

2) Transfer of ownership: Is it transfer of ownership or transfer change control?  And, is it to the IESG or IETF?

3) Should the "should" be "SHOULD" in the last paragraph of 3.1?  6 provides uses requirements language wrt application protocols.  Actually, Section 7 uses "SHOULD" and it's talking about APIs.

4) Is "Subject:" needed in 3.2, 4.2, and 5.2?  It's in 5056.

5) Should the descriptions in 3.2, 4.2, and 5.2 point to  ?

6) Owner/Change control: Should the IESG's email address be included?

7) I think you've got page breaks for the heading in Section 7.  There's four words on Page 6 ;)

8) Is there some reason you're not pointing to FIPS-180-3?  I think -3 obsoletes -2 (not entirely sure of this).

IANA comments:

Upon approval of this document, IANA will make the following
changes in the "Channel Binding Types" registry at
http://www.iana.org/assignments/channel-binding-types/

OLD:

Channel Binding Reference Registration Date
--------------- ---------- -----------------
tls-server-end-point [IESG] 2008-06-26 (modified 2009-06-16)
tls-unique [IESG] 2008-06-26 (modified 2009-06-16)
tls-unique-for-telnet [Altman] 2008-06-26

NEW:

Channel Binding Reference Registration Date
--------------- ---------- -----------------
tls-server-end-point [RFC-altman-tls-channel-bindings-10] 2008-06-26
(modified
2009-06-16, 2010-04-12)
tls-unique [RFC-altman-tls-channel-bindings-10] 2008-06-26 (modified
2009-06-16, 2010-04-12)
tls-unique-for-telnet [RFC-altman-tls-channel-bindings-10] 2008-06-26
(modified
2010-04-12)


We understand the above to be the only IANA Action for this document.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Nicolas Williams, one of its
authors.  The Document Shepherd believes this version of this document
is ready to be forwarded to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document is an individual submission I-D that does not fit in the
charter of any current WGs.  However, the I-D has been reviewed in the
SASL and TLS WGs in a pseudo-WG Last Call.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The Document Shepherd has no such concerns and is aware of no IPR
covering this work.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

WG consensus is solid; there were no opinions voiced against
publication.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

There is no disclaimer for a pre-RFC5378 work.  There should probably be
such a disclaimer; I will check with the co-authors.

The idnits tool doesn't understand the notion of multiple "normative
references" sections and complains about the one reference defined in
section 10.2 ("Normative References for 'tls-server-end-point'").  This
is a spurious warning that can be ignored.

Finally, there is a new version of draft-irtf-cfrg-rhash, which is an
informative reference for this document.  This reference can be updated
later.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has separate normative and informative references sections.
There are no normative references to documents outside the Standards
Track, with the exception of FIPS-180-2, which is appropriate for use as
a normative referenced.  There are no downrefs.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes.  Yes.  Yes.  N/A.  N/A.  N/A.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

Technical Summary

  This document defines three channel binding types for Transport Layer
  Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
  telnet, in accordance with RFC 5056 (On Channel Binding).

Working Group Summary

  Although this is an individual submission, it was pseudo-Last Called
  in the SASL and TLS Working Groups.  No dissent was reported.  All
  comments have been addressed.

Document Quality

  There appears to exist at least one implementation of each of the
  tls-server-end-point and tls-unique-for-telnet channel binding types.
  Implementations of tls-unique appear to be in progress.

Personnel

  Nicolas Williams is the Document Shepherd for this document.  Pasi
  Eronen is the Responsible Area Director.