idnits 2.17.1 draft-thomson-saag-context-labels-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (May 20, 2016) is 2897 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-05 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'I-D.irtf-cfrg-eddsa') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-12 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track D. Gillmor 5 Expires: November 21, 2016 ACLU 6 B. Kaduk 7 Unaffiliated 8 May 20, 2016 10 Using Context Labels for Domain Separation of Cryptographic Objects 11 draft-thomson-saag-context-labels-00 13 Abstract 15 A single cryptographic key is sometimes relied upon to produce 16 muliple cryptographic artifacts that each have different semantics. 17 This produces a potential problem whereby artifacts with different 18 intended uses can be confused. The addition of context labels 19 removes this problem. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 21, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 57 2. Existing Functions with Context Labels . . . . . . . . . . . 3 58 3. Generic Signature or MAC Function with Context . . . . . . . 3 59 4. Recommendations for Context Labels . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 7.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Appendix A. Existing Protocols with Context Labels . . . . . . . 6 66 Appendix B. Existing Protocols without Context Labels . . . . . 10 67 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The same cryptographic primitive can be used in a range of different 73 contexts. These uses are often developed in isolation, which leads 74 to the potential for data structures that are used in one protocol 75 having plausible interpretations in other protocols. This gives an 76 opportunity for cross-protocol attacks, wherein a well-behaved 77 participant in one protocol can be coerced into creating a 78 cryptographic object that, when interpreted by a different protocol, 79 introduces a vulnerability. 81 Reuse of the same key in multiple contexts is strongly discouraged. 82 However, in some cases, use of the same key might be unavoidable. 83 For example, the same key might need to be used in multiple versions 84 of the same protocol, or a protocol might define multiple uses for a 85 particular type of key. 87 Including a unique protocol- and usage- specific context label as 88 input to a cryptographic operation prevents objects created in one 89 context from being mistakenly used in a different context. 91 This document describes a uniform approach for the inclusion of 92 context labels and a registry for unique labels. It covers the use 93 of these labels in digital signatures, key derivation functions 94 (KDFs), and message authentication codes (MACs). 96 Existing protocols might already include a unique context label. 97 This document collects some of these existing labels into the context 98 label registry. 100 1.1. Notational Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Existing Functions with Context Labels 108 The following cryptographic primitives define an explicit argument 109 for identifying a context: 111 o Ed448 and Ed448ph [I-D.irtf-cfrg-eddsa] define a "context" 112 argument. 114 o HKDF [RFC5869] specifies an "info" argument to the HKDF-Expand 115 function. 117 3. Generic Signature or MAC Function with Context 119 Many pre-existing signature and MAC schemes do not define an explicit 120 context label. This document defines a new signature function that 121 adds a context label to an existing function. 123 Given a signature function S that takes a key K and message M as a 124 sequence of octets, a signature with context function Sc is defined. 125 The signature with context function Sc takes three arguments, K, M, 126 and a context label C as a sequence of octets and is defined as: 128 Sc(K, M, C) = S(K, C || M) 130 That is, the signature is changed to accept a message that is the 131 concatenation of the context label and the message. 133 This scheme MUST be used with: 135 o RSA (both PKCS#1 and PSS) [RFC3447] 137 o ECDSA [X9.62] 139 o HMAC [RFC2104] 141 o Ed25519 and Ed25519ph [I-D.irtf-cfrg-eddsa] 143 4. Recommendations for Context Labels 145 In order to avoid attacks that permit use of a cryptographic object 146 for purposes other than intended, a context label C MUST NOT be a 147 prefix of any other context label. 149 New specifications defining context labels SHOULD select context 150 labels that end with a single zero-valued octet and do not contain 151 any other zero-valued octets. Context labels SHOULD be at least 12 152 octets in length. 154 5. IANA Considerations 156 This document establishes a "Cryptographic Context Label" registry. 158 Entries in this registry contain the following fields: 160 Context Label: A sequence of octets between 1 and 255 octets in 161 length, displayed as a hexadecimal string 163 String: An optional, informative ASCII representation of the context 164 label 166 Specification: A reference to a specification describing the use of 167 the context label 169 Context labels in this registry MUST NOT be a prefix of any other 170 context label in the registry. For example, if 0x01ab00 is 171 registered, then a registration for 0x01 or 0x01ab007c MUST be 172 rejected. 174 A context label that is 12 octets or more in length and contains 175 exactly one zero-valued octet at the end can be registered on a 176 First-Come, First-Served basis [RFC5226]. Context labels that do not 177 meet these requirements require Expert Review [RFC5226]. 179 The initial contents of this registry are included in Appendix A. 181 6. Security Considerations 183 In general, it is best to limit any cryptographic material to being 184 used for a single purpose. 186 7. References 187 7.1. Normative References 189 [I-D.irtf-cfrg-eddsa] 190 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 191 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-05 192 (work in progress), March 2016. 194 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 195 Hashing for Message Authentication", RFC 2104, 196 DOI 10.17487/RFC2104, February 1997, 197 . 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, 201 DOI 10.17487/RFC2119, March 1997, 202 . 204 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 205 Standards (PKCS) #1: RSA Cryptography Specifications 206 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 207 2003, . 209 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 210 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 211 DOI 10.17487/RFC5226, May 2008, 212 . 214 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 215 Key Derivation Function (HKDF)", RFC 5869, 216 DOI 10.17487/RFC5869, May 2010, 217 . 219 [X9.62] ANSI, "Public Key Cryptography For The Financial Services 220 Industry: The Elliptic Curve Digital Sig nature Algorithm 221 (ECDSA)", ANSI X9.62 , 1998. 223 7.2. Informative References 225 [I-D.ietf-tls-tls13] 226 Rescorla, E., "The Transport Layer Security (TLS) Protocol 227 Version 1.3", draft-ietf-tls-tls13-12 (work in progress), 228 March 2016. 230 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 231 (TLS) Protocol Version 1.2", RFC 5246, 232 DOI 10.17487/RFC5246, August 2008, 233 . 235 Appendix A. Existing Protocols with Context Labels 237 +----------------------+---------------------+----------------------+ 238 | Context label | String | Specification | 239 +----------------------+---------------------+----------------------+ 240 | 20 20 20 20 20 20 20 | (64 spaces)TLS 1.3, | [I-D.ietf-tls-tls13] | 241 | 20 20 20 20 20 20 20 | server | | 242 | 20 20 20 20 20 20 20 | CertificateVerify\0 | | 243 | 20 20 20 20 20 20 20 | | | 244 | 20 20 20 20 20 20 20 | | | 245 | 20 20 20 20 20 20 20 | | | 246 | 20 20 20 20 20 20 20 | | | 247 | 20 20 20 20 20 20 20 | | | 248 | 20 20 20 20 20 20 20 | | | 249 | 20 54 4c 53 20 31 2e | | | 250 | 33 2c 20 73 65 72 76 | | | 251 | 65 72 20 43 65 72 74 | | | 252 | 69 66 69 63 61 74 65 | | | 253 | 56 65 72 69 66 79 00 | | | 254 | | | | 255 | 20 20 20 20 20 20 20 | (64 spaces)TLS 1.3, | [I-D.ietf-tls-tls13] | 256 | 20 20 20 20 20 20 20 | client | | 257 | 20 20 20 20 20 20 20 | CertificateVerify\0 | | 258 | 20 20 20 20 20 20 20 | | | 259 | 20 20 20 20 20 20 20 | | | 260 | 20 20 20 20 20 20 20 | | | 261 | 20 20 20 20 20 20 20 | | | 262 | 20 20 20 20 20 20 20 | | | 263 | 20 20 20 20 20 20 20 | | | 264 | 20 54 4c 53 20 31 2e | | | 265 | 33 2c 20 63 6c 69 65 | | | 266 | 6e 74 20 43 65 72 74 | | | 267 | 69 66 69 63 61 74 65 | | | 268 | 56 65 72 69 66 79 00 | | | 269 | | | | 270 | 54 4c 53 20 31 2e 33 | TLS 1.3, expanded | [I-D.ietf-tls-tls13] | 271 | 2c 20 65 78 70 61 6e | static secret | | 272 | 64 65 64 20 73 74 61 | | | 273 | 74 69 63 20 73 65 63 | | | 274 | 72 65 74 | | | 275 | | | | 276 | 54 4c 53 20 31 2e 33 | TLS 1.3, expanded | [I-D.ietf-tls-tls13] | 277 | 2c 20 65 78 70 61 6e | ephemeral secret | | 278 | 64 65 64 20 65 70 68 | | | 279 | 65 6d 65 72 61 6c 20 | | | 280 | 73 65 63 72 65 74 | | | 281 | | | | 282 | 54 4c 53 20 31 2e 33 | TLS 1.3, traffic | [I-D.ietf-tls-tls13] | 283 | 2c 20 74 72 61 66 66 | secret | | 284 | 69 63 20 73 65 63 72 | | | 285 | 65 74 | | | 286 | | | | 287 | 54 4c 53 20 31 2e 33 | TLS 1.3, resumption | [I-D.ietf-tls-tls13] | 288 | 2c 20 72 65 73 75 6d | master secret | | 289 | 70 74 69 6f 6e 20 6d | | | 290 | 61 73 74 65 72 20 73 | | | 291 | 65 63 72 65 74 | | | 292 | | | | 293 | 54 4c 53 20 31 2e 33 | TLS 1.3, exporter | [I-D.ietf-tls-tls13] | 294 | 2c 20 65 78 70 6f 72 | master secret | | 295 | 74 65 72 20 6d 61 73 | | | 296 | 74 65 72 20 73 65 63 | | | 297 | 72 65 74 | | | 298 | | | | 299 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 300 | 2c 20 65 61 72 6c 79 | handshake key | | 301 | 20 68 61 6e 64 73 68 | expansion, client | | 302 | 61 6b 65 20 6b 65 79 | write key | | 303 | 20 65 78 70 61 6e 73 | | | 304 | 69 6f 6e 2c 20 63 6c | | | 305 | 69 65 6e 74 20 77 72 | | | 306 | 69 74 65 20 6b 65 79 | | | 307 | | | | 308 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 309 | 2c 20 65 61 72 6c 79 | handshake key | | 310 | 20 68 61 6e 64 73 68 | expansion, server | | 311 | 61 6b 65 20 6b 65 79 | write key | | 312 | 20 65 78 70 61 6e 73 | | | 313 | 69 6f 6e 2c 20 73 65 | | | 314 | 72 76 65 72 20 77 72 | | | 315 | 69 74 65 20 6b 65 79 | | | 316 | | | | 317 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 318 | 2c 20 65 61 72 6c 79 | handshake key | | 319 | 20 68 61 6e 64 73 68 | expansion, client | | 320 | 61 6b 65 20 6b 65 79 | write iv | | 321 | 20 65 78 70 61 6e 73 | | | 322 | 69 6f 6e 2c 20 63 6c | | | 323 | 69 65 6e 74 20 77 72 | | | 324 | 69 74 65 20 69 76 | | | 325 | | | | 326 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 327 | 2c 20 65 61 72 6c 79 | handshake key | | 328 | 20 68 61 6e 64 73 68 | expansion, server | | 329 | 61 6b 65 20 6b 65 79 | write iv | | 330 | 20 65 78 70 61 6e 73 | | | 331 | 69 6f 6e 2c 20 73 65 | | | 332 | 72 76 65 72 20 77 72 | | | 333 | 69 74 65 20 69 76 | | | 334 | | | | 335 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 336 | 2c 20 65 61 72 6c 79 | application data | | 337 | 20 61 70 70 6c 69 63 | key expansion, | | 338 | 61 74 69 6f 6e 20 64 | client write key | | 339 | 61 74 61 20 6b 65 79 | | | 340 | 20 65 78 70 61 6e 73 | | | 341 | 69 6f 6e 2c 20 63 6c | | | 342 | 69 65 6e 74 20 77 72 | | | 343 | 69 74 65 20 6b 65 79 | | | 344 | | | | 345 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 346 | 2c 20 65 61 72 6c 79 | application data | | 347 | 20 61 70 70 6c 69 63 | key expansion, | | 348 | 61 74 69 6f 6e 20 64 | server write key | | 349 | 61 74 61 20 6b 65 79 | | | 350 | 20 65 78 70 61 6e 73 | | | 351 | 69 6f 6e 2c 20 73 65 | | | 352 | 72 76 65 72 20 77 72 | | | 353 | 69 74 65 20 6b 65 79 | | | 354 | | | | 355 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 356 | 2c 20 65 61 72 6c 79 | application data | | 357 | 20 61 70 70 6c 69 63 | key expansion, | | 358 | 61 74 69 6f 6e 20 64 | client write iv | | 359 | 61 74 61 20 6b 65 79 | | | 360 | 20 65 78 70 61 6e 73 | | | 361 | 69 6f 6e 2c 20 63 6c | | | 362 | 69 65 6e 74 20 77 72 | | | 363 | 69 74 65 20 69 76 | | | 364 | | | | 365 | 54 4c 53 20 31 2e 33 | TLS 1.3, early | [I-D.ietf-tls-tls13] | 366 | 2c 20 65 61 72 6c 79 | application data | | 367 | 20 61 70 70 6c 69 63 | key expansion, | | 368 | 61 74 69 6f 6e 20 64 | server write iv | | 369 | 61 74 61 20 6b 65 79 | | | 370 | 20 65 78 70 61 6e 73 | | | 371 | 69 6f 6e 2c 20 73 65 | | | 372 | 72 76 65 72 20 77 72 | | | 373 | 69 74 65 20 69 76 | | | 374 | | | | 375 | 54 4c 53 20 31 2e 33 | TLS 1.3, handshake | [I-D.ietf-tls-tls13] | 376 | 2c 20 68 61 6e 64 73 | key expansion, | | 377 | 68 61 6b 65 20 6b 65 | client write key | | 378 | 79 20 65 78 70 61 6e | | | 379 | 73 69 6f 6e 2c 20 63 | | | 380 | 6c 69 65 6e 74 20 77 | | | 381 | 72 69 74 65 20 6b 65 | | | 382 | 79 | | | 383 | | | | 384 | 54 4c 53 20 31 2e 33 | TLS 1.3, handshake | [I-D.ietf-tls-tls13] | 385 | 2c 20 68 61 6e 64 73 | key expansion, | | 386 | 68 61 6b 65 20 6b 65 | server write key | | 387 | 79 20 65 78 70 61 6e | | | 388 | 73 69 6f 6e 2c 20 73 | | | 389 | 65 72 76 65 72 20 77 | | | 390 | 72 69 74 65 20 6b 65 | | | 391 | 79 | | | 392 | | | | 393 | 54 4c 53 20 31 2e 33 | TLS 1.3, handshake | [I-D.ietf-tls-tls13] | 394 | 2c 20 68 61 6e 64 73 | key expansion, | | 395 | 68 61 6b 65 20 6b 65 | client write iv | | 396 | 79 20 65 78 70 61 6e | | | 397 | 73 69 6f 6e 2c 20 63 | | | 398 | 6c 69 65 6e 74 20 77 | | | 399 | 72 69 74 65 20 69 76 | | | 400 | | | | 401 | 54 4c 53 20 31 2e 33 | TLS 1.3, handshake | [I-D.ietf-tls-tls13] | 402 | 2c 20 68 61 6e 64 73 | key expansion, | | 403 | 68 61 6b 65 20 6b 65 | server write iv | | 404 | 79 20 65 78 70 61 6e | | | 405 | 73 69 6f 6e 2c 20 73 | | | 406 | 65 72 76 65 72 20 77 | | | 407 | 72 69 74 65 20 69 76 | | | 408 | | | | 409 | 54 4c 53 20 31 2e 33 | TLS 1.3, | [I-D.ietf-tls-tls13] | 410 | 2c 20 61 70 70 6c 69 | application data | | 411 | 63 61 74 69 6f 6e 20 | key expansion, | | 412 | 64 61 74 61 20 6b 65 | client write key | | 413 | 79 20 65 78 70 61 6e | | | 414 | 73 69 6f 6e 2c 20 63 | | | 415 | 6c 69 65 6e 74 20 77 | | | 416 | 72 69 74 65 20 6b 65 | | | 417 | 79 | | | 418 | | | | 419 | 54 4c 53 20 31 2e 33 | TLS 1.3, | [I-D.ietf-tls-tls13] | 420 | 2c 20 61 70 70 6c 69 | application data | | 421 | 63 61 74 69 6f 6e 20 | key expansion, | | 422 | 64 61 74 61 20 6b 65 | server write key | | 423 | 79 20 65 78 70 61 6e | | | 424 | 73 69 6f 6e 2c 20 73 | | | 425 | 65 72 76 65 72 20 77 | | | 426 | 72 69 74 65 20 6b 65 | | | 427 | 79 | | | 428 | | | | 429 | 54 4c 53 20 31 2e 33 | TLS 1.3, | [I-D.ietf-tls-tls13] | 430 | 2c 20 61 70 70 6c 69 | application data | | 431 | 63 61 74 69 6f 6e 20 | key expansion, | | 432 | 64 61 74 61 20 6b 65 | client write iv | | 433 | 79 20 65 78 70 61 6e | | | 434 | 73 69 6f 6e 2c 20 63 | | | 435 | 6c 69 65 6e 74 20 77 | | | 436 | 72 69 74 65 20 69 76 | | | 437 | | | | 438 | 54 4c 53 20 31 2e 33 | TLS 1.3, | [I-D.ietf-tls-tls13] | 439 | 2c 20 61 70 70 6c 69 | application data | | 440 | 63 61 74 69 6f 6e 20 | key expansion, | | 441 | 64 61 74 61 20 6b 65 | server write iv | | 442 | 79 20 65 78 70 61 6e | | | 443 | 73 69 6f 6e 2c 20 73 | | | 444 | 65 72 76 65 72 20 77 | | | 445 | 72 69 74 65 20 69 76 | | | 446 +----------------------+---------------------+----------------------+ 448 Note that in the above table, the following categories of entry do 449 not conform with the guidance in Section 4: 451 o Labels for the TLS 1.3 HKDF input 453 Appendix B. Existing Protocols without Context Labels 455 TLS versions 1.2 [RFC5246] and earlier do not use context labels for 456 signatures though the use of the pseudorandom function (PRF) uses 457 version-agnostic labels. 459 Appendix C. Acknowledgments 461 This document originated from hallway discussions at IETF 95; thank 462 you to those who helped spark the idea. 464 Authors' Addresses 466 Martin Thomson 467 Mozilla 469 Email: martin.thomson@gmail.com 470 Daniel Kahn Gillmor 471 ACLU 473 Email: dkg@fifthhorseman.net 475 Benjamin Kaduk 476 Unaffiliated 478 Email: kaduk@mit.edu