doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5746.txt b/doc/rfc/rfc5746.txt
new file mode 100644
index 0000000..4f071e8
--- /dev/null
+++ b/doc/rfc/rfc5746.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       E. Rescorla
+Request for Comments: 5746                                    RTFM, Inc.
+Updates: 5246, 4366, 4347, 4346, 2246                             M. Ray
+Category: Standards Track                                    S. Dispensa
+ISSN: 2070-1721                                              PhoneFactor
+                                                                N. Oskov
+                                                               Microsoft
+                                                           February 2010
+
+
+   Transport Layer Security (TLS) Renegotiation Indication Extension
+
+Abstract
+
+   Secure Socket Layer (SSL) and Transport Layer Security (TLS)
+   renegotiation are vulnerable to an attack in which the attacker forms
+   a TLS connection with the target server, injects content of his
+   choice, and then splices in a new TLS connection from a client.  The
+   server treats the client's initial TLS handshake as a renegotiation
+   and thus believes that the initial data transmitted by the attacker
+   is from the same entity as the subsequent client data.  This
+   specification defines a TLS extension to cryptographically tie
+   renegotiations to the TLS connections they are being performed over,
+   thus preventing this attack.
+
+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/rfc5746.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 1]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions Used in This Document ...............................4
+   3. Secure Renegotiation Definition .................................4
+      3.1. Additional Connection State ................................4
+      3.2. Extension Definition .......................................5
+      3.3. Renegotiation Protection Request Signaling Cipher
+           Suite Value ................................................6
+      3.4. Client Behavior: Initial Handshake .........................6
+      3.5. Client Behavior: Secure Renegotiation ......................7
+      3.6. Server Behavior: Initial Handshake .........................7
+      3.7. Server Behavior: Secure Renegotiation ......................8
+   4. Backward Compatibility ..........................................9
+      4.1. Client Considerations ......................................9
+      4.2. Client Behavior: Legacy (Insecure) Renegotiation ..........10
+      4.3. Server Considerations .....................................10
+      4.4. Server Behavior: Legacy (Insecure) Renegotiation ..........11
+      4.5. SSLv3 .....................................................11
+   5. Security Considerations ........................................12
+   6. IANA Considerations ............................................13
+   7. Acknowledgements ...............................................13
+   8. References .....................................................13
+      8.1. Normative References ......................................13
+      8.2. Informative References ....................................13
+
+
+
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 2]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+1.  Introduction
+
+   TLS [RFC5246] allows either the client or the server to initiate
+   renegotiation -- a new handshake that establishes new cryptographic
+   parameters.  Unfortunately, although the new handshake is carried out
+   using the cryptographic parameters established by the original
+   handshake, there is no cryptographic binding between the two.  This
+   creates the opportunity for an attack in which the attacker who can
+   intercept a client's transport layer connection can inject traffic of
+   his own as a prefix to the client's interaction with the server.  One
+   form of this attack [Ray09] proceeds as shown below:
+
+   Client                        Attacker                        Server
+   ------                        -------                         ------
+                                     <----------- Handshake ---------->
+                                     <======= Initial Traffic ========>
+   <--------------------------  Handshake ============================>
+   <======================== Client Traffic ==========================>
+
+   To start the attack, the attacker forms a TLS connection to the
+   server (perhaps in response to an initial intercepted connection from
+   the client).  He then sends any traffic of his choice to the server.
+   This may involve multiple requests and responses at the application
+   layer, or may simply be a partial application layer request intended
+   to prefix the client's data.  This traffic is shown with == to
+   indicate it is encrypted.  He then allows the client's TLS handshake
+   to proceed with the server.  The handshake is in the clear to the
+   attacker but encrypted over the attacker's TLS connection to the
+   server.  Once the handshake has completed, the client communicates
+   with the server over the newly established security parameters with
+   the server.  The attacker cannot read this traffic, but the server
+   believes that the initial traffic to and from the attacker is the
+   same as that to and from the client.
+
+   If certificate-based client authentication is used, the server will
+   see a stream of bytes where the initial bytes are protected but
+   unauthenticated by TLS and subsequent bytes are authenticated by TLS
+   and bound to the client's certificate.  In some protocols (notably
+   HTTPS), no distinction is made between pre- and post-authentication
+   stages and the bytes are handled uniformly, resulting in the server
+   believing that the initial traffic corresponds to the authenticated
+   client identity.  Even without certificate-based authentication, a
+   variety of attacks may be possible in which the attacker convinces
+   the server to accept data from it as data from the client.  For
+   instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965],
+   the attacker may be able to generate a request of his choice
+   validated by the client's cookie.
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 3]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   Some protocols -- such as IMAP or SMTP -- have more explicit
+   transitions between authenticated and unauthenticated phases and
+   require that the protocol state machine be partly or fully reset at
+   such transitions.  If strictly followed, these rules may limit the
+   effect of attacks.  Unfortunately, there is no requirement for state
+   machine resets at TLS renegotiation, and thus there is still a
+   potential window of vulnerability, for instance, by prefixing a
+   command that writes to an area visible by the attacker with a command
+   by the client that includes his password, thus making the client's
+   password visible to the attacker (note that this precise attack does
+   not work with challenge-response authentication schemes, but other
+   attacks may be possible).  Similar attacks are available with SMTP,
+   and in fact do not necessarily require the attacker to have an
+   account on the target server.
+
+   It is important to note that in both cases these attacks are possible
+   because the client sends unsolicited authentication information
+   without requiring any specific data from the server over the TLS
+   connection.  Protocols that require a round trip to the server over
+   TLS before the client sends sensitive information are likely to be
+   less vulnerable.
+
+   These attacks can be prevented by cryptographically binding
+   renegotiation handshakes to the enclosing TLS cryptographic
+   parameters, thus allowing the server to differentiate renegotiation
+   from initial negotiation, as well as preventing renegotiations from
+   being spliced in between connections.  An attempt by an attacker to
+   inject himself as described above will result in a mismatch of the
+   cryptographic binding and can thus be detected.  The data used in the
+   extension is similar to, but not the same as, the data used in the
+   tls-unique and/or tls-unique-for-telnet channel bindings described in
+   [TLS-CHANNEL-BINDINGS]; however, this extension is not a general-
+   purpose RFC 5056 [RFC5056] channel binding facility.
+
+2.  Conventions Used in This Document
+
+   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].
+
+3.  Secure Renegotiation Definition
+
+3.1.  Additional Connection State
+
+   Both client and server need to store three additional values for each
+   TLS connection state (see RFC 5246, Section 6.1).  Note that these
+   values are specific to connection (not a TLS session cache entry).
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 4]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   o  a "secure_renegotiation" flag, indicating whether secure
+      renegotiation is in use for this connection.
+
+   o  "client_verify_data":  the verify_data from the Finished message
+      sent by the client on the immediately previous handshake.  For
+      currently defined TLS versions and cipher suites, this will be a
+      12-byte value; for SSLv3, this will be a 36-byte value.
+
+   o  "server_verify_data":  the verify_data from the Finished message
+      sent by the server on the immediately previous handshake.
+
+3.2.  Extension Definition
+
+   This document defines a new TLS extension, "renegotiation_info" (with
+   extension type 0xff01), which contains a cryptographic binding to the
+   enclosing TLS connection (if any) for which the renegotiation is
+   being performed.  The "extension data" field of this extension
+   contains a "RenegotiationInfo" structure:
+
+      struct {
+          opaque renegotiated_connection<0..255>;
+      } RenegotiationInfo;
+
+   The contents of this extension are specified as follows.
+
+   o  If this is the initial handshake for a connection, then the
+      "renegotiated_connection" field is of zero length in both the
+      ClientHello and the ServerHello.  Thus, the entire encoding of the
+      extension is ff 01 00 01 00.  The first two octets represent the
+      extension type, the third and fourth octets the length of the
+      extension itself, and the final octet the zero length byte for the
+      "renegotiated_connection" field.
+
+   o  For ClientHellos that are renegotiating, this field contains the
+      "client_verify_data" specified in Section 3.1.
+
+   o  For ServerHellos that are renegotiating, this field contains the
+      concatenation of client_verify_data and server_verify_data.  For
+      current versions of TLS, this will be a 24-byte value (for SSLv3,
+      it will be a 72-byte value).
+
+   This extension also can be used with Datagram TLS (DTLS) [RFC4347].
+   Although, for editorial simplicity, this document refers to TLS, all
+   requirements in this document apply equally to DTLS.
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 5]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+3.3.  Renegotiation Protection Request Signaling Cipher Suite Value
+
+   Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require
+   implementations to ignore data following the ClientHello (i.e.,
+   extensions) if they do not understand it.  However, some SSLv3 and
+   TLS 1.0 implementations incorrectly fail the handshake in such a
+   case.  This means that clients that offer the "renegotiation_info"
+   extension may encounter handshake failures.  In order to enhance
+   compatibility with such servers, this document defines a second
+   signaling mechanism via a special Signaling Cipher Suite Value (SCSV)
+   "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}.
+   This SCSV is not a true cipher suite (it does not correspond to any
+   valid set of algorithms) and cannot be negotiated.  Instead, it has
+   the same semantics as an empty "renegotiation_info" extension, as
+   described in the following sections.  Because SSLv3 and TLS
+   implementations reliably ignore unknown cipher suites, the SCSV may
+   be safely sent to any server.  The SCSV can also be included in the
+   SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of
+   [RFC5246]).
+
+   Note:  a minimal client that does not support renegotiation at all
+   can simply use the SCSV in all initial handshakes.  The rules in the
+   following sections will cause any compliant server to abort the
+   handshake when it sees an apparent attempt at renegotiation by such a
+   client.
+
+3.4.  Client Behavior: Initial Handshake
+
+   Note that this section and Section 3.5 apply to both full handshakes
+   and session resumption handshakes.
+
+   o  The client MUST include either an empty "renegotiation_info"
+      extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling
+      cipher suite value in the ClientHello.  Including both is NOT
+      RECOMMENDED.
+
+   o  When a ServerHello is received, the client MUST check if it
+      includes the "renegotiation_info" extension:
+
+      *  If the extension is not present, the server does not support
+         secure renegotiation; set secure_renegotiation flag to FALSE.
+         In this case, some clients may want to terminate the handshake
+         instead of continuing; see Section 4.1 for discussion.
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 6]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+      *  If the extension is present, set the secure_renegotiation flag
+         to TRUE.  The client MUST then verify that the length of the
+         "renegotiated_connection" field is zero, and if it is not, MUST
+         abort the handshake (by sending a fatal handshake_failure
+         alert).
+
+         Note: later in Section 3, "abort the handshake" is used as
+         shorthand for "send a fatal handshake_failure alert and
+         terminate the connection".
+
+   o  When the handshake has completed, the client needs to save the
+      client_verify_data and server_verify_data values for future use.
+
+3.5.  Client Behavior: Secure Renegotiation
+
+   This text applies if the connection's "secure_renegotiation" flag is
+   set to TRUE (if it is set to FALSE, see Section 4.2).
+
+   o  The client MUST include the "renegotiation_info" extension in the
+      ClientHello, containing the saved client_verify_data.  The SCSV
+      MUST NOT be included.
+
+   o  When a ServerHello is received, the client MUST verify that the
+      "renegotiation_info" extension is present; if it is not, the
+      client MUST abort the handshake.
+
+   o  The client MUST then verify that the first half of the
+      "renegotiated_connection" field is equal to the saved
+      client_verify_data value, and the second half is equal to the
+      saved server_verify_data value.  If they are not, the client MUST
+      abort the handshake.
+
+   o  When the handshake has completed, the client needs to save the new
+      client_verify_data and server_verify_data values.
+
+3.6.  Server Behavior: Initial Handshake
+
+   Note that this section and Section 3.7 apply to both full handshakes
+   and session-resumption handshakes.
+
+   o  When a ClientHello is received, the server MUST check if it
+      includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV.  If it does,
+      set the secure_renegotiation flag to TRUE.
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 7]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   o  The server MUST check if the "renegotiation_info" extension is
+      included in the ClientHello.  If the extension is present, set
+      secure_renegotiation flag to TRUE.  The server MUST then verify
+      that the length of the "renegotiated_connection" field is zero,
+      and if it is not, MUST abort the handshake.
+
+   o  If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the
+      "renegotiation_info" extension was included, set the
+      secure_renegotiation flag to FALSE.  In this case, some servers
+      may want to terminate the handshake instead of continuing; see
+      Section 4.3 for discussion.
+
+   o  If the secure_renegotiation flag is set to TRUE, the server MUST
+      include an empty "renegotiation_info" extension in the ServerHello
+      message.
+
+   o  When the handshake has completed, the server needs to save the
+      client_verify_data and server_verify_data values for future use.
+
+   TLS servers implementing this specification MUST ignore any unknown
+   extensions offered by the client and they MUST accept version numbers
+   higher than their highest version number and negotiate the highest
+   common version.  These two requirements reiterate preexisting
+   requirements in RFC 5246 and are merely stated here in the interest
+   of forward compatibility.
+
+   Note that sending a "renegotiation_info" extension in response to a
+   ClientHello containing only the SCSV is an explicit exception to the
+   prohibition in RFC 5246, Section 7.4.1.4, on the server sending
+   unsolicited extensions and is only allowed because the client is
+   signaling its willingness to receive the extension via the
+   TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV.  TLS implementations MUST
+   continue to comply with Section 7.4.1.4 for all other extensions.
+
+3.7.  Server Behavior: Secure Renegotiation
+
+   This text applies if the connection's "secure_renegotiation" flag is
+   set to TRUE (if it is set to FALSE, see Section 4.4).
+
+   o  When a ClientHello is received, the server MUST verify that it
+      does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV.  If
+      the SCSV is present, the server MUST abort the handshake.
+
+   o  The server MUST verify that the "renegotiation_info" extension is
+      present; if it is not, the server MUST abort the handshake.
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 8]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   o  The server MUST verify that the value of the
+      "renegotiated_connection" field is equal to the saved
+      client_verify_data value; if it is not, the server MUST abort the
+      handshake.
+
+   o  The server MUST include a "renegotiation_info" extension
+      containing the saved client_verify_data and server_verify_data in
+      the ServerHello.
+
+   o  When the handshake has completed, the server needs to save the new
+      client_verify_data and server_verify_data values.
+
+4.  Backward Compatibility
+
+   Existing implementations that do not support this extension are
+   widely deployed and, in general, must interoperate with newer
+   implementations that do support it.  This section describes
+   considerations for backward compatible interoperation.
+
+4.1.  Client Considerations
+
+   If a client offers the "renegotiation_info" extension or the
+   TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply
+   with "renegotiation_info" in the ServerHello, then this indicates
+   that the server does not support secure renegotiation.  Because some
+   attacks (see Section 1) look like a single handshake to the client,
+   the client cannot determine whether or not the connection is under
+   attack.  Note, however, that merely because the server does not
+   acknowledge the extension does not mean that it is vulnerable; it
+   might choose to reject all renegotiations and simply not signal it.
+   However, it is not possible for the client to determine purely via
+   TLS mechanisms whether or not this is the case.
+
+   If clients wish to ensure that such attacks are impossible, they need
+   to terminate the connection immediately upon failure to receive the
+   extension without completing the handshake.  Such clients MUST
+   generate a fatal "handshake_failure" alert prior to terminating the
+   connection.  However, it is expected that many TLS servers that do
+   not support renegotiation (and thus are not vulnerable) will not
+   support this extension either, so in general, clients that implement
+   this behavior will encounter interoperability problems.  There is no
+   set of client behaviors that will guarantee security and achieve
+   maximum interoperability during the transition period.  Clients need
+   to choose one or the other preference when dealing with potentially
+   un-upgraded servers.
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                    [Page 9]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+4.2.  Client Behavior: Legacy (Insecure) Renegotiation
+
+   This text applies if the connection's "secure_renegotiation" flag is
+   set to FALSE.
+
+   It is possible that un-upgraded servers will request that the client
+   renegotiate.  It is RECOMMENDED that clients refuse this
+   renegotiation request.  Clients that do so MUST respond to such
+   requests with a "no_renegotiation" alert (RFC 5246 requires this
+   alert to be at the "warning" level).  It is possible that the
+   apparently un-upgraded server is in fact an attacker who is then
+   allowing the client to renegotiate with a different, legitimate,
+   upgraded server.  If clients nevertheless choose to renegotiate, they
+   MUST behave as described below.
+
+   Clients that choose to renegotiate MUST provide either the
+   TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in
+   their ClientHello.  In a legitimate renegotiation with an un-upgraded
+   server, that server should ignore both of these signals.  However, if
+   the server (incorrectly) fails to ignore extensions, sending the
+   "renegotiation_info" extension may cause a handshake failure.  Thus,
+   it is permitted, though NOT RECOMMENDED, for the client to simply
+   send the SCSV.  This is the only situation in which clients are
+   permitted to not send the "renegotiation_info" extension in a
+   ClientHello that is used for renegotiation.
+
+   Note that in the case of a downgrade attack, if this is an initial
+   handshake from the server's perspective, then use of the SCSV from
+   the client precludes detection of this attack by the server (if this
+   is a renegotiation from the server's perspective, then it will detect
+   the attack).  However, the attack will be detected by the client when
+   the server sends an empty "renegotiation_info" extension and the
+   client is expecting one containing the previous verify_data.  By
+   contrast, if the client sends the "renegotiation_info" extension,
+   then the server will immediately detect the attack.
+
+   When the ServerHello is received, the client MUST verify that it does
+   not contain the "renegotiation_info" extension.  If it does, the
+   client MUST abort the handshake.  (Because the server has already
+   indicated it does not support secure renegotiation, the only way that
+   this can happen is if the server is broken or there is an attack.)
+
+4.3.  Server Considerations
+
+   If the client does not offer the "renegotiation_info" extension or
+   the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that
+   the client does not support secure renegotiation.  Although the
+   attack described in Section 1 looks like two handshakes to the
+
+
+
+Rescorla, et al.             Standards Track                   [Page 10]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   server, other attacks may be possible in which the renegotiation is
+   seen only by the client.  If servers wish to ensure that such attacks
+   are impossible, they need to terminate the connection immediately
+   upon failure to negotiate the use of secure renegotiation.  Servers
+   that do choose to allow connections from unpatched clients can still
+   prevent the attack described in Section 1 by refusing to renegotiate
+   over those connections.
+
+   In order to enable clients to probe, even servers that do not support
+   renegotiation MUST implement the minimal version of the extension
+   described in this document for initial handshakes, thus signaling
+   that they have been upgraded.
+
+4.4.  Server Behavior: Legacy (Insecure) Renegotiation
+
+   This text applies if the connection's "secure_renegotiation" flag is
+   set to FALSE.
+
+   It is RECOMMENDED that servers not permit legacy renegotiation.  If
+   servers nevertheless do permit it, they MUST follow the requirements
+   in this section.
+
+   o  When a ClientHello is received, the server MUST verify that it
+      does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV.  If
+      the SCSV is present, the server MUST abort the handshake.
+
+   o  The server MUST verify that the "renegotiation_info" extension is
+      not present; if it is, the server MUST abort the handshake.
+
+4.5.  SSLv3
+
+   While SSLv3 is not a protocol under IETF change control (see
+   [SSLv3]), it was the original basis for TLS and most TLS
+   implementations also support SSLv3.  The IETF encourages SSLv3
+   implementations to adopt the "renegotiation_info" extension and SCSV
+   as defined in this document.  The semantics of the SCSV and extension
+   are identical to TLS stacks except for the size of the verify_data
+   values, which are 36 bytes long each.  Note that this will require
+   adding at least minimal extension processing to such stacks.  Clients
+   that support SSLv3 and offer secure renegotiation (either via SCSV or
+   "renegotiation_info") MUST accept the "renegotiation_info" extension
+   from the server, even if the server version is {0x03, 0x00}, and
+   behave as described in this specification.  TLS servers that support
+   secure renegotiation and support SSLv3 MUST accept SCSV or the
+   "renegotiation_info" extension and respond as described in this
+   specification even if the offered client version is {0x03, 0x00}.
+   SSLv3 does not define the "no_renegotiation" alert (and does
+
+
+
+
+Rescorla, et al.             Standards Track                   [Page 11]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   not offer a way to indicate a refusal to renegotiate at a "warning"
+   level).  SSLv3 clients that refuse renegotiation SHOULD use a fatal
+   handshake_failure alert.
+
+5.  Security Considerations
+
+   The extension described in this document prevents an attack on TLS.
+   If this extension is not used, TLS renegotiation is subject to an
+   attack in which the attacker can inject their own conversation with
+   the TLS server as a prefix to the client's conversation.  This attack
+   is invisible to the client and looks like an ordinary renegotiation
+   to the server.  The extension defined in this document allows
+   renegotiation to be performed safely.  Servers SHOULD NOT allow
+   clients to renegotiate without using this extension.  Many servers
+   can mitigate this attack simply by refusing to renegotiate at all.
+
+   While this extension mitigates the man-in-the-middle attack described
+   in the overview, it does not resolve all possible problems an
+   application may face if it is unaware of renegotiation.  For example,
+   during renegotiation, either the client or the server can present a
+   different certificate than was used earlier.  This may come as a
+   surprise to application developers (who might have expected, for
+   example, that a "getPeerCertificates()" API call returns the same
+   value if called twice), and might be handled in an insecure way.
+
+   TLS implementations SHOULD provide a mechanism to disable and enable
+   renegotiation.
+
+   TLS implementers are encouraged to clearly document how renegotiation
+   interacts with the APIs offered to applications (for example, which
+   API calls might return different values on different calls, or which
+   callbacks might get called multiple times).
+
+   To make life simpler for applications that use renegotiation but do
+   not expect the certificate to change once it has been authenticated,
+   TLS implementations may also wish to offer the applications the
+   option to abort the renegotiation if the peer tries to authenticate
+   with a different certificate and/or different server name (in the
+   server_name extension) than was used earlier.  TLS implementations
+   may alternatively offer the option to disable renegotiation once the
+   client certificate has been authenticated.  However, enabling these
+   options by default for all applications could break existing
+   applications that depend on using renegotiation to change from one
+   certificate to another.  (For example, long-lived TLS connections
+   could change to a renewed certificate; or renegotiation could select
+   a different cipher suite that requires using a different
+   certificate.)
+
+
+
+
+Rescorla, et al.             Standards Track                   [Page 12]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   Finally, designers of applications that depend on renegotiation are
+   reminded that many TLS APIs represent application data as a simple
+   octet stream; applications may not be able to determine exactly which
+   application data octets were received before, during, or after
+   renegotiation.  Especially if the peer presents a different
+   certificate during renegotiation, care is needed when specifying how
+   the application should handle the data.
+
+6.  IANA Considerations
+
+   IANA has added the extension code point 65281 (0xff01), which has
+   been used for prototype implementations, for the "renegotiation_info"
+   extension to the TLS ExtensionType values registry.
+
+   IANA has added TLS cipher suite number 0x00,0xFF with name
+   TLS_EMPTY_RENEGOTIATION_INFO_SCSV to the TLS Cipher Suite registry.
+
+7.  Acknowledgements
+
+   This vulnerability was originally discovered by Marsh Ray and
+   independently rediscovered by Martin Rex.  The general concept behind
+   the extension described here was independently invented by Steve
+   Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson
+   Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael
+   Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller,
+   Martin Rex, Peter Robinson, Jesse Walker, Nico Williams, and other
+   members of the Project Mogul team and the TLS WG.
+
+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.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+8.2.  Informative References
+
+   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, April 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                   [Page 13]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+   [TLS-CHANNEL-BINDINGS]
+              Altman, J., Williams, N., and L. Zhu, "Channel Bindings
+              for TLS", Work in Progress, October 2009.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
+              Mechanism", RFC 2965, October 2000.
+
+   [Ray09]    Ray, M., "Authentication Gap in TLS Renegotiation",
+              November 2009, <http://extendedsubset.com/?p=8>.
+
+   [SSLv3]    Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
+              Version 3.0", Work in Progress, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                   [Page 14]
+
+RFC 5746               TLS Renegotiation Extension         February 2010
+
+
+Authors' Addresses
+
+   Eric Rescorla
+   RTFM, Inc.
+   2064 Edgewood Drive
+   Palo Alto, CA  94303
+   USA
+
+   EMail:  ekr@rtfm.com
+
+
+   Marsh Ray
+   PhoneFactor
+   7301 W 129th Street
+   Overland Park, KS  66213
+   USA
+
+   EMail:  marsh@extendedsubset.com
+
+
+   Steve Dispensa
+   PhoneFactor
+   7301 W 129th Street
+   Overland Park, KS  66213
+   USA
+
+   EMail:  dispensa@phonefactor.com
+
+
+   Nasko Oskov
+   Microsoft
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+
+   EMail:  nasko.oskov@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla, et al.             Standards Track                   [Page 15]
+