The Transport Layer Security (TLS) Protocol Version 1.2
draft-ietf-tls-rfc4346-bis-10
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Chris Newman; former steering group member) Yes
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.
(Jari Arkko; former steering group member) Yes
> 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
(Tim Polk; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection