The Transport Layer Security (TLS) Protocol Version 1.2
draft-ietf-tls-rfc4346-bis-10

As this is a critical IETF standard for application protocols, I have
reviewed it in depth.  While the protocol is more complex then I might
wish, it takes an appropriate compromise between the necessary hash
agility to future-proof TLS, backwards compatibility with previous TLS
versions and simplicity.  I consider this revision an important and
necessary step forward for TLS.

I am aware of TLS interoperability problems with wildcard server
certificates and client certificates used by application protocols. 
This specification chooses to avoid all issues of application use of
TLS.  After a discussion with Ekr, I believe this is best addressed by
an "application use of TLS" BCP rather than delaying this document.

I have a number of minor comments and it is my belief a revision of the
document addressing some or all of my comments would improve the
document's value sufficiently to merit the delay.  I don't consider any
of these discuss-level blocking comments, however.

Section 4.7:

The acronym "DER" is first used in the context of a normative reference
to RFC 3447 (PKCS#1).  However, RFC 3447 does not define nor provide a
direct reference to either DER or ASN.1, although those are normative to
implementing this portion of TLS (given the "MUST").  I suggest adding
normative references to ASN.1/DER and/or expanding the "DER" acronym on
first use.  A previous RFC that normatively referenced RFC 3447 was RFC
4556 and it included the following normative references:

   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
              Information technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation.

   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              Information technology - ASN.1 encoding Rules: Specification
              of Basic Encoding Rules (BER), Canonical Encoding Rules
              (CER) and Distinguished Encoding Rules (DER).

Section 6.2.2:

While RFC 3749 (TLS Compression) is referenced from the IANA
considerations section, it would also be helpful to implementers to
reference it from the compression section 6.2.2.  It's fine as an
informative reference.

Section 6.2.3.1, last paragraph, last sentence:

This sentence:
>   TLSCiphertext.length is TLSCompressed.length plus
>   SecurityParameters.mac_length.
doesn't have a clear context (it's not clear if it refers to the null
cipher, stream cipher, both or all ciphers).  I suggest clairifying this
similar to the equivalent statement in the next section:
   The null or stream cipher length (TLSCiphertext.length) is
   TLSCompressed.length plus SecurityParameters.mac_length.

Section 7.4.1.2, page 40 "session_id":
>      The ID of a session the client wishes to use for this connection.
>      This field is empty if no session_id is available, or it the
s/it/if/

Section 7.4.1.2, page 40 "extensions":
>      Clients MAY request extended functionality from servers by sending
>      data in the extensions Here the new "extensions" field contains a
>      list of extensions.
This needs rewording.

Section 7.4.1.3, "session_id" last sentence:
>      session_id. Client MUST be prepared to do a full negotiation --
s/Client/Clients/

Section 7.4.1.4:
>          signature_algorithms(TBD-BY-IANA), (65535)
I suggest an explicit note to RFC editor to make sure this occurrance of
TBD-BY-IANA is changed to the registered number.  Alternatively, the
text in section 12 should specifically mention this item in this section
needs to be replaced by the registered number.

Section 7.4.1.4.1, "signature":
>      This field indicates the signature algorithm which may be used.
>      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
>      [PKCS1] and DSA [DSS] respectively.
This sentence is missing a reference for ECDSA.

Section 7.4.1.4.1:
>   cipher suite indicates permissible signature algorithms but not hash
>   algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
s/algorithm/algorithms/

Section 7.4.2, "certificate_list":
>      certificate authority MAY optionally be omitted from the chain,
s/MAY optionally/MAY/
("MAY optionally" is redundant as "MAY" implies the behavior is optional)

Section 7.4.2:
>      ECDHE_RSA          allow the key to be used for signing
It would be helpful to mention this cipher suite is defined in [TLSECC]
here.

Section 7.4.2:
>   extension.  The naming is historical.
I'm not sure which "naming" is referred to by this sentence.  Perhaps
clarification is needed?

Section 7.4.3:
>         DHE_DSS
>         DHE_RSA
>         DH_anon
This is also true for "ECDHE_RSA", "ECDHE_DSS", "ECDH_anon" I believe.
While I know those cipher suites are defined in RFC 4492 rather than
here, it's confusing to have them discussed in the previous section and
suddenly missing in this section.  Either say explicitly you're omitting
them from this section or include them in this discussion.

Section 7.4.8:
>      permitted hash algorith, subject to restrictions in the
s/algorith/algorithm/

Section A.7:
>   to be used and digest algorithms other than SHA-1, provided such use
s/and/with/

Section E.1:
>   remains compatible, and the client support the highest protocol
s/support/supports/
...
>   A TLS server can also receive a ClientHello containing version number
s/containing version/containing a version/

Informative References:

The XDR reference should mention it is STD 67:
   [XDR]    Eisler, M., "External Data Representation Standard", STD
            67, RFC 4506, May 2006.

> a SHOULD, with sending it a SHOULD not. Support will probably

s/SHOULD not/SHOULD NOT/

Section 1.2 does not list the change that unnegotiated extensions now result in a fatal alert, not silently dropping the message. (Section 6)

> This document
> describes TLS Version 1.2, which uses the version { 3, 3 }. The
> version value 3.3 is historical, deriving from the use of 3.1 for
> TLS 1.0. (See Appendix A.1).

This was somewhat confusing, because I do not know when you are talking
of values for the "version" field and when you are talking about the
version numbers associated with a particular TLS RFC. I think you 
want to say:

  This document
  describes TLS Version 1.2, which uses the version { 3, 3 }. The
  version value { 3, 3 } is historical, deriving from the use of { 3, 1 }
  for TLS 1.0. (See Appendix A.1).

By the way, differences from RFC 4346 are easily seen in 
http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/rfc/rfc4346.txt&url2=http://tools.ietf.org/id/draft-ietf-tls-rfc4346-bis-09.txt