idnits 2.17.1 draft-rescorla-tls-extended-random-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 02, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '28' on line 85 == Outdated reference: A later version (-12) exists of draft-ietf-tls-rfc4366-bis-03 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Informational M. Salter 5 Expires: September 3, 2009 National Security Agency 6 March 02, 2009 8 Extended Random Values for TLS 9 draft-rescorla-tls-extended-random-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 3, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes an extension for using larger client and 58 server Random values with Transport Layer Security (TLS) and Datagram 59 TLS (DTLS). 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 65 3. The ExtendedRandom Extension . . . . . . . . . . . . . . . . . 3 66 3.1. Negotiating the ExtendedRandom Extension . . . . . . . . . 4 67 3.2. PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Threats to TLS . . . . . . . . . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte 80 "Random" value consisting of a 32-bit time value time and 28 randomly 81 generated bytes: 83 struct { 84 uint32 gmt_unix_time; 85 opaque random_bytes[28]; 86 } Random; 88 The client and server each contribute a Random value which is then 89 mixed with secret keying material to produce the final per- 90 association keying material. 92 The United States Department of Defense has requested a TLS mode 93 which allows the use of longer public randomness values for use with 94 high security level cipher suites like those specified in Suite B 95 [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD 96 is that the public randomness for each side should be at least twice 97 as long as the security level for cryptographic parity, which makes 98 the 224 bits of randomness provided by the current TLS random values 99 insufficient. 101 This document specifies an extension which allows for additional 102 randomness to be exchanged in the Hello messages. 104 2. Conventions Used In This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. The ExtendedRandom Extension 112 This document defines a new TLS extension called "extended_random". 114 The "extended_random" extension carried in a new TLS extension called 115 "ExtendedRandom". 117 struct { 118 opaque extended_random_value<0..2^16-1>; 119 } ExtendedRandom; 121 The extended_random_value MUST be a randomly generated byte string. 122 A cryptographically secure PRNG [RFC4086] SHOULD be used. 124 3.1. Negotiating the ExtendedRandom Extension 126 The client requests support for the extended randomness feature by 127 sending an "extended_random" extension in its ClientHello. The 128 "extension_data" field contains an ExtendedRandom value. 130 When a server which does not recognize the "extended_random" 131 extension receives one, it will ignore it as required. A server 132 which recognizes the extension MAY choose to ignore it, in which case 133 it SHOULD continue with the exchange as if it had not received the 134 extension. 136 If the server wishes to use the extended randomness feature, it MUST 137 send its own "extended_random" extension with an 138 extended_random_value equal in length to the client's 139 extended_random_value. Clients SHOULD check the length of the 140 server's extended_random_value and generate a fatal 141 "illegal_parameter" error if it is present but does does not match 142 the length that was transmitted in the ClientHello. 144 Because TLS does not permit servers to request extensions which the 145 client did not offer, the client may not offer the "extended_random" 146 extension even if the server requires it. In this case, the server 147 should generate a fatal "handshake_failure" alert. 149 Because there is no way to mark extensions as critical, the server 150 may ignore the "extended_random" extension even though the client 151 requires it. If a client requires the extended randomness input 152 feature but the server does not negotiate it, the client SHOULD 153 generate a fatal "handshake_failure" alert. 155 3.2. PRF Modifications 157 When the extended randomness feature is in use, the extended random 158 values MUST be mixed into the PRF along with the client and server 159 random values during the PMS->MS conversion. Thus, the PRF becomes: 161 master_secret = PRF(pre_master_secret, "master secret", 162 ClientHello.random + 163 ClientHello.extended_random_value + 164 ServerHello.random + 165 ServerHello.extended_random_value)[0..47]; 167 Because new extensions may not be introduced in resumed handshakes, 168 mixing in the extended inputs during the MS->keying material 169 conversion would simply involve mixing in the same material twice. 170 Therefore, the extended random inputs are only used when the PMS is 171 converted into the MS. 173 4. Security Considerations 175 4.1. Threats to TLS 177 When this extension is in use it increases the amount of data that an 178 attacker can inject into the PRF. This potentially would allow an 179 attacker who had partially compromised the PRF greater scope for 180 influencing the output. Hash-based PRFs like the one in TLS are 181 designed to be fairly indifferent to the input size (the input is 182 already greater than the block size of most hash functions), however 183 there is currently no proof that a larger input space would not make 184 attacks easier. 186 Another concern is that bad implementations might generate low 187 entropy extented random values. TLS is designed to function 188 correctly even when fed low-entropy random values because they are 189 primarily used to generate distinct keying material for each 190 connection. 192 5. IANA Considerations 194 This document defines an extension to TLS, in accordance with 195 [I-D.ietf-tls-rfc4366-bis]: 197 enum { extended_random (??) } ExtensionType; 199 [[ NOTE: These values need to be assigned by IANA ]] 201 6. Acknowledgements 203 This work was supported by the US Department of Defense. 205 7. References 207 7.1. Normative References 209 [I-D.ietf-tls-rfc4346-bis] 210 Dierks, T. and E. Rescorla, "The Transport Layer Security 211 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 212 (work in progress), March 2008. 214 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 215 Requirements for Security", BCP 106, RFC 4086, June 2005. 217 7.2. Informative References 219 [I-D.ietf-tls-rfc4366-bis] 220 3rd, D., "Transport Layer Security (TLS) Extensions: 221 Extension Definitions", draft-ietf-tls-rfc4366-bis-03 222 (work in progress), October 2008. 224 [I-D.rescorla-tls-suiteb] 225 Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 226 for Transport Layer Security (TLS)", 227 draft-rescorla-tls-suiteb-11 (work in progress), 228 November 2008. 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 234 Security", RFC 4347, April 2006. 236 Authors' Addresses 238 Eric Rescorla 239 RTFM, Inc. 240 2064 Edgewood Drive 241 Palo Alto, CA 94303 242 USA 244 Email: ekr@rtfm.com 246 Margaret Salter 247 National Security Agency 248 9800 Savage Rd. 249 Fort Meade 20755-6709 250 USA 252 Email: msalter@restarea.ncsc.mil