Add.

2 files changed, 840 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt
new file mode 100644
index 0000000000..2ac8fcaee7
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt
@@ -0,0 +1,392 @@
+
+
+
+Network Working Group                                        E. Rescorla
+Internet-Draft                                                RTFM, Inc.
+Intended status:  Informational                           April 29, 2008
+Expires:  October 31, 2008
+
+
+TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
+                                  Mode
+                   draft-ietf-tls-ecc-new-mac-06.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on October 31, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+   RFC 4492 describes elliptic curve cipher suites for Transport Layer
+   Security (TLS).  However, all those cipher suites use SHA-1 as their
+   MAC algorithm.  This document describes sixteen new CipherSuites for
+   TLS/DTLS which specify stronger digest algorithms.  Eight use HMAC
+   with SHA-256 or SHA-384 and eight use AES in Galois Counter Mode
+   (GCM).
+
+
+
+
+Rescorla                Expires October 31, 2008                [Page 1]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
+   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
+     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                Expires October 31, 2008                [Page 2]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+1.  Introduction
+
+   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
+   suites for Transport Layer Security (TLS).  However, all of the RFC
+   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
+   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
+   from SHA-1 and towards stronger hash algorithms.  This document
+   specifies TLS ECC cipher suites which use SHA-256 and SHA-384 rather
+   than SHA-1.
+
+   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
+   encryption with additional data (AEAD) cipher modes [RFC5116].  This
+   document also specifies a set of ECC cipher suites using one such
+   mode, Galois Counter Mode (GCM) [GCM].  Another document
+   [I-D.ietf-tls-rsa-aes-gcm], provides support for GCM with other key
+   establishment methods.
+
+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 [RFC2119].
+
+
+2.  Cipher Suites
+
+   This document defines 8 new cipher suites to be added to TLS.  All
+   use Elliptic Curve Cryptography for key exchange and digital
+   signature, as defined in RFC 4492.
+
+2.1.  HMAC-based Cipher Suites
+
+   The first eight cipher suites use AES [AES] in CBC [CBC] mode with an
+   HMAC-based MAC:
+
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
+
+   These eight cipher suites are the same as the corresponding cipher
+   suites in RFC 4492 (with names ending in "_SHA" in place of "_SHA256"
+   or "_SHA384"), except for the hash and PRF algorithms, which use SHA-
+   256 and SHA-384 [SHS] as follows.
+
+
+
+Rescorla                Expires October 31, 2008                [Page 3]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+       Cipher Suite                                MAC          PRF
+       ------------                                ---          ---
+       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA256
+       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA384
+       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA256
+       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA384
+       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256       HMAC-SHA-256 P_SHA256
+       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384       HMAC-SHA-384 P_SHA384
+       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256        HMAC-SHA-256 P_SHA256
+       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384        HMAC-SHA-384 P_SHA384
+
+2.2.  Galois Counter Mode-based Cipher Suites
+
+   The second eight cipher suites use the same asymmetric algorithms as
+   those in the previous section but use the new authenticated
+   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode
+   (GCM) [GCM]:
+
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
+
+   These cipher suites use authenticated encryption with additional data
+   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
+   [RFC5116].  GCM is used as described in [I-D.ietf-tls-rsa-aes-gcm].
+
+
+        Cipher Suite                                PRF
+        ------------                                ---
+        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256     P_SHA256
+        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384     P_SHA384
+        TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256      P_SHA256
+        TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384      P_SHA384
+        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256       P_SHA256
+        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384       P_SHA384
+        TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256        P_SHA256
+        TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384        P_SHA384
+
+
+3.  Security Considerations
+
+   The security considerations in RFC 4346, RFC 4492, and
+   [I-D.ietf-tls-rsa-aes-gcm] apply to this document as well.  In
+
+
+
+Rescorla                Expires October 31, 2008                [Page 4]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+   addition, as described in [I-D.ietf-tls-rsa-aes-gcm], these cipher
+   suites may only be used with TLS 1.2 or greater.
+
+
+4.  IANA Considerations
+
+   IANA has assigned the following values for these cipher suites:
+
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
+       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
+       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
+       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
+       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
+
+
+5.  Acknowledgements
+
+   This work was supported by the US Department of Defense.
+
+   David McGrew contributed substantual sections of the GCM nonce text
+   as well as providing a review of this document.
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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, May 2006.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, January 2008.
+
+
+
+
+Rescorla                Expires October 31, 2008                [Page 5]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+   [I-D.ietf-tls-rfc4346-bis]
+              Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
+              (work in progress), March 2008.
+
+   [AES]      National Institute of Standards and Technology,
+              "Specification for the Advanced Encryption Standard
+              (AES)", FIPS 197, November 2001.
+
+   [SHS]      National Institute of Standards and Technology, "Secure
+              Hash Standard", FIPS 180-2, August 2002.
+
+   [CBC]      National Institute of Standards and Technology,
+              "Recommendation for Block Cipher Modes of Operation -
+              Methods and Techniques", SP 800-38A, December 2001.
+
+   [GCM]      National Institute of Standards and Technology,
+              "Recommendation for Block Cipher Modes of Operation:
+              Galois;/Counter Mode (GCM) for Confidentiality and
+              Authentication", SP 800-38D, November 2007.
+
+6.2.  Informative References
+
+   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
+              Full SHA-1", CRYPTO 2005, August 2005.
+
+   [I-D.ietf-tls-rsa-aes-gcm]
+              Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
+              Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 (work in
+              progress), April 2008.
+
+
+Author's Address
+
+   Eric Rescorla
+   RTFM, Inc.
+   2064 Edgewood Drive
+   Palo Alto  94303
+   USA
+
+   Email:  ekr@rtfm.com
+
+
+
+
+
+
+
+
+
+
+Rescorla                Expires October 31, 2008                [Page 6]
+
+Internet-Draft               TLS ECC New MAC                  April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Rescorla                Expires October 31, 2008                [Page 7]
+
diff --git a/doc/protocol/draft-rescorla-tls-extended-random-00.txt b/doc/protocol/draft-rescorla-tls-extended-random-00.txt
new file mode 100644
index 0000000000..5b33f74178
--- /dev/null
+++ b/doc/protocol/draft-rescorla-tls-extended-random-00.txt
@@ -0,0 +1,448 @@
+
+
+
+Network Working Group                                        E. Rescorla
+Internet-Draft                                                RTFM, Inc.
+Intended status:  Informational                                M. Salter
+Expires:  October 31, 2008                      National Security Agency
+                                                          April 29, 2008
+
+
+                     Extended Random Values for TLS
+               draft-rescorla-tls-extended-random-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on October 31, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+   This document describes an extension for using larger client and
+   server Random values with Transport Layer Security (TLS) and Datagram
+   TLS (DTLS).
+
+
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 1]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
+   3.  The ExtendedRandom Extension  . . . . . . . . . . . . . . . . . 3
+     3.1.  Negotiating the ExtendedRandom Extension  . . . . . . . . . 4
+     3.2.  PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+     4.1.  Threats to TLS  . . . . . . . . . . . . . . . . . . . . . . 5
+     4.2.  Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 2]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+1.  Introduction
+
+   TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
+   "Random" value consisting of a 32-bit time value time and 28 randomly
+   generated bytes:
+
+         struct {
+            uint32 gmt_unix_time;
+            opaque random_bytes[28];
+         } Random;
+
+   The client and server each contribute a Random value which is then
+   mixed with secret keying material to produce the final per-
+   association keying material.
+
+   The United States Department of Defense has requested a TLS mode
+   which allows the use of longer public randomness values for use with
+   high security level cipher suites like those specified in Suite B
+   [I-D.rescorla-tls-suiteb].  The rationale for this as stated by DoD
+   is that the public randomness for each side should be at least twice
+   as long as the security level for cryptographic parity, which makes
+   the 224 bits of randomness provided by the current TLS random values
+   insufficient.
+
+   This document specifies an extension which allows for additional
+   randomness to be exchanged in the Hello messages.
+
+
+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.  The ExtendedRandom Extension
+
+   This document defines a new TLS extension called "extended_random".
+
+   The "extended_random" extension carried in a new TLS extension called
+   "ExtendedRandom".
+
+        struct {
+            opaque extended_random_value<0..2^16-1>;
+        } ExtendedRandom;
+
+   The extended_random_value MUST be a randomly generated byte string.
+   A cryptographically secure PRNG [RFC4086] SHOULD be used.
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 3]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+3.1.  Negotiating the ExtendedRandom Extension
+
+   The client requests support for the extended randomness feature by
+   sending an "extended_random" extension in its ClientHello.  The
+   "extension_data" field contains an ExtendedRandom value.
+
+   When a server which does not recognize the "extended_random"
+   extension receives one, it will ignore it as required.  A server
+   which recognizes the extension MAY choose to ignore it, in which case
+   it SHOULD continue with the exchange as if it had not received the
+   extension.
+
+   If the server wishes to use the extended randomness feature, it MUST
+   send its own "extended_random" extension with an
+   extended_random_value equal in length to the client's
+   extended_random_value.  Clients SHOULD check the length of the
+   server's extended_random_value and generate a fatal
+   "illegal_parameter" error if it is present but does does not match
+   the length that was transmitted in the ClientHello.
+
+   Because TLS does not permit servers to request extensions which the
+   client did not offer, the client may not offer the "extended_random"
+   extension even if the server requires it.  In this case, the server
+   should generate a fatal "handshake_failure" alert.
+
+   Because there is no way to mark extensions as critical, the server
+   may ignore the "extended_random" extension even though the client
+   requires it.  If a client requires the extended randomness input
+   feature but the server does not negotiate it, the client SHOULD
+   generate a fatal "handshake_failure" alert.
+
+3.2.  PRF Modifications
+
+   When the extended randomness feature is in use, the extended random
+   values MUST be mixed into the PRF along with the client and server
+   random values during the PMS->MS conversion.  Thus, the PRF becomes:
+
+          master_secret = PRF(pre_master_secret, "master secret",
+                              ClientHello.random +
+                              ClientHello.extended_random_value +
+                              ServerHello.random +
+                              ServerHello.extended_random_value)[0..47];
+
+   Because new extensions may not be introduced in resumed handshakes,
+   mixing in the extended inputs during the MS->keying material
+   conversion would simply involve mixing in the same material twice.
+   Therefore, the extended random inputs are only used when the PMS is
+   converted into the MS.
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 4]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+4.  Security Considerations
+
+4.1.  Threats to TLS
+
+   When this extension is in use it increases the amount of data that an
+   attacker can inject into the PRF.  This potentially would allow an
+   attacker who had partially compromised the PRF greater scope for
+   influencing the output.  Hash-based PRFs like the one in TLS are
+   designed to be fairly indifferent to the input size (the input is
+   already greater than the block size of most hash functions), however
+   there is currently no proof that a larger input space would not make
+   attacks easier.
+
+   Another concern is that bad implementations might generate low
+   entropy extented random values.  TLS is designed to function
+   correctly even when fed low-entropy random values because they are
+   primarily used to generate distinct keying material for each
+   connection.
+
+4.2.  Scope of Randomness
+
+   TLS specifies that when a session is resumed the extensions from the
+   original connection are used:
+
+        If, on the other hand, the older session is resumed, then the
+        server MUST ignore the extensions and send a server hello
+        containing none of the extension types.  In this case, the
+        functionality of these extensions negotiated during the original
+        session initiation is applied to the resumed session.
+
+   This motivates why the the extended randomness does not get mixed
+   into the PRF when generating the keying material from the master
+   secret.  Because the same values would be used for every connection
+   in a session, they would not provide any differentiation in the
+   keying material between the connections.
+
+
+5.  IANA Considerations
+
+   This document defines an extension to TLS, in accordance with
+   [I-D.ietf-tls-rfc4366-bis]:
+
+     enum { extended_random (??) } ExtensionType;
+
+   [[ NOTE:  These values need to be assigned by IANA ]]
+
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 5]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+6.  Acknowledgements
+
+   This work was supported by the US Department of Defense.
+
+
+7.  References
+
+7.1.  Normative References
+
+   [I-D.ietf-tls-rfc4346-bis]
+              Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
+              (work in progress), March 2008.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+7.2.  Informative References
+
+   [I-D.ietf-tls-rfc4366-bis]
+              3rd, D., "Transport Layer Security (TLS) Extensions:
+              Extension Definitions", draft-ietf-tls-rfc4366-bis-02
+              (work in progress), February 2008.
+
+   [I-D.rescorla-tls-suiteb]
+              Salter, M. and E. Rescorla, "Suite B Cipher Suites for
+              TLS", draft-rescorla-tls-suiteb-02 (work in progress),
+              April 2008.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, April 2006.
+
+
+Authors' Addresses
+
+   Eric Rescorla
+   RTFM, Inc.
+   2064 Edgewood Drive
+   Palo Alto, CA  94303
+   USA
+
+   Email:  ekr@rtfm.com
+
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 6]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+   Margaret Salter
+   National Security Agency
+   9800 Savage Rd.
+   Fort Meade  20755-6709
+   USA
+
+   Email:  msalter@restarea.ncsc.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 7]
+
+Internet-Draft             Extended TLS Random                April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Rescorla & Salter       Expires October 31, 2008                [Page 8]
+