doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc7366.txt b/doc/rfc/rfc7366.txt
new file mode 100644
index 0000000..b63759c
--- /dev/null
+++ b/doc/rfc/rfc7366.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Gutmann
+Request for Comments: 7366                        University of Auckland
+Category: Standards Track                                 September 2014
+ISSN: 2070-1721
+
+
+        Encrypt-then-MAC for Transport Layer Security (TLS) and
+                Datagram Transport Layer Security (DTLS)
+
+Abstract
+
+   This document describes a means of negotiating the use of the
+   encrypt-then-MAC security mechanism in place of the existing MAC-
+   then-encrypt mechanism in Transport Layer Security (TLS) and Datagram
+   Transport Layer Security (DTLS).  The MAC-then-encrypt mechanism has
+   been the subject of a number of security vulnerabilities over a
+   period of many years.
+
+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/rfc7366.
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+
+
+
+
+Gutmann                      Standards Track                    [Page 1]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Conventions Used in This Document . . . . . . . . . . . .   2
+   2.  Negotiating Encrypt-then-MAC  . . . . . . . . . . . . . . . .   2
+     2.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . .   3
+     3.1.  Rehandshake Issues  . . . . . . . . . . . . . . . . . . .   5
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+
+1.  Introduction
+
+   TLS [2] and DTLS [4] use a MAC-then-encrypt construction that was
+   regarded as secure at the time the original Secure Socket Layer (SSL)
+   protocol was specified in the mid-1990s, but that is no longer
+   regarded as secure [5] [6].  This construction, as used in TLS and
+   later DTLS, has been the subject of numerous security vulnerabilities
+   and attacks stretching over a period of many years.  This document
+   specifies a means of switching to the more secure encrypt-then-MAC
+   construction as part of the TLS/DTLS handshake, replacing the current
+   MAC-then-encrypt construction.  (In this document, "MAC" refers to
+   "Message Authentication Code".)
+
+1.1.  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 [1].
+
+2.  Negotiating Encrypt-then-MAC
+
+   The use of encrypt-then-MAC is negotiated via TLS/DTLS extensions as
+   defined in TLS [2].  On connecting, the client includes the
+   encrypt_then_mac extension in its client_hello if it wishes to use
+   encrypt-then-MAC rather than the default MAC-then-encrypt.  If the
+   server is capable of meeting this requirement, it responds with an
+   encrypt_then_mac in its server_hello.  The "extension_type" value for
+   this extension SHALL be 22 (0x16), and the "extension_data" field of
+   this extension SHALL be empty.  The client and server MUST NOT use
+   encrypt-then-MAC unless both sides have successfully exchanged
+   encrypt_then_mac extensions.
+
+
+
+
+
+Gutmann                      Standards Track                    [Page 2]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+2.1.  Rationale
+
+   The use of TLS/DTLS extensions to negotiate an overall switch is
+   preferable to defining new ciphersuites because the latter would
+   result in a Cartesian explosion of suites, potentially requiring
+   duplicating every single existing suite with a new one that uses
+   encrypt-then-MAC.  In contrast, the approach presented here requires
+   just a single new extension type with a corresponding minimal-length
+   extension sent by client and server.
+
+   Another possibility for introducing encrypt-then-MAC would be to make
+   it part of TLS 1.3; however, this would require the implementation
+   and deployment of all of TLS 1.2 just to support a trivial code
+   change in the order of encryption and MAC'ing.  In contrast,
+   deploying encrypt-then-MAC via the TLS/DTLS extension mechanism
+   required changing less than a dozen lines of code in one
+   implementation (not including the handling for the new extension
+   type, which was a further 50 or so lines of code).
+
+   The use of extensions precludes use with SSL 3.0, but then it's
+   likely that anything still using that protocol, which is nearly two
+   decades old, will be vulnerable to any number of other attacks
+   anyway, so there seems little point in bending over backwards to
+   accommodate SSL 3.0.
+
+3.  Applying Encrypt-then-MAC
+
+   Once the use of encrypt-then-MAC has been negotiated, processing of
+   TLS/DTLS packets switches from the standard:
+
+   encrypt( data || MAC || pad )
+
+   to the new:
+
+   encrypt( data || pad ) || MAC
+
+   with the MAC covering the entire packet up to the start of the MAC
+   value.  In TLS [2] notation, the MAC calculation for TLS 1.0 without
+   the explicit Initialization Vector (IV) is:
+
+   MAC(MAC_write_key, seq_num +
+       TLSCipherText.type +
+       TLSCipherText.version +
+       TLSCipherText.length +
+       ENC(content + padding + padding_length));
+
+
+
+
+
+
+Gutmann                      Standards Track                    [Page 3]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+   and for TLS 1.1 and greater with an explicit IV is:
+
+   MAC(MAC_write_key, seq_num +
+       TLSCipherText.type +
+       TLSCipherText.version +
+       TLSCipherText.length +
+       IV +
+       ENC(content + padding + padding_length));
+
+   (For DTLS, the sequence number is replaced by the combined epoch and
+   sequence number as per DTLS [4].)  The final MAC value is then
+   appended to the encrypted data and padding.  This calculation is
+   identical to the existing one, with the exception that the MAC
+   calculation is run over the payload ciphertext (the TLSCipherText
+   PDU) rather than the plaintext (the TLSCompressed PDU).
+
+   The overall TLS packet [2] is then:
+
+   struct {
+          ContentType type;
+          ProtocolVersion version;
+          uint16 length;
+          GenericBlockCipher fragment;
+          opaque MAC;
+          } TLSCiphertext;
+
+   The equivalent DTLS packet [4] is then:
+
+   struct {
+          ContentType type;
+          ProtocolVersion version;
+          uint16 epoch;
+          uint48 sequence_number;
+          uint16 length;
+          GenericBlockCipher fragment;
+          opaque MAC;
+          } TLSCiphertext;
+
+   This is identical to the existing TLS/DTLS layout, with the only
+   difference being that the MAC value is moved outside the encrypted
+   data.
+
+   Note from the GenericBlockCipher annotation that this only applies to
+   standard block ciphers that have distinct encrypt and MAC operations.
+   It does not apply to GenericStreamCiphers or to GenericAEADCiphers
+   that already include integrity protection with the cipher.  If a
+   server receives an encrypt-then-MAC request extension from a client
+   and then selects a stream or Authenticated Encryption with Associated
+
+
+
+Gutmann                      Standards Track                    [Page 4]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+   Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC
+   response extension back to the client.
+
+   Decryption reverses this processing.  The MAC SHALL be evaluated
+   before any further processing such as decryption is performed, and if
+   the MAC verification fails, then processing SHALL terminate
+   immediately.  For TLS, a fatal bad_record_mac MUST be generated [2].
+   For DTLS, the record MUST be discarded, and a fatal bad_record_mac
+   MAY be generated [4].  This immediate response to a bad MAC
+   eliminates any timing channels that may be available through the use
+   of manipulated packet data.
+
+   Some implementations may prefer to use a truncated MAC rather than a
+   full-length one.  In this case, they MAY negotiate the use of a
+   truncated MAC through the TLS truncated_hmac extension as defined in
+   TLS-Ext [3].
+
+3.1.  Rehandshake Issues
+
+   The status of encrypt-then-MAC vs. MAC-then-encrypt can potentially
+   change during one or more rehandshakes.  Implementations SHOULD
+   retain the current session state across all rehandshakes for that
+   session.  (In other words, if the mechanism for the current session
+   is X, then the renegotiated session should also use X.)  Although
+   implementations SHOULD NOT change the state during a rehandshake, if
+   they wish to be more flexible, then the following rules apply:
+
+   +------------------+---------------------+--------------------------+
+   | Current Session  |     Renegotiated    |      Action to take      |
+   |                  |       Session       |                          |
+   +------------------+---------------------+--------------------------+
+   | MAC-then-encrypt |   MAC-then-encrypt  |        No change         |
+   |                  |                     |                          |
+   | MAC-then-encrypt |   Encrypt-then-MAC  |        Upgrade to        |
+   |                  |                     |     Encrypt-then-MAC     |
+   |                  |                     |                          |
+   | Encrypt-then-MAC |   MAC-then-encrypt  |          Error           |
+   |                  |                     |                          |
+   | Encrypt-then-MAC |   Encrypt-then-MAC  |        No change         |
+   +------------------+---------------------+--------------------------+
+
+               Table 1: Encrypt-then-MAC with Renegotiation
+
+   As the above table points out, implementations MUST NOT renegotiate a
+   downgrade from encrypt-then-MAC to MAC-then-encrypt.  Note that a
+   client or server that doesn't wish to implement the mechanism-change-
+   during-rehandshake ability can (as a client) not request a mechanism
+   change and (as a server) deny the mechanism change.
+
+
+
+Gutmann                      Standards Track                    [Page 5]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+   Note that these rules apply across potentially many rehandshakes.
+   For example, if a session were in the encrypt-then-MAC state and a
+   rehandshake selected a GenericAEADCiphers ciphersuite and a
+   subsequent rehandshake then selected a MAC-then-encrypt ciphersuite,
+   this would be an error since the renegotiation process has resulted
+   in a downgrade from encrypt-then-MAC to MAC-then-encrypt (via the
+   AEAD ciphersuite).
+
+   (As the text above has already pointed out, implementations SHOULD
+   avoid having to deal with these ciphersuite calisthenics by retaining
+   the initially negotiated mechanism across all rehandshakes.)
+
+   If an upgrade from MAC-then-encrypt to encrypt-then-MAC is negotiated
+   as per the second line in the table above, then the change will take
+   place in the first message that follows the Change Cipher Spec (CCS)
+   message.  In other words, all messages up to and including the CCS
+   will use MAC-then-encrypt, and then the message that follows will
+   continue with encrypt-then-MAC.
+
+4.  Security Considerations
+
+   This document defines encrypt-then-MAC, an improved security
+   mechanism to replace the current MAC-then-encrypt one.  Encrypt-then-
+   MAC is regarded as more secure than the current mechanism [5] [6] and
+   should mitigate or eliminate a number of attacks on the current
+   mechanism, provided that the instructions on MAC processing given in
+   Section 3 are applied.
+
+   An active attacker who can emulate a client or server with extension
+   intolerance may cause some implementations to fall back to older
+   protocol versions that don't support extensions, which will in turn
+   force a fallback to non-encrypt-then-MAC behaviour.  A
+   straightforward solution to this problem is to avoid fallback to
+   older, less secure protocol versions.  If fallback behaviour is
+   unavoidable, then mechanisms to address this issue, which affects all
+   capabilities that are negotiated via TLS extensions, are being
+   developed by the TLS working group [7].  Anyone concerned about this
+   type of attack should consult the TLS working group documents for
+   guidance on appropriate defence mechanisms.
+
+5.  IANA Considerations
+
+   IANA has added the extension code point 22 (0x16) for the
+   encrypt_then_mac extension to the TLS "ExtensionType Values" registry
+   as specified in TLS [2].
+
+
+
+
+
+
+Gutmann                      Standards Track                    [Page 6]
+
+RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014
+
+
+6.  Acknowledgements
+
+   The author would like to thank Martin Rex, Dan Shumow, and the
+   members of the TLS mailing list for their feedback on this document.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+        Protocol Version 1.2", RFC 5246, August 2008.
+
+   [3]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
+        Extension Definitions", RFC 6066, January 2011.
+
+   [4]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security
+        Version 1.2", RFC 6347, January 2012.
+
+7.2.  Informative References
+
+   [5]  Bellare, M. and C. Namprempre, "Authenticated Encryption:
+        Relations among notions and analysis of the generic composition
+        paradigm", Proceedings of AsiaCrypt '00, Springer-Verlag LNCS
+        No. 1976, p. 531, December 2000.
+
+   [6]  Krawczyk, H., "The Order of Encryption and Authentication for
+        Protecting Communications (or: How Secure Is SSL?)", Proceedings
+        of Crypto '01, Springer-Verlag LNCS No. 2139, p. 310, August
+        2001.
+
+   [7]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite
+        Value (SCSV) for Preventing Protocol Downgrade Attacks", Work in
+        Progress, July 2014.
+
+Author's Address
+
+   Peter Gutmann
+   University of Auckland
+   Department of Computer Science
+   New Zealand
+
+   EMail: pgut001@cs.auckland.ac.nz
+
+
+
+
+
+
+Gutmann                      Standards Track                    [Page 7]
+