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