doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7507.txt b/doc/rfc/rfc7507.txt
new file mode 100644
index 0000000..382405f
--- /dev/null
+++ b/doc/rfc/rfc7507.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        B. Moeller
+Request for Comments: 7507                                    A. Langley
+Updates: 2246, 4346, 4347, 5246, 6347                             Google
+Category: Standards Track                                     April 2015
+ISSN: 2070-1721
+
+
+            TLS Fallback Signaling Cipher Suite Value (SCSV)
+               for Preventing Protocol Downgrade Attacks
+
+Abstract
+
+   This document defines a Signaling Cipher Suite Value (SCSV) that
+   prevents protocol downgrade attacks on the Transport Layer Security
+   (TLS) and Datagram Transport Layer Security (DTLS) protocols.  It
+   updates RFCs 2246, 4346, 4347, 5246, and 6347.  Server update
+   considerations are included.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7507.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 1]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Protocol Values . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
+   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   To work around interoperability problems with legacy servers, many
+   TLS client implementations do not rely on the TLS protocol version
+   negotiation mechanism alone but will intentionally reconnect using a
+   downgraded protocol if initial handshake attempts fail.  Such clients
+   may fall back to connections in which they announce a version as low
+   as TLS 1.0 (or even its predecessor, Secure Socket Layer (SSL) 3.0)
+   as the highest supported version.
+
+   While such fallback retries can be a useful last resort for
+   connections to actual legacy servers, there's a risk that active
+   attackers could exploit the downgrade strategy to weaken the
+   cryptographic security of connections.  Also, handshake errors due to
+   network glitches could similarly be misinterpreted as interaction
+   with a legacy server and result in a protocol downgrade.
+
+   All unnecessary protocol downgrades are undesirable (e.g., from TLS
+   1.2 to TLS 1.1, if both the client and the server actually do support
+   TLS 1.2); they can be particularly harmful when the result is loss of
+   the TLS extension feature by downgrading to SSL 3.0.  This document
+   defines an SCSV that can be employed to prevent unintended protocol
+   downgrades between clients and servers that comply with this document
+   by having the client indicate that the current connection attempt is
+   merely a fallback and by having the server return a fatal alert if it
+   detects an inappropriate fallback.  (The alert does not necessarily
+   indicate an intentional downgrade attack, since network glitches too
+   could result in inappropriate fallback retries.)
+
+
+
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 2]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+   The fallback SCSV defined in this document is not a suitable
+   substitute for proper TLS version negotiation.  TLS implementations
+   need to properly handle TLS version negotiation and extensibility
+   mechanisms to avoid the security issues and connection delays
+   associated with fallback retries.
+
+   This specification applies to implementations of TLS 1.0 [RFC2246],
+   TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of
+   DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347].  (It is particularly
+   relevant if the TLS implementations also include support for
+   predecessor protocol SSL 3.0 [RFC6101].)  It can be applied similarly
+   to later protocol versions.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Protocol Values
+
+   This document defines a new TLS cipher suite value:
+
+        TLS_FALLBACK_SCSV          {0x56, 0x00}
+
+   This is an SCSV, i.e., it does not actually correspond to a suite of
+   cryptosystems, and it can never be selected by the server in the
+   handshake; rather, its presence in the Client Hello message serves as
+   a backwards-compatible signal from the client to the server.
+
+   This document also allocates a new alert value in the TLS Alert
+   Registry [RFC5246]:
+
+        enum {
+          /* ... */
+          inappropriate_fallback(86),
+          /* ... */
+          (255)
+        } AlertDescription;
+
+   This alert is only generated by servers, as described in Section 3.
+   It is always fatal.
+
+
+
+
+
+
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 3]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+3.  Server Behavior
+
+   This section specifies server behavior when receiving the
+   TLS_FALLBACK_SCSV cipher suite from a client in
+   ClientHello.cipher_suites.
+
+   o  If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
+      highest protocol version supported by the server is higher than
+      the version indicated in ClientHello.client_version, the server
+      MUST respond with a fatal inappropriate_fallback alert (unless it
+      responds with a fatal protocol_version alert because the version
+      indicated in ClientHello.client_version is unsupported).  The
+      record layer version number for this alert MUST be set to either
+      ClientHello.client_version (as it would for the Server Hello
+      message if the server was continuing the handshake) or to the
+      record layer version number used by the client.
+
+   o  Otherwise (either TLS_FALLBACK_SCSV does not appear or it appears
+      and the client's protocol version is at least the highest protocol
+      version supported by the server), the server proceeds with the
+      handshake as usual.
+
+   (A protocol version is supported by the server if, in response to
+   appropriate Client Hello messages, the server would use it for
+   ServerHello.server_version.  If a particular protocol version is
+   implemented but completely disabled by server settings, it is not
+   considered supported.  For example, if the implementation's highest
+   protocol version is TLS 1.2 but the server operator has disabled this
+   version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV does not
+   warrant responding with an inappropriate_fallback alert.)
+
+4.  Client Behavior
+
+   The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients
+   that repeat a connection attempt with a downgraded protocol (perform
+   a "fallback retry") in order to work around interoperability problems
+   with legacy servers.
+
+   o  If a client sends a ClientHello.client_version containing a lower
+      value than the latest (highest-valued) version supported by the
+      client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
+      in ClientHello.cipher_suites; see Section 6 for security
+      considerations for this recommendation.  (The client SHOULD put
+      TLS_FALLBACK_SCSV after all cipher suites that it actually intends
+      to negotiate.)
+
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 4]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+   o  As an exception to the above, when a client intends to resume a
+      session and sets ClientHello.client_version to the protocol
+      version negotiated for that session, it MUST NOT include
+      TLS_FALLBACK_SCSV in ClientHello.cipher_suites.  (In this case, it
+      is assumed that the client already knows the highest protocol
+      version supported by the server: see Appendix E.1 of [RFC5246].)
+
+   o  If a client sets ClientHello.client_version to its highest
+      supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV
+      in ClientHello.cipher_suites.
+
+   (A protocol version is supported by the client if the client normally
+   attempts to use it in handshakes.  If a particular protocol version
+   is implemented but completely disabled by client settings, it is not
+   considered supported.  For example, if the implementation's highest
+   protocol version is TLS 1.2 but the user has disabled this version, a
+   TLS 1.1 handshake is expected and does not warrant sending
+   TLS_FALLBACK_SCSV.)
+
+   Fallback retries could be caused by events such as network glitches,
+   and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites
+   may receive an inappropriate_fallback alert in response, indicating
+   that the server supports a higher protocol version.  Thus, if a
+   client intends to use retries to work around network glitches, it
+   should then retry with the highest version it supports.
+
+   If a client keeps track of the highest protocol version apparently
+   supported by a particular server for use in
+   ClientHello.client_version later, then if the client receives an
+   inappropriate_fallback alert from that server, it MUST clear the
+   memorized highest supported protocol version.  (Without the alert, it
+   is a good idea -- but outside of the scope of this document -- for
+   clients to clear that state after a timeout since the server's
+   highest protocol version could change over time.)
+
+   For clients that use client-side TLS False Start [false-start], it is
+   important to note that the TLS_FALLBACK_SCSV mechanism cannot protect
+   the first round of application data sent by the client: refer to the
+   Security Considerations (Section 6) of [false-start].
+
+5.  Operational Considerations
+
+   Updating legacy server clusters to simultaneously add support for
+   newer protocol versions and support for TLS_FALLBACK_SCSV can have
+   complications if the legacy server implementation is not "version-
+   tolerant" (cannot properly handle Client Hello messages for newer
+   protocol versions): fallback retries required for interoperability
+   with old server nodes might be rejected by updated server nodes.
+
+
+
+Moeller & Langley            Standards Track                    [Page 5]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+   Updating the server cluster in two consecutive steps makes this safe:
+   first, update the server software but leave the highest supported
+   version unchanged (by disabling newer versions in server settings);
+   then, after all legacy (version-intolerant) implementations have been
+   removed, change server settings to allow new protocol versions.
+
+6.  Security Considerations
+
+   Section 4 does not require client implementations to send
+   TLS_FALLBACK_SCSV in any particular case, it merely recommends it;
+   behavior can be adapted according to the client's security needs.  It
+   is important to remember that omitting TLS_FALLBACK_SCSV enables
+   downgrade attacks, so implementors must take into account whether the
+   protocol version given by ClientHello.client_version still provides
+   an acceptable level of protection.  For example, during the initial
+   deployment of a new protocol version (when some interoperability
+   problems may have to be expected), smoothly falling back to the
+   previous protocol version in case of problems may be preferable to
+   potentially not being able to connect at all: so TLS_FALLBACK_SCSV
+   could be omitted for this particular protocol downgrade step.
+
+   However, it is strongly recommended to send TLS_FALLBACK_SCSV when
+   downgrading to SSL 3.0 as the Cipher Block Chaining (CBC) cipher
+   suites in SSL 3.0 have weaknesses that cannot be addressed by
+   implementation workarounds like the remaining weaknesses in later
+   (TLS) protocol versions.
+
+7.  IANA Considerations
+
+   IANA has added TLS cipher suite number 0x56,0x00 with the name
+   TLS_FALLBACK_SCSV to the TLS Cipher Suite Registry and alert number
+   86 with the name inappropriate_fallback to the TLS Alert Registry, as
+   shown below.  The registries are available from
+   <http://www.iana.org/assignments/tls-parameters>.
+
+          +-----------+-------------------+---------+-----------+
+          |   Value   |    Description    | DTLS-OK | Reference |
+          +-----------+-------------------+---------+-----------+
+          | 0x56,0x00 | TLS_FALLBACK_SCSV |    Y    |  RFC 7507 |
+          +-----------+-------------------+---------+-----------+
+
+                 Addition to the TLS Cipher Suite Registry
+
+
+
+
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 6]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+         +-------+------------------------+---------+-----------+
+         | Value |      Description       | DTLS-OK | Reference |
+         +-------+------------------------+---------+-----------+
+         |   86  | inappropriate_fallback |    Y    |  RFC 7507 |
+         +-------+------------------------+---------+-----------+
+
+                    Addition to the TLS Alert Registry
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999,
+              <http://www.rfc-editor.org/info/rfc2246>.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006,
+              <http://www.rfc-editor.org/info/rfc4346>.
+
+   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, April 2006,
+              <http://www.rfc-editor.org/info/rfc4347>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, January 2012,
+              <http://www.rfc-editor.org/info/rfc6347>.
+
+8.2.  Informative References
+
+   [RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
+              Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
+              August 2011, <http://www.rfc-editor.org/info/rfc6101>.
+
+   [false-start]
+              Langley, A., Modadugu, N., and B. Moeller, "Transport
+              Layer Security (TLS) False Start", Work in Progress,
+              draft-bmoeller-tls-falsestart-01, November 2014.
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 7]
+
+RFC 7507                    TLS Fallback SCSV                 April 2015
+
+
+Acknowledgements
+
+   This specification was inspired by an earlier proposal by Eric
+   Rescorla.  We also thank Daniel Kahn Gillmor, Joe Saloway, Brian
+   Smith, Martin Thomson, and others in the TLS Working Group for their
+   feedback and suggestions.
+
+Authors' Addresses
+
+   Bodo Moeller
+   Google Switzerland GmbH
+   Brandschenkestrasse 110
+   Zurich  8002
+   Switzerland
+
+   EMail: bmoeller@acm.org
+
+
+   Adam Langley
+   Google Inc.
+   345 Spear St
+   San Francisco, CA  94105
+   United States
+
+   EMail: agl@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moeller & Langley            Standards Track                    [Page 8]
+