idnits 2.17.1 draft-irtf-cfrg-hpke-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 03, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Nenc' is mentioned on line 403, but not defined == Missing Reference: 'Npk' is mentioned on line 405, but not defined == Unused Reference: 'MAEA10' is defined on line 689, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-mls-protocol-06 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Informational K. Bhargavan 5 Expires: January 4, 2020 Inria 6 July 03, 2019 8 Hybrid Public Key Encryption 9 draft-irtf-cfrg-hpke-00 11 Abstract 13 This document describes a scheme for hybrid public-key encryption 14 (HPKE). This scheme provides authenticated public key encryption of 15 arbitrary-sized plaintexts for a recipient public key. HPKE works 16 for any combination of an asymmetric key encapsulation mechanism 17 (KEM), key derivation function (KDF), and authenticated encryption 18 with additional data (AEAD) encryption function. We provide 19 instantiations of the scheme using widely-used and efficient 20 primitives. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Security Properties . . . . . . . . . . . . . . . . . . . . . 3 59 4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 4 61 5.1. DH-Based KEM . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Hybrid Public Key Encryption . . . . . . . . . . . . . . . . 6 63 6.1. Creating an Encryption Context . . . . . . . . . . . . . 7 64 6.2. Encryption to a Public Key . . . . . . . . . . . . . . . 10 65 6.3. Authentication using a Pre-Shared Key . . . . . . . . . . 10 66 6.4. Authentication using an Asymmetric Key . . . . . . . . . 11 67 6.5. Authentication using both a PSK and an Asymmetric Key . . 12 68 6.6. Encryption and Decryption . . . . . . . . . . . . . . . . 12 69 7. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Key Encapsulation Mechanisms (KEMs) . . . . . . . . . . . 13 71 7.2. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 14 72 7.3. Authentication Encryption with Associated Data (AEAD) 73 Functions . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Appendix A. Possible TODOs . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 "Hybrid" public-key encryption schemes (HPKE) that combine asymmetric 85 and symmetric algorithms are a substantially more efficient solution 86 than traditional public key encryption techniques such as those based 87 on RSA or ElGamal. Encrypted messages convey a single ciphertext and 88 authentication tag alongside a short public key, which may be further 89 compressed. The key size and computational complexity of elliptic 90 curve cryptographic primitives for authenticated encryption therefore 91 make it compelling for a variety of use cases. This type of public 92 key encryption has many applications in practice, for example: 94 o PGP [RFC6637] 96 o Messaging Layer Security [I-D.ietf-mls-protocol] 97 o Encrypted Server Name Indication [I-D.ietf-tls-esni] 99 o Protection of 5G subscriber identities [fiveG] 101 Currently, there are numerous competing and non-interoperable 102 standards and variants for hybrid encryption, including ANSI X9.63 103 [ANSI], IEEE 1363a [IEEE], ISO/IEC 18033-2 [ISO], and SECG SEC 1 104 [SECG]. All of these existing schemes have problems, e.g., because 105 they rely on outdated primitives, lack proofs of IND-CCA2 security, 106 or fail to provide test vectors. 108 This document defines an HPKE scheme that provides a subset of the 109 functions provided by the collection of schemes above, but specified 110 with sufficient clarity that they can be interoperably implemented 111 and formally verified. 113 2. Requirements Notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Security Properties 123 As a hybrid authentication encryption algorithm, we desire security 124 against (adaptive) chosen ciphertext attacks (IND-CCA2 secure). The 125 HPKE variants described in this document achieve this property under 126 the Random Oracle model assuming the gap Computational Diffie Hellman 127 (CDH) problem is hard [S01]. 129 [[ TODO - Provide citations to these proofs once they exist ]] 131 4. Notation 133 The following terms are used throughout this document to describe the 134 operations, roles, and behaviors of HPKE: 136 o Initiator (I): Sender of an encrypted message. 138 o Responder (R): Receiver of an encrypted message. 140 o Ephemeral (E): A fresh random value meant for one-time use. 142 o "(skX, pkX)": A KEM key pair used in role X; "skX" is the private 143 key and "pkX" is the public key 145 o "pk(skX)": The public key corresponding to private key "skX" 147 o "len(x)": The length of the octet string "x", expressed as a two- 148 octet unsigned integer in network (big-endian) byte order 150 o "encode_big_endian(x, n)": An octet string encoding the integer 151 value "x" as an n-byte big-endian value 153 o "concat(x0, ..., xN)": Concatenation of octet strings. 154 "concat(0x01, 0x0203, 0x040506) = 0x010203040506" 156 o "zero(n)": An all-zero octet string of length "n". "zero(4) = 157 0x00000000" 159 o "xor(a,b)": XOR of octet strings; "xor(0xF0F0, 0x1234) = 0xE2C4". 160 It is an error to call this function with two arguments of unequal 161 length. 163 5. Cryptographic Dependencies 165 HPKE variants rely on the following primitives: 167 o A Key Encapsulation Mechanism (KEM): 169 * GenerateKeyPair(): Generate a key pair (sk, pk) 171 * Marshal(pk): Produce a fixed-length octet string encoding the 172 public key "pk" 174 * Unmarshal(enc): Parse a fixed-length octet string to recover a 175 public key 177 * Encap(pk): Generate an ephemeral symmetric key and a fixed- 178 length encapsulation of that key that can be decapsulated by 179 the holder of the private key corresponding to pk 181 * Decap(enc, sk): Use the private key "sk" to recover the 182 ephemeral symmetric key from its encapsulated representation 183 "enc" 185 * AuthEncap(pkR, skI) (optional): Same as Encap(), but the 186 outputs encode an assurance that the ephemeral shared key is 187 known only to the holder of the private key "skI" 189 * AuthDecap(skR, pkI) (optional): Same as Decap(), but the holder 190 of the private key "skR" is assured that the ephemeral shared 191 key is known only to the holder of the private key 192 corresponding to "pkI" 194 * Nenc: The length in octets of an encapsulated key from this KEM 196 * Npk: The length in octets of a public key for this KEM 198 o A Key Derivation Function: 200 * Extract(salt, IKM): Extract a pseudorandom key of fixed length 201 from input keying material "IKM" and an optional octet string 202 "salt" 204 * Expand(PRK, info, L): Expand a pseudorandom key "PRK" using 205 optional string "info" into "L" bytes of output keying material 207 * Nh: The output size of the Extract function 209 o An AEAD encryption algorithm [RFC5116]: 211 * Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext 212 "pt" with associated data "aad" using secret key "key" and 213 nonce "nonce", yielding ciphertext and tag "ct" 215 * Open(key, nonce, aad, ct): Decrypt ciphertext "ct" using 216 associated data "aad" with secret key "key" and nonce "nonce", 217 returning plaintext message "pt" or the error value "OpenError" 219 * Nk: The length in octets of a key for this algorithm 221 * Nn: The length in octets of a nonce for this algorithm 223 A set of algorithm identifiers for concrete instantiations of these 224 primitives is provided in Section 7. Algorithm identifier values are 225 two octets long. 227 5.1. DH-Based KEM 229 Suppose we are given a Diffie-Hellman group that provides the 230 following operations: 232 o GenerateKeyPair(): Generate an ephemeral key pair "(sk, pk)" for 233 the DH group in use 235 o DH(sk, pk): Perform a non-interactive DH exchange using the 236 private key sk and public key pk to produce a fixed-length shared 237 secret 239 o Marshal(pk): Produce a fixed-length octet string encoding the 240 public key "pk" 242 o Unmarshal(enc): Parse a fixed-length octet string to recover a 243 public key 245 Then we can construct a KEM (which we'll call "DHKEM") in the 246 following way: 248 def Encap(pkR): 249 skE, pkE = GenerateKeyPair() 250 zz = DH(skE, pkR) 251 enc = Marshal(pkE) 252 return zz, enc 254 def Decap(enc, skR): 255 pkE = Unmarshal(enc) 256 return DH(skR, pkE) 258 def AuthEncap(pkR, skI): 259 skE, pkE = GenerateKeyPair() 260 zz = concat(DH(skE, pkR), DH(skI, pkR)) 261 enc = Marshal(pkE) 262 return zz, enc 264 def AuthDecap(enc, skR, pkI): 265 pkE = Unmarshal(enc) 266 return concat(DH(skR, pkE), DH(skR, pkI)) 268 The GenerateKeyPair, Marshal, and Unmarshal functions are the same as 269 for the underlying DH group. The Marshal functions for the curves 270 referenced in {#ciphersuites} are as follows: 272 o P-256: The X-coordinate of the point, encoded as a 32-octet big- 273 endian integer 275 o P-521: The X-coordinate of the point, encoded as a 66-octet big- 276 endian integer 278 o Curve25519: The standard 32-octet representation of the public key 280 o Curve448: The standard 56-octet representation of the public key 282 6. Hybrid Public Key Encryption 284 In this section, we define a few HPKE variants. All variants take a 285 recipient public key and a sequence of plaintexts "pt", and produce 286 an encapsulated key "enc" and a sequence of ciphertexts "ct". These 287 outputs are constructed so that only the holder of the private key 288 corresponding to "pkR" can decapsulate the key from "enc" and decrypt 289 the ciphertexts. All of the algorithms also take an "info" parameter 290 that can be used to influence the generation of keys (e.g., to fold 291 in identity information) and an "aad" parameter that provides 292 Additional Authenticated Data to the AEAD algorithm in use. 294 In addition to the base case of encrypting to a public key, we 295 include two authenticated variants, one of which authenticates 296 possession of a pre-shared key, and one of which authenticates 297 possession of a KEM private key. The following one-octet values will 298 be used to distinguish between modes: 300 +---------------+-------+ 301 | Mode | Value | 302 +---------------+-------+ 303 | mode_base | 0x00 | 304 | | | 305 | mode_psk | 0x01 | 306 | | | 307 | mode_auth | 0x02 | 308 | | | 309 | mode_psk_auth | 0x03 | 310 +---------------+-------+ 312 All of these cases follow the same basic two-step pattern: 314 1. Set up an encryption context that is shared between the sender 315 and the recipient 317 2. Use that context to encrypt or decrypt content 319 A "context" encodes the AEAD algorithm and key in use, and manages 320 the nonces used so that the same nonce is not used with multiple 321 plaintexts. 323 The procedures described in this session are laid out in a Python- 324 like pseudocode. The algorithms in use are left implicit. 326 6.1. Creating an Encryption Context 328 The variants of HPKE defined in this document share a common 329 mechanism for translating the protocol inputs into an encryption 330 context. The key schedule inputs are as follows: 332 o "pkR" - The receiver's public key 334 o "zz" - A shared secret generated via the KEM for this transaction 336 o "enc" - An encapsulated key produced by the KEM for the receiver 337 o "info" - Application-supplied information (optional; default value 338 "") 340 o "psk" - A pre-shared secret held by both the initiator and the 341 receiver (optional; default value "zero(Nh)"). 343 o "pskID" - An identifier for the PSK (optional; default value """ = 344 zero(0)" 346 o "pkI" - The initiator's public key (optional; default value 347 "zero(Npk)") 349 The "psk" and "pskID" fields MUST appear together or not at all. 350 That is, if a non-default value is provided for one of them, then the 351 other MUST be set to a non-default value. 353 The key and nonce computed by this algorithm have the property that 354 they are only known to the holder of the receipient private key, and 355 the party that ran the KEM to generate "zz" and "enc". If the "psk" 356 and "pskID" arguments are provided, then the recipient is assured 357 that the initiator held the PSK. If the "pkIm" argument is provided, 358 then the recipient is assued that the initator held the corresponding 359 private key (assuming that "zz" and "enc" were generated using the 360 AuthEncap / AuthDecap methods; see below). 362 default_pkIm = zero(Npk) 363 default_psk = zero(Nh) 364 default_pskId = zero(0) 366 def VerifyMode(mode, psk, pskID, pkIm): 367 got_psk = (psk != default_psk and pskID != default_pskID) 368 no_psk = (psk == default_psk and pskID == default_pskID) 369 got_pkIm = (pkIm != default_pkIm) 370 no_pkIm = (pkIm == default_pkIm) 372 if mode == mode_base and (got_psk or got_pkIm): 373 raise Exception("Invalid configuration for mode_base") 374 if mode == mode_psk and (no_psk or got_pkIm): 375 raise Exception("Invalid configuration for mode_psk") 376 if mode == mode_auth and (got_psk or no_pkIm): 377 raise Exception("Invalid configuration for mode_auth") 378 if mode == mode_psk_auth and (no_psk or no_pkIm): 379 raise Exception("Invalid configuration for mode_psk_auth") 381 def EncryptionContext(mode, pkRm, zz, enc, info, psk, pskID, pkIm): 382 VerifyMode(mode, psk, pskID, pkI) 384 pkRm = Marshal(pkR) 385 context = concat(mode, ciphersuite, enc, pkRm, pkIm, 386 len(pskID), pskID, len(info), info) 388 secret = Extract(psk, zz) 389 key = Expand(secret, concat("hpke key", context), Nk) 390 nonce = Expand(secret, concat("hpke nonce", context), Nn) 391 return Context(key, nonce) 393 Note that the context construction in the KeySchedule procedure is 394 equivalent to serializing a structure of the following form in the 395 TLS presentation syntax: 397 struct { 398 // Mode and algorithms 399 uint8 mode; 400 uint16 ciphersuite; 402 // Public inputs to this key exchange 403 opaque enc[Nenc]; 404 opaque pkR[Npk]; 405 opaque pkI[Npk]; 406 opaque pskID<0..2^16-1>; 408 // Application-supplied info 409 opaque info<0..2^16-1>; 410 } HPKEContext; 412 6.2. Encryption to a Public Key 414 The most basic function of an HPKE scheme is to enable encryption for 415 the holder of a given KEM private key. The "SetupBaseI()" and 416 "SetupBaseR()" procedures establish contexts that can be used to 417 encrypt and decrypt, respectively, for a given private key. 419 The the shared secret produced by the KEM is combined via the KDF 420 with information describing the key exchange, as well as the explicit 421 "info" parameter provided by the caller. 423 def SetupBaseI(pkR, info): 424 zz, enc = Encap(pkR) 425 return enc, KeySchedule(mode_base, pkR, zz, enc, info, 426 default_psk, default_pskID, default_pkIm) 428 def SetupBaseR(enc, skR, info): 429 zz = Decap(enc, skR) 430 return KeySchedule(mode_base, pk(skR), zz, enc, info, 431 default_psk, default_pskID, default_pkIm) 433 6.3. Authentication using a Pre-Shared Key 435 This variant extends the base mechansism by allowing the recipient to 436 authenticate that the sender possessed a given pre-shared key (PSK). 437 We assume that both parties have been provisioned with both the PSK 438 value "psk" and another octet string "pskID" that is used to identify 439 which PSK should be used. 441 The primary differences from the base case are: 443 o The PSK is used as the "salt" input to the KDF (instead of 0) 444 o The PSK ID is added to the context string used as the "info" input 445 to the KDF 447 This mechanism is not suitable for use with a low-entropy password as 448 the PSK. A malicious recipient that does not possess the PSK can use 449 decryption of a plaintext as an oracle for performing offline 450 dictionary attacks. 452 def SetupPSKI(pkR, psk, pskID, info): 453 zz, enc = Encap(pkR) 454 return enc, KeySchedule(pkR, zz, enc, info, 455 psk, pskId, default_pkIm) 457 def SetupPSKR(enc, skR, psk, pskID, info): 458 zz = Decap(enc, skR) 459 return KeySchedule(pk(skR), zz, enc, info, 460 psk, pskId, default_pkIm) 462 6.4. Authentication using an Asymmetric Key 464 This variant extends the base mechansism by allowing the recipient to 465 authenticate that the sender possessed a given KEM private key. This 466 assurance is based on the assumption that "AuthDecap(enc, skR, pkI)" 467 produces the correct shared secret only if the encapsulated value 468 "enc" was produced by "AuthEncap(pkR, skI)", where "skI" is the 469 private key corresponding to "pkI". In other words, only two people 470 could have produced this secret, so if the recipient is one, then the 471 sender must be the other. 473 The primary differences from the base case are: 475 o The calls to "Encap" and "Decap" are replaced with calls to 476 "AuthEncap" and "AuthDecap". 478 o The initiator public key is added to the context string 480 Obviously, this variant can only be used with a KEM that provides 481 "AuthEncap()" and "AuthDecap()" procuedures. 483 This mechanism authenticates only the key pair of the initiator, not 484 any other identity. If an application wishes to authenticate some 485 other identity for the sender (e.g., an email address or domain 486 name), then this identity should be included in the "info" parameter 487 to avoid unknown key share attacks. 489 def SetupAuthI(pkR, skI, info): 490 zz, enc = AuthEncap(pkR, skI) 491 pkIm = Marshal(pk(skI)) 492 return enc, KeySchedule(pkR, zz, enc, info, 493 default_psk, default_pskID, pkIm) 495 def SetupAuthR(enc, skR, pkI, info): 496 zz = AuthDecap(enc, skR, pkI) 497 pkIm = Marshal(pkI) 498 return KeySchedule(pk(skR), zz, enc, info, 499 default_psk, default_pskID, pkIm) 501 6.5. Authentication using both a PSK and an Asymmetric Key 503 This mode is a straightforward combination of the PSK and 504 authenticated modes. The PSK is passed through to the key schedule 505 as in the former, and as in the latter, we use the authenticated KEM 506 variants. 508 def SetupAuthI(pkR, psk, pskID, skI, info): 509 zz, enc = AuthEncap(pkR, skI) 510 pkIm = Marshal(pk(skI)) 511 return enc, KeySchedule(pkR, zz, enc, info, psk, pskID, pkIm) 513 def SetupAuthR(enc, skR, psk, pskID, pkI, info): 514 zz = AuthDecap(enc, skR, pkI) 515 pkIm = Marshal(pkI) 516 return KeySchedule(pk(skR), zz, enc, info, psk, pskID, pkIm) 518 6.6. Encryption and Decryption 520 HPKE allows multiple encryption operations to be done based on a 521 given setup transaction. Since the public-key operations involved in 522 setup are typically more expensive than symmetric encryption or 523 decryption, this allows applications to "amortize" the cost of the 524 public-key operations, reducing the overall overhead. 526 In order to avoid nonce reuse, however, this decryption must be 527 stateful. Each of the setup procedures above produces a context 528 object that stores the required state: 530 o The AEAD algorithm in use 532 o The key to be used with the AEAD algorithm 534 o A base nonce value 536 o A sequence number (initially 0) 537 All of these fields except the sequence number are constant. The 538 sequence number is used to provide nonce uniqueness: The nonce used 539 for each encryption or decryption operation is the result of XORing 540 the base nonce with the current sequence number, encoded as a big- 541 endian integer of the same length as the nonce. Implementations MAY 542 use a sequence number that is shorter than the nonce (padding on the 543 left with zero), but MUST return an error if the sequence number 544 overflows. 546 Each encryption or decryption operation increments the sequence 547 number for the context in use. A given context SHOULD be used either 548 only for encryption or only for decryption. 550 It is up to the application to ensure that encryptions and 551 decryptions are done in the proper sequence, so that the nonce values 552 used for encryption and decryption line up. 554 [[ TODO: Check for overflow, a la TLS ]] 555 def Context.Nonce(seq): 556 encSeq = encode_big_endian(seq, len(self.nonce)) 557 return xor(self.nonce, encSeq) 559 def Context.Seal(aad, pt): 560 ct = Seal(self.key, self.Nonce(self.seq), aad, pt) 561 self.seq += 1 562 return ct 564 def Context.Open(aad, ct): 565 pt = Open(self.key, self.Nonce(self.seq), aad, ct) 566 if pt == OpenError: 567 return OpenError 568 self.seq += 1 569 return pt 571 7. Algorithm Identifiers 573 7.1. Key Encapsulation Mechanisms (KEMs) 574 +--------+-------------------+------+-----+--------------+ 575 | Value | KEM | Nenc | Npk | Reference | 576 +--------+-------------------+------+-----+--------------+ 577 | 0x0000 | (reserved) | N/A | N/A | N/A | 578 | | | | | | 579 | 0x0001 | DHKEM(P-256) | 32 | 32 | [NISTCurves] | 580 | | | | | | 581 | 0x0002 | DHKEM(Curve25519) | 32 | 32 | [RFC7748] | 582 | | | | | | 583 | 0x0003 | DHKEM(P-521) | 65 | 65 | [NISTCurves] | 584 | | | | | | 585 | 0x0004 | DHKEM(Curve448) | 56 | 56 | [RFC7748] | 586 +--------+-------------------+------+-----+--------------+ 588 For the NIST curves P-256 and P-521, the Marshal function of the DH 589 scheme produces the normal (non-compressed) representation of the 590 public key, according to [SECG]. When these curves are used, the 591 recipient of an HPKE ciphertext MUST validate that the ephemeral 592 public key "pkE" is on the curve. The relevant validation procedures 593 are defined in [keyagreement] 595 For the CFRG curves Curve25519 and Curve448, the Marshal function is 596 the identity function, since these curves already use fixed-length 597 octet strings for public keys. 599 7.2. Key Derivation Functions (KDFs) 601 +--------+-------------+-----+-----------+ 602 | Value | KDF | Nh | Reference | 603 +--------+-------------+-----+-----------+ 604 | 0x0000 | (reserved) | N/A | N/A | 605 | | | | | 606 | 0x0001 | HKDF-SHA256 | 32 | [RFC5869] | 607 | | | | | 608 | 0x0002 | HKDF-SHA512 | 64 | [RFC5869] | 609 +--------+-------------+-----+-----------+ 611 7.3. Authentication Encryption with Associated Data (AEAD) Functions 612 +--------+------------------+-----+-----+-----------+ 613 | Value | AEAD | Nk | Nn | Reference | 614 +--------+------------------+-----+-----+-----------+ 615 | 0x0000 | (reserved) | N/A | N/A | N/A | 616 | | | | | | 617 | 0x0001 | AES-GCM-128 | 16 | 12 | [GCM] | 618 | | | | | | 619 | 0x0002 | AES-GCM-256 | 32 | 12 | [GCM] | 620 | | | | | | 621 | 0x0003 | ChaCha20Poly1305 | 32 | 12 | [RFC8439] | 622 +--------+------------------+-----+-----+-----------+ 624 8. Security Considerations 626 [[ TODO ]] 628 9. IANA Considerations 630 [[ TODO: Make IANA registries for the above ]] 632 10. References 634 10.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 642 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 643 . 645 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 646 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 647 May 2017, . 649 10.2. Informative References 651 [ANSI] "Public Key Cryptography for the Financial Services 652 Industry -- Key Agreement and Key Transport Using Elliptic 653 Curve Cryptography", n.d.. 655 [fiveG] "Security architecture and procedures for 5G System", 656 n.d., 657 . 660 [GCM] Dworkin, M., "Recommendation for block cipher modes of 661 operation :", National Institute of Standards and 662 Technology report, DOI 10.6028/nist.sp.800-38d, 2007. 664 [I-D.ietf-mls-protocol] 665 Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and 666 R. Robert, "The Messaging Layer Security (MLS) Protocol", 667 draft-ietf-mls-protocol-06 (work in progress), May 2019. 669 [I-D.ietf-tls-esni] 670 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 671 "Encrypted Server Name Indication for TLS 1.3", draft- 672 ietf-tls-esni-03 (work in progress), March 2019. 674 [IEEE] "IEEE 1363a, Standard Specifications for Public Key 675 Cryptography - Amendment 1 -- Additional Techniques", 676 n.d.. 678 [ISO] "ISO/IEC 18033-2, Information Technology - Security 679 Techniques - Encryption Algorithms - Part 2 -- Asymmetric 680 Ciphers", n.d.. 682 [keyagreement] 683 Barker, E., Chen, L., Roginsky, A., and M. Smid, 684 "Recommendation for Pair-Wise Key Establishment Schemes 685 Using Discrete Logarithm Cryptography", National Institute 686 of Standards and Technology report, 687 DOI 10.6028/nist.sp.800-56ar2, May 2013. 689 [MAEA10] "A Comparison of the Standardized Versions of ECIES", 690 n.d., . 693 [NISTCurves] 694 "Digital Signature Standard (DSS)", National Institute of 695 Standards and Technology report, 696 DOI 10.6028/nist.fips.186-4, July 2013. 698 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 699 Key Derivation Function (HKDF)", RFC 5869, 700 DOI 10.17487/RFC5869, May 2010, 701 . 703 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 704 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 705 . 707 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 708 for Security", RFC 7748, DOI 10.17487/RFC7748, January 709 2016, . 711 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 712 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 713 . 715 [S01] "A Proposal for an ISO Standard for Public Key Encryption 716 (verison 2.1)", n.d., 717 . 719 [SECG] "Elliptic Curve Cryptography, Standards for Efficient 720 Cryptography Group, ver. 2", n.d., 721 . 723 Appendix A. Possible TODOs 725 The following extensions might be worth specifying: 727 o Multiple recipients - It might be possible to add some 728 simplifications / assurances for the case where the same value is 729 being encrypted to multiple recipients. 731 o Test vectors - Obviously, we can provide decryption test vectors 732 in this document. In order to provide known-answer tests, we 733 would have to introduce a non-secure deterministic mode where the 734 ephemeral key pair is derived from the inputs. And to do that 735 safely, we would need to augment the decrypt function to detect 736 the deterministic mode and fail. 738 o A reference implementation in hacspec or similar 740 Authors' Addresses 742 Richard L. Barnes 743 Cisco 745 Email: rlb@ipv.sx 747 Karthik Bhargavan 748 Inria 750 Email: karthikeyan.bhargavan@inria.fr