| < draft-ietf-tls-ssl2-must-not-03.txt | draft-ietf-tls-ssl2-must-not-04.txt > | |||
|---|---|---|---|---|
| Network Working Group S. Turner | Network Working Group S. Turner | |||
| Internet Draft IECA | Internet Draft IECA | |||
| Updates: 5246, 4346, 2246 (once approved) T. Polk | Updates: 5246, 4346, 2246 (once approved) T. Polk | |||
| Intended Status: Standards Track NIST | Intended Status: Standards Track NIST | |||
| Expires: May 29, 2011 November 29, 2010 | Expires: June 16, 2011 December 16, 2010 | |||
| Prohibiting SSL Version 2.0 | Prohibiting SSL Version 2.0 | |||
| draft-ietf-tls-ssl2-must-not-03.txt | draft-ietf-tls-ssl2-must-not-04.txt | |||
| Abstract | Abstract | |||
| This document requires that when TLS clients and servers establish | This document requires that when TLS clients and servers establish | |||
| connections that they never negotiate the use of Secure Sockets Layer | connections that they never negotiate the use of Secure Sockets Layer | |||
| (SSL) version 2.0. This document updates the backward compatibility | (SSL) version 2.0. This document updates the backward compatibility | |||
| sections found in the Transport Security Layer (TLS). | sections found in the Transport Security Layer (TLS). | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on May 29, 2009. | This Internet-Draft will expire on May 16, 2009. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| 1. Introduction | 1. Introduction | |||
| Many protocols specified in the IETF rely on Transport Layer Security | Many protocols specified in the IETF rely on Transport Layer Security | |||
| (TLS) [TLS1.0][TLS1.1][TLS1.2] for security services. This is a good | (TLS) [TLS1.0][TLS1.1][TLS1.2] for security services. This is a good | |||
| thing, but some TLS clients and servers also support negotiating the | thing, but some TLS clients and servers also support negotiating the | |||
| use of Secure Sockets Layer (SSL) version 2.0 [SSL2]; however, this | use of Secure Sockets Layer (SSL) version 2.0 [SSL2]; however, this | |||
| version does not provide the expected level of security. SSL version | version does not provide a sufficiently high level of security. SSL | |||
| 2.0 has known deficiencies. This document describes those | version 2.0 has known deficiencies. This document describes those | |||
| deficiencies, and it requires TLS clients and servers never negotiate | deficiencies, and it requires TLS clients and servers never negotiate | |||
| the use of SSL version 2.0. | the use of SSL version 2.0. | |||
| This document updates the backward compatibility sections found in | TLS 1.1 [RFC4346] and later in TLS 1.2 [RFC5246] explicitly warned | |||
| TLS [TLS1.0][TLS1.1][TLS1.2]. | implementers that the "ability to send version 2.0 CLIENT-HELLO | |||
| messages will be phased out with all due haste." This document | ||||
| accomplishes this by updating the backward compatibility sections | ||||
| found in TLS [TLS1.0][TLS1.1][TLS1.2]. | ||||
| 1.1. Requirements Terminology | 1.1. Requirements Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | [RFC2119]. | |||
| 2. SSL 2.0 Deficiencies | 2. SSL 2.0 Deficiencies | |||
| skipping to change at page 3, line 13 ¶ | skipping to change at page 3, line 17 ¶ | |||
| algorithm. | algorithm. | |||
| o Sessions can be easily terminated. A man-in-the-middle can easily | o Sessions can be easily terminated. A man-in-the-middle can easily | |||
| insert a TCP FIN to close the session and the peer is unable to | insert a TCP FIN to close the session and the peer is unable to | |||
| determine whether or not it was a legitimate end of the session. | determine whether or not it was a legitimate end of the session. | |||
| 3. Changes to TLS | 3. Changes to TLS | |||
| Because of the deficiencies noted in the previous section: | Because of the deficiencies noted in the previous section: | |||
| o TLS clients MUST NOT negotiate or use SSL 2.0. | o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT- | |||
| HELLO message format. Clients MUST NOT send any client hello | ||||
| message which specifies a protocol version less than | ||||
| { 0x03, 0x00 }. As previously stated by the definitions of all | ||||
| previous versions of TLS, the client SHOULD specify the highest | ||||
| protocol version it supports. | ||||
| o TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO messages. | o TLS servers MAY continue to accept CLIENT-HELLO messages in the | |||
| version 2 CLIENT-HELLO format as specified in TLS 1.2 [RFC5246] | ||||
| Appendix E.2. Note that this does not contradict the prohibition | ||||
| against actually negotiating the use of SSL 2.0. | ||||
| o TLS servers MUST NOT negotiate or use SSL 2.0. | TLS Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a | |||
| protocol version which is less than { 0x03, 0x00 } and instead | ||||
| MUST abort the connection, i.e., when the highest protocol version | ||||
| offered by the client is { 0x02, 0x00 } the TLS connection will be | ||||
| refused. | ||||
| As described in TLSv1.2 ([TLS1.2] Appendix E.2), TLS servers that do | Note that the number of servers that support this above-mentioned | |||
| not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages as | "MAY accept" implementation option is declining, and the SSL 2.0 | |||
| the first message of a TLS handshake for interoperability with old | CLIENT-HELLO precludes the use of TLS protocol enhancements that | |||
| clients. | require TLS extensions. TLS extensions can only be sent as part of an | |||
| (Extended) ClientHello handshake message. | ||||
| 4. IANA Considerations | 4. IANA Considerations | |||
| None. | None. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| This entire document is about security considerations. | This entire document is about security considerations. | |||
| 6. Acknowledgements | 6. Acknowledgements | |||
| skipping to change at page 3, line 36 ¶ | skipping to change at page 4, line 4 ¶ | |||
| None. | None. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| This entire document is about security considerations. | This entire document is about security considerations. | |||
| 6. Acknowledgements | 6. Acknowledgements | |||
| The idea for this document was inspired by discussions between Peter | The idea for this document was inspired by discussions between Peter | |||
| Saint Andre, Simon Josefsson, and others on the XMPP mailing list. | Saint Andre, Simon Josefsson, and others on the XMPP mailing list. | |||
| We would also like to thank Michael D'Errico, Paul Hoffman, Nikos | We would also like to thank Michael D'Errico, Paul Hoffman, Nikos | |||
| Mavrogiannopoulos, Tom Petch, Yngve Pettersen, Marsh Ray, Martin Rex, | Mavrogiannopoulos, Tom Petch, Yngve Pettersen, Marsh Ray, Martin Rex, | |||
| and Yaron Sheffer for their reviews and comments. | Yaron Sheffer, and Glen Zorn for their reviews and comments. | |||
| 7. References | 7. References | |||
| 7.1. Normative References | 7.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol Version | [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol Version | |||
| 1.0", RFC 2246, January 1999. | 1.0", RFC 2246, January 1999. | |||
| End of changes. 11 change blocks. | ||||
| 15 lines changed or deleted | 32 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||