doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7918.txt b/doc/rfc/rfc7918.txt
new file mode 100644
index 0000000..51c11ba
--- /dev/null
+++ b/doc/rfc/rfc7918.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Langley
+Request for Comments: 7918                                   N. Modadugu
+Category: Informational                                       B. Moeller
+ISSN: 2070-1721                                                   Google
+                                                             August 2016
+
+
+               Transport Layer Security (TLS) False Start
+
+Abstract
+
+   This document specifies an optional behavior of Transport Layer
+   Security (TLS) client implementations, dubbed "False Start".  It
+   affects only protocol timing, not on-the-wire protocol data, and can
+   be implemented unilaterally.  A TLS False Start reduces handshake
+   latency to one round trip.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   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/rfc7918.
+
+Copyright Notice
+
+   Copyright (c) 2016 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.
+
+
+
+
+Langley, et al.               Informational                     [Page 1]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
+   3.  False Start Compatibility . . . . . . . . . . . . . . . . . .   4
+   4.  Client-Side False Start . . . . . . . . . . . . . . . . . . .   4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+     5.1.  Symmetric Cipher  . . . . . . . . . . . . . . . . . . . .   6
+     5.2.  Protocol Version  . . . . . . . . . . . . . . . . . . . .   7
+     5.3.  Key Exchange and Client Certificate Type  . . . . . . . .   7
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
+   Appendix A.  Implementation Notes . . . . . . . . . . . . . . . .  10
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11
+
+1.  Introduction
+
+   A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246]
+   requires two full protocol rounds (four flights) before the handshake
+   is complete and the protocol parties may begin to send application
+   data.  Thus, using TLS can add a latency penalty of two network
+   round-trip times for application protocols in which the client sends
+   data first, such as HTTP [RFC7230].  Figure 1 (copied from [RFC5246])
+   shows the message flow for a full handshake.
+
+      Client                                               Server
+
+      ClientHello                  -------->
+                                                      ServerHello
+                                                     Certificate*
+                                               ServerKeyExchange*
+                                              CertificateRequest*
+                                   <--------      ServerHelloDone
+      Certificate*
+      ClientKeyExchange
+      CertificateVerify*
+      [ChangeCipherSpec]
+      Finished                     -------->
+                                               [ChangeCipherSpec]
+                                   <--------             Finished
+      Application Data             <------->     Application Data
+
+                Figure 1: Message Flow for a Full Handshake
+
+
+
+
+
+
+Langley, et al.               Informational                     [Page 2]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   This document describes a technique that alleviates the latency
+   burden imposed by TLS: the client-side TLS False Start.  If certain
+   conditions are met, the client can start to send application data
+   when the full handshake is only partially complete, namely, when the
+   client has sent its own ChangeCipherSpec and Finished messages (thus
+   having updated its TLS Record Protocol write state as negotiated in
+   the handshake) but has yet to receive the server's ChangeCipherSpec
+   and Finished messages.  (Per Section 7.4.9 of [RFC5246], after a full
+   handshake, the client would have to delay sending application data
+   until it has received and validated the server's Finished message.)
+   Accordingly, the latency penalty for using TLS with HTTP can be kept
+   at one round-trip time.
+
+   Note that in practice, the TCP three-way handshake [RFC0793]
+   typically adds one round-trip time before the client can even send
+   the ClientHello.  See [RFC7413] for a latency improvement at that
+   level.
+
+   When an earlier TLS session is resumed, TLS uses an abbreviated
+   handshake with only three protocol flights.  For application
+   protocols in which the client sends data first, this abbreviated
+   handshake adds just one round-trip time to begin with, so there is no
+   need for a client-side False Start.  However, if the server sends
+   application data first, the abbreviated handshake adds two round-trip
+   times, and this could be reduced to just one added round-trip time by
+   doing a server-side False Start.  There is little need for this in
+   practice, so this document does not consider server-side False Starts
+   further.
+
+   Note also that TLS versions 1.3 [TLS13] and beyond are out of scope
+   for this document.  False Start will not be needed with these newer
+   versions since protocol flows minimizing the number of round trips
+   have become a first-order design goal.
+
+   In a False Start, when the client sends application data before it
+   has received and verified the server's Finished message, there are
+   two possible outcomes:
+
+   o  The handshake completes successfully: The handshake is
+      retroactively validated when both Finished messages have been
+      received and verified.  This retroactively validates the
+      handshake.  In this case, the transcript of protocol data carried
+      over the transport underlying TLS will look as usual, apart from
+      the different timing.
+
+
+
+
+
+
+
+Langley, et al.               Informational                     [Page 3]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   o  The handshake fails: If a party does not receive the other side's
+      Finished message or if the Finished message's contents are not
+      correct, the handshake never gets validated.  This means that an
+      attacker may have removed, changed, or injected handshake
+      messages.  In this case, data has been sent over the underlying
+      transport that would not have been sent without the False Start.
+
+   The latter scenario makes it necessary to restrict when a False Start
+   is allowed, as described in this document.  Section 3 considers basic
+   requirements for using False Start.  Section 4 specifies the behavior
+   for clients, referring to important security considerations in
+   Section 5.
+
+2.  Requirements Notation
+
+   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 RFC 2119 [RFC2119].
+
+3.  False Start Compatibility
+
+   TLS False Start as described in detail in the subsequent sections, if
+   implemented, is an optional feature.
+
+   A TLS server implementation is defined to be "False Start compatible"
+   if it tolerates receiving TLS records on the transport connection
+   early, before the protocol has reached the state to process them.
+   For successful use of client-side False Start in a TLS connection,
+   the server has to be False Start compatible.  Out-of-band knowledge
+   that the server is False Start compatible may be available, e.g., if
+   this is mandated by specific application profile standards.  As
+   discussed in Appendix A, the requirement for False Start
+   compatibility generally does not pose a hindrance in practice.
+
+4.  Client-Side False Start
+
+   This section specifies a change to the behavior of TLS client
+   implementations in full TLS handshakes.
+
+   When the client has sent its ChangeCipherSpec and Finished messages,
+   its default behavior per [RFC5246] is to not send application data
+   until it has received the server's ChangeCipherSpec and Finished
+   messages, which completes the handshake.  With the False Start
+   protocol modification, the client MAY send application data earlier
+   (under the new Cipher Spec) if each of the following conditions is
+   satisfied:
+
+   o  The application layer has requested the TLS False Start option.
+
+
+
+Langley, et al.               Informational                     [Page 4]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   o  The symmetric cipher defined by the cipher suite negotiated in
+      this handshake has been whitelisted for use with False Start
+      according to the Security Considerations in Section 5.1.
+
+   o  The protocol version chosen by ServerHello.server_version has been
+      whitelisted for use with False Start according to the Security
+      Considerations in Section 5.2.
+
+   o  The key exchange method defined by the cipher suite negotiated in
+      this handshake and, if applicable, its parameters have been
+      whitelisted for use with False Start according to the Security
+      Considerations in Section 5.3.
+
+   o  In the case of a handshake with client authentication, the client
+      certificate type has been whitelisted for use with False Start
+      according to the Security Considerations in Section 5.3.
+
+   The rules for receiving data from the server remain unchanged.
+
+   Note that the TLS client cannot infer the presence of an
+   authenticated server until all handshake messages have been received.
+   With False Start, unlike with the default handshake behavior,
+   applications are able to send data before this point has been
+   reached: from an application point of view, being able to send data
+   does not imply that an authenticated peer is present.  Accordingly,
+   it is recommended that TLS implementations allow the application
+   layer to query whether the handshake has completed.
+
+5.  Security Considerations
+
+   In a TLS handshake, the Finished messages serve to validate the
+   entire handshake.  These messages are based on a hash of the
+   handshake so far processed by a Pseudorandom Function (PRF) keyed
+   with the new master secret (serving as a Message Authentication Code
+   (MAC)) and are also sent under the new Cipher Spec with its keyed
+   MAC, where the MAC key again is derived from the master secret.  The
+   protocol design relies on the assumption that any server and/or
+   client authentication done during the handshake carries over to this.
+   While an attacker could, for example, have changed the cipher suite
+   list sent by the client to the server and thus influenced cipher
+   suite selection (presumably towards a less secure choice) or could
+   have made other modifications to handshake messages in transmission,
+   the attacker would not be able to round off the modified handshake
+   with a valid Finished message: every TLS cipher suite is presumed to
+   key the PRF appropriately to ensure unforgeability.  Verifying the
+   Finished messages validates the handshake and confirms that the
+   handshake has not been tampered with; thus, secure encryption is
+   bootstrapped from secure authentication.
+
+
+
+Langley, et al.               Informational                     [Page 5]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   Using False Start interferes with this approach of bootstrapping
+   secure encryption from secure authentication, as application data may
+   have already been sent before Finished validation confirms that the
+   handshake has not been tampered with -- so there is generally no way
+   to be sure that communication with the expected peer is indeed taking
+   place during the False Start.  Instead, the security goal is to
+   ensure that if anyone at all can decrypt the application data sent in
+   a False Start, it must be the legitimate peer.  While an attacker
+   could be influencing the handshake (restricting cipher suite
+   selection, modifying key exchange messages, etc.), the attacker
+   should not be able to benefit from this.  The TLS protocol already
+   relies on such a security property for authentication; with False
+   Start, the same is needed for encryption.  This motivates the rules
+   put forth in the following subsections.
+
+   It is prudent for applications to be even more restrictive.  If
+   heuristically a small list of cipher suites and a single protocol
+   version is found to be sufficient for the majority of TLS handshakes
+   in practice, it could make sense to forego False Start for any
+   handshake that does not match this expected pattern, even if there is
+   no concrete reason to assume a cryptographic weakness.  Similarly, if
+   handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman
+   (ECDH) over one of a few named curves, it could make sense to
+   disallow False Start with any other supported curve.
+
+5.1.  Symmetric Cipher
+
+   Clients MUST NOT use the False Start protocol modification in a
+   handshake unless the cipher suite uses a symmetric cipher that is
+   considered cryptographically strong.
+
+   Implementations may have their own classification of ciphers (and may
+   additionally allow the application layer to provide a
+   classification), but generally only symmetric ciphers with an
+   effective key length of 128 bits or more can be considered strong.
+   Also, various ciphers specified for use with TLS are known to have
+   cryptographic weaknesses regardless of key length (none of the
+   ciphers specified in [RFC4492] and [RFC5246] can be recommended for
+   use with False Start).  The AES_128_GCM_SHA256 or AES_256_GCM_SHA384
+   ciphers specified in [RFC5288] and [RFC5289] can be considered
+   sufficiently strong for most uses.  Implementations that support
+   additional cipher suites have to be careful to whitelist only
+   suitable symmetric ciphers; if in doubt, False Start should not be
+   used with a given symmetric cipher.
+
+
+
+
+
+
+
+Langley, et al.               Informational                     [Page 6]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   While an attacker can change handshake messages to force a downgrade
+   to a less secure symmetric cipher than otherwise would have been
+   chosen, this rule ensures that in such a downgrade attack, no
+   application data will be sent under an insecure symmetric cipher.
+
+5.2.  Protocol Version
+
+   Clients MUST NOT use the False Start protocol modification in a
+   handshake unless the protocol version chosen by
+   ServerHello.server_version has been whitelisted for this use.
+
+   Generally, to avoid potential protocol downgrade attacks,
+   implementations should whitelist only their latest (highest-valued)
+   supported TLS protocol version (and, if applicable, any earlier
+   protocol versions that they would use in fallback retries without
+   TLS_FALLBACK_SCSV [RFC7507]).
+
+   The details of nominally identical cipher suites can differ between
+   protocol versions, so this reinforces Section 5.1.
+
+5.3.  Key Exchange and Client Certificate Type
+
+   Clients MUST NOT use the False Start protocol modification in a
+   handshake unless the cipher suite uses a key exchange method that has
+   been whitelisted for this use.  Also, clients MUST NOT use the False
+   Start protocol modification unless any parameters to the key exchange
+   methods (such as ServerDHParams or ServerECDHParams) have been
+   whitelisted for this use.  Furthermore, when using client
+   authentication, clients MUST NOT use the False Start protocol
+   modification unless the client certificate type has been whitelisted
+   for this use.
+
+   Implementations may have their own whitelists of key exchange
+   methods, parameters, and client certificate types (and may
+   additionally allow the application layer to specify whitelists).
+   Generally, out of the options from [RFC5246] and [RFC4492], the
+   following whitelists are recommended:
+
+   o  Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA
+
+   o  Parameters: well-known DH groups (at least 3,072 bits), named
+      curves (at least 256 bits)
+
+   o  Client certificate types: none
+
+   However, if an implementation that supports only key exchange methods
+   from [RFC5246] and [RFC4492] does not support any of the above key
+   exchange methods, all of its supported key exchange methods can be
+
+
+
+Langley, et al.               Informational                     [Page 7]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   whitelisted for False Start use.  Care is required with any
+   additional key exchange methods, as these may not have similar
+   properties.
+
+   The recommended whitelists are such that if cryptographic algorithms
+   suitable for forward secrecy would possibly be negotiated, no False
+   Start will take place if the current handshake fails to provide
+   forward secrecy.  (Forward secrecy can be achieved using ephemeral
+   Diffie-Hellman or ephemeral Elliptic Curve Diffie-Hellman; there is
+   no forward secrecy when using a key exchange method of RSA, RSA_PSK,
+   DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type
+   of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.)
+   As usual, the benefits of forward secrecy may need to be balanced
+   against efficiency, and accordingly, even implementations that
+   support the above key exchange methods might whitelist further key
+   exchange methods and client certificate types.
+
+   Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow
+   forward security, but using False Start with any of these means
+   sending application data tied to the client's signature before the
+   server's authenticity (and thus the CertificateRequest message) has
+   been completely verified, so these too are not generally suitable for
+   the client certificate type whitelist.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
+              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
+              for Transport Layer Security (TLS)", RFC 4492,
+              DOI 10.17487/RFC4492, May 2006,
+              <http://www.rfc-editor.org/info/rfc4492>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
+              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
+              DOI 10.17487/RFC5288, August 2008,
+              <http://www.rfc-editor.org/info/rfc5288>.
+
+
+
+Langley, et al.               Informational                     [Page 8]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+   [RFC5289]  Rescorla, E., "TLS Elliptic Curve Cipher Suites with
+              SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
+              DOI 10.17487/RFC5289, August 2008,
+              <http://www.rfc-editor.org/info/rfc5289>.
+
+6.2.  Informative References
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <http://www.rfc-editor.org/info/rfc793>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <http://www.rfc-editor.org/info/rfc7413>.
+
+   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
+              Suite Value (SCSV) for Preventing Protocol Downgrade
+              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
+              <http://www.rfc-editor.org/info/rfc7507>.
+
+   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", Work in Progress, draft-ietf-tls-tls13-14,
+              July 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.               Informational                     [Page 9]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+Appendix A.  Implementation Notes
+
+   TLS False Start is a modification to the TLS protocol, and some
+   implementations that conform to [RFC5246] may have problems
+   interacting with implementations that use the False Start
+   modification.  If the peer uses a False Start, application data
+   records may be received directly following the peer's Finished
+   message, before the TLS implementation has sent its own Finished
+   message.  False Start compatibility as defined in Section 3 ensures
+   that these records with application data will simply remain buffered
+   for later processing.
+
+   A False Start compatible TLS implementation does not have to be aware
+   of the False Start concept and is certainly not expected to detect
+   whether a False Start handshake is currently taking place: thanks to
+   transport layer buffering, typical implementations will be False
+   Start compatible without having been designed for it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.               Informational                    [Page 10]
+
+RFC 7918                     TLS False Start                 August 2016
+
+
+Acknowledgments
+
+   The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson,
+   Eric Rescorla, and Brian Smith for their input.
+
+Authors' Addresses
+
+   Adam Langley
+   Google Inc.
+   345 Spear St
+   San Francisco, CA  94105
+   United States of America
+
+   Email: agl@google.com
+
+
+   Nagendra Modadugu
+   Google Inc.
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   United States of America
+
+   Email: nagendra@cs.stanford.edu
+
+
+   Bodo Moeller
+   Google Switzerland GmbH
+   Brandschenkestrasse 110
+   Zurich  8002
+   Switzerland
+
+   Email: bmoeller@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.               Informational                    [Page 11]
+