idnits 2.17.1 draft-rescorla-tls-extended-random-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 2008) is 5840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '28' on line 72 == Outdated reference: A later version (-12) exists of draft-ietf-tls-rfc4366-bis-02 == Outdated reference: A later version (-11) exists of draft-rescorla-tls-suiteb-02 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 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: October 31, 2008 National Security Agency 6 April 29, 2008 8 Extended Random Values for TLS 9 draft-rescorla-tls-extended-random-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 31, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes an extension for using larger client and 43 server Random values with Transport Layer Security (TLS) and Datagram 44 TLS (DTLS). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 50 3. The ExtendedRandom Extension . . . . . . . . . . . . . . . . . 3 51 3.1. Negotiating the ExtendedRandom Extension . . . . . . . . . 4 52 3.2. PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 4.1. Threats to TLS . . . . . . . . . . . . . . . . . . . . . . 5 55 4.2. Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Introduction 66 TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte 67 "Random" value consisting of a 32-bit time value time and 28 randomly 68 generated bytes: 70 struct { 71 uint32 gmt_unix_time; 72 opaque random_bytes[28]; 73 } Random; 75 The client and server each contribute a Random value which is then 76 mixed with secret keying material to produce the final per- 77 association keying material. 79 The United States Department of Defense has requested a TLS mode 80 which allows the use of longer public randomness values for use with 81 high security level cipher suites like those specified in Suite B 82 [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD 83 is that the public randomness for each side should be at least twice 84 as long as the security level for cryptographic parity, which makes 85 the 224 bits of randomness provided by the current TLS random values 86 insufficient. 88 This document specifies an extension which allows for additional 89 randomness to be exchanged in the Hello messages. 91 2. Conventions Used In This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. The ExtendedRandom Extension 99 This document defines a new TLS extension called "extended_random". 101 The "extended_random" extension carried in a new TLS extension called 102 "ExtendedRandom". 104 struct { 105 opaque extended_random_value<0..2^16-1>; 106 } ExtendedRandom; 108 The extended_random_value MUST be a randomly generated byte string. 109 A cryptographically secure PRNG [RFC4086] SHOULD be used. 111 3.1. Negotiating the ExtendedRandom Extension 113 The client requests support for the extended randomness feature by 114 sending an "extended_random" extension in its ClientHello. The 115 "extension_data" field contains an ExtendedRandom value. 117 When a server which does not recognize the "extended_random" 118 extension receives one, it will ignore it as required. A server 119 which recognizes the extension MAY choose to ignore it, in which case 120 it SHOULD continue with the exchange as if it had not received the 121 extension. 123 If the server wishes to use the extended randomness feature, it MUST 124 send its own "extended_random" extension with an 125 extended_random_value equal in length to the client's 126 extended_random_value. Clients SHOULD check the length of the 127 server's extended_random_value and generate a fatal 128 "illegal_parameter" error if it is present but does does not match 129 the length that was transmitted in the ClientHello. 131 Because TLS does not permit servers to request extensions which the 132 client did not offer, the client may not offer the "extended_random" 133 extension even if the server requires it. In this case, the server 134 should generate a fatal "handshake_failure" alert. 136 Because there is no way to mark extensions as critical, the server 137 may ignore the "extended_random" extension even though the client 138 requires it. If a client requires the extended randomness input 139 feature but the server does not negotiate it, the client SHOULD 140 generate a fatal "handshake_failure" alert. 142 3.2. PRF Modifications 144 When the extended randomness feature is in use, the extended random 145 values MUST be mixed into the PRF along with the client and server 146 random values during the PMS->MS conversion. Thus, the PRF becomes: 148 master_secret = PRF(pre_master_secret, "master secret", 149 ClientHello.random + 150 ClientHello.extended_random_value + 151 ServerHello.random + 152 ServerHello.extended_random_value)[0..47]; 154 Because new extensions may not be introduced in resumed handshakes, 155 mixing in the extended inputs during the MS->keying material 156 conversion would simply involve mixing in the same material twice. 157 Therefore, the extended random inputs are only used when the PMS is 158 converted into the MS. 160 4. Security Considerations 162 4.1. Threats to TLS 164 When this extension is in use it increases the amount of data that an 165 attacker can inject into the PRF. This potentially would allow an 166 attacker who had partially compromised the PRF greater scope for 167 influencing the output. Hash-based PRFs like the one in TLS are 168 designed to be fairly indifferent to the input size (the input is 169 already greater than the block size of most hash functions), however 170 there is currently no proof that a larger input space would not make 171 attacks easier. 173 Another concern is that bad implementations might generate low 174 entropy extented random values. TLS is designed to function 175 correctly even when fed low-entropy random values because they are 176 primarily used to generate distinct keying material for each 177 connection. 179 4.2. Scope of Randomness 181 TLS specifies that when a session is resumed the extensions from the 182 original connection are used: 184 If, on the other hand, the older session is resumed, then the 185 server MUST ignore the extensions and send a server hello 186 containing none of the extension types. In this case, the 187 functionality of these extensions negotiated during the original 188 session initiation is applied to the resumed session. 190 This motivates why the the extended randomness does not get mixed 191 into the PRF when generating the keying material from the master 192 secret. Because the same values would be used for every connection 193 in a session, they would not provide any differentiation in the 194 keying material between the connections. 196 5. IANA Considerations 198 This document defines an extension to TLS, in accordance with 199 [I-D.ietf-tls-rfc4366-bis]: 201 enum { extended_random (??) } ExtensionType; 203 [[ NOTE: These values need to be assigned by IANA ]] 205 6. Acknowledgements 207 This work was supported by the US Department of Defense. 209 7. References 211 7.1. Normative References 213 [I-D.ietf-tls-rfc4346-bis] 214 Dierks, T. and E. Rescorla, "The Transport Layer Security 215 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 216 (work in progress), March 2008. 218 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 219 Requirements for Security", BCP 106, RFC 4086, June 2005. 221 7.2. Informative References 223 [I-D.ietf-tls-rfc4366-bis] 224 3rd, D., "Transport Layer Security (TLS) Extensions: 225 Extension Definitions", draft-ietf-tls-rfc4366-bis-02 226 (work in progress), February 2008. 228 [I-D.rescorla-tls-suiteb] 229 Salter, M. and E. Rescorla, "Suite B Cipher Suites for 230 TLS", draft-rescorla-tls-suiteb-02 (work in progress), 231 April 2008. 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 237 Security", RFC 4347, April 2006. 239 Authors' Addresses 241 Eric Rescorla 242 RTFM, Inc. 243 2064 Edgewood Drive 244 Palo Alto, CA 94303 245 USA 247 Email: ekr@rtfm.com 248 Margaret Salter 249 National Security Agency 250 9800 Savage Rd. 251 Fort Meade 20755-6709 252 USA 254 Email: msalter@restarea.ncsc.mil 256 Full Copyright Statement 258 Copyright (C) The IETF Trust (2008). 260 This document is subject to the rights, licenses and restrictions 261 contained in BCP 78, and except as set forth therein, the authors 262 retain all their rights. 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 268 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 269 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Intellectual Property 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at 294 ietf-ipr@ietf.org. 296 Acknowledgment 298 Funding for the RFC Editor function is provided by the IETF 299 Administrative Support Activity (IASA).