Hybrid Public Key Encryption
draft-irtf-cfrg-hpke-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-02-23
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-01-07
|
12 | (System) | RFC Editor state changed to AUTH48 |
2021-12-03
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-11-17
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-11-16
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-11-16
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-11-16
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-11-12
|
12 | (System) | RFC Editor state changed to EDIT |
2021-11-11
|
12 | (System) | IANA Action state changed to In Progress |
2021-11-11
|
12 | Colin Perkins | IRTF state changed to Sent to the RFC Editor from In IESG Review |
2021-11-11
|
12 | Colin Perkins | Sent request for publication to the RFC Editor |
2021-09-15
|
12 | (System) | IANA Review state changed to IANA OK - Actions Needed |
2021-09-15
|
12 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors: The IANA Functions Operator has completed its review of draft-irtf-cfrg-hpke-12. If any part of this review is inaccurate, please let us … (Via drafts-eval@iana.org): IESG/Authors: The IANA Functions Operator has completed its review of draft-irtf-cfrg-hpke-12. If any part of this review is inaccurate, please let us know. We understand that when this document is sent to us for processing, three registries should be created under the new heading "Hybrid Public Key Encryption (HPKE)": Registry Name: HPKE KEM Identifiers Registration Procedure: Specification Required Expert(s): Unassigned +=======+===============+=========+====+===+===+====+===============+ |Value | KEM | Nsecret |Nenc|Npk|Nsk|Auth| Reference | +=======+===============+=========+====+===+===+====+===============+ |0x0000 | Reserved | N/A |N/A |N/A|N/A|yes | [RFCXXXX] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0001-| Unassigned | | | | | | | |0x000F | | | | | | | | +-------+---------------+---------+----+---+---+----+---------------+ |0x0010 | DHKEM(P-256, | 32 |65 |65 |32 |yes | [NISTCurves], | | | HKDF-SHA256) | | | | | | [RFC5869] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0011 | DHKEM(P-384, | 48 |97 |97 |48 |yes | [NISTCurves], | | | HKDF-SHA384) | | | | | | [RFC5869] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0012 | DHKEM(P-521, | 64 |133 |133|66 |yes | [NISTCurves], | | | HKDF-SHA512) | | | | | | [RFC5869] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0013-| Unassigned | | | | | | | |0x001F | | | | | | | | +-------+---------------+---------+----+---+---+----+---------------+ |0x0020 | DHKEM(X25519, | 32 |32 |32 |32 |yes | [RFC7748], | | | HKDF-SHA256) | | | | | | [RFC5869] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0021 | DHKEM(X448, | 64 |56 |56 |56 |yes | [RFC7748], | | | HKDF-SHA512) | | | | | | [RFC5869] | +-------+---------------+---------+----+---+---+----+---------------+ |0x0022-| Unassigned | | | | | | | |0xFFFF | | | | | | | | +-------+---------------+---------+----+---+---+----+---------------+ Registry Name: HPKE KDF Identifiers Registration Procedure: Specification Required Expert(s): Unassigned +========+=============+=====+===========+ | Value | KDF | Nh | Reference | +========+=============+=====+===========+ | 0x0000 | Reserved | N/A | [RFCXXXX] | +--------+-------------+-----+-----------+ | 0x0001 | HKDF-SHA256 | 32 | [RFC5869] | +--------+-------------+-----+-----------+ | 0x0002 | HKDF-SHA384 | 48 | [RFC5869] | +--------+-------------+-----+-----------+ | 0x0003 | HKDF-SHA512 | 64 | [RFC5869] | +--------+-------------+-----+-----------+ | 0x0004-| Unassigned | | | | 0xFFFF | | | | +--------+-------------+-----+-----------+ Registry Name: HPKE AEAD Identifiers Registration Procedure: Specification Required Expert(s): Unassigned +========+==================+=====+=====+=====+=============+ | Value | AEAD | Nk | Nn | Nt | Reference | +========+==================+=====+=====+=====+=============+ | 0x0000 | Reserved | N/A | N/A | N/A | [RFCXXXX] | +--------+------------------+-----+-----+-----+-------------+ | 0x0001 | AES-128-GCM | 16 | 12 | 16 | [GCM] | +--------+------------------+-----+-----+-----+-------------+ | 0x0002 | AES-256-GCM | 32 | 12 | 16 | [GCM] | +--------+------------------+-----+-----+-----+-------------+ | 0x0003 | ChaCha20Poly1305 | 32 | 12 | 16 | [RFC8439] | +--------+------------------+-----+-----+-----+-------------+ | 0x0004-| Unassigned | | | | | | 0xFFFE | | | | | | +--------+------------------+-----+-----+-----+-------------+ | 0xFFFF | Export-only | N/A | N/A | N/A | [[RFCXXXX]] | +--------+------------------+-----+-----+-----+-------------+ Thank you, Amanda Baber IANA Operations Manager |
2021-09-08
|
12 | Colin Perkins | IRTF state changed to In IESG Review from IRSG Review |
2021-09-08
|
12 | Colin Perkins | IETF conflict review initiated - see conflict-review-irtf-cfrg-hpke |
2021-09-02
|
12 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-12.txt |
2021-09-02
|
12 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-09-02
|
12 | Christopher Wood | Uploaded new revision |
2021-08-02
|
11 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-11.txt |
2021-08-02
|
11 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-08-02
|
11 | Christopher Wood | Uploaded new revision |
2021-07-07
|
10 | (System) | Revised ID Needed tag cleared |
2021-07-07
|
10 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-10.txt |
2021-07-07
|
10 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-07-07
|
10 | Christopher Wood | Uploaded new revision |
2021-06-27
|
09 | Colin Perkins | Review I-D needed to address review comments from Spencer and Kirsty P. |
2021-06-27
|
09 | Colin Perkins | Tag Revised I-D Needed set. |
2021-06-27
|
09 | Colin Perkins | IRTF state changed to IRSG Review from In IRSG Poll |
2021-06-27
|
09 | Colin Perkins | Closed "IRSG Approve" ballot |
2021-06-27
|
09 | Colin Perkins | [Ballot comment] Changing my ballot from "No Objection" to "Yes", now we also have an additional external review from Kirsty P. I believe once her … [Ballot comment] Changing my ballot from "No Objection" to "Yes", now we also have an additional external review from Kirsty P. I believe once her comments, and those from Spencer, are addressed, then this will be ready for publication. |
2021-06-27
|
09 | Colin Perkins | [Ballot Position Update] Position for Colin Perkins has been changed to Yes from No Objection |
2021-06-18
|
09 | Spencer Dawkins | [Ballot comment] This isn't even remotely a topic I'm smart about, but the document was clearly written, and I can imagine using it as an … [Ballot comment] This isn't even remotely a topic I'm smart about, but the document was clearly written, and I can imagine using it as an implementer. I do have some nits, so please Do The Right Thing. At the bottom of Section 5, this sentence, "The procedures described in this session are laid out in a Python-like pseudocode", and that's the only occurence of "session" in the document. I don't know what "this session" is intended to refer to - I can guess, but I'd be guessing. Is it something like "in the following *sections*"? In this text, "This assurance is based on the assumption that AuthDecap(enc, skR, pkS) produces the correct KEM shared secret only if the encapsulated value enc was produced by AuthEncap(pkR, skS), where skS is the private key corresponding to pkS", is "assumption" the right word? "Assumption" makes me look for some mention of evidence that would support that assumption, but reading further, I'm led to believe that this is a fundamental property, not an assumption. In this text, "In many cases, applications encrypt only a single message to a recipient's public key", is "to the recipient's public key" the right way to say this? I was guessing this meant "In many cases, applications encrypt only a single message using a recipient's public key" In this text, "The precise likelihood of DeriveKeyPair() failing with DeriveKeyPairError depends on the group being used, but it is negligibly small in all cases", is there any obvious action that an implementer could take if this DOES happen? I wonder if Section 7.1.5. KEM Key Reuse should appear in the security considerations section, or perhaps even just be mentioned there, with a reference to its current location. Perhaps even in Section 9.2? But just having this appear in Section 7 without a mention in Section 9 seems counterintuitive. Hmmm. Section 5.3 says this: “Applications that do not use the encryption API in Section 5.2 can use the export-only AEAD ID 0xFFFF when computing the key schedule. Such applications can avoid computing the key and base_nonce values in the key schedule, as they are not used by the Export interface described above”, but Section 7.3 says “The 0xFFFF AEAD ID is reserved for applications which only use the Export interface; see Section 5.3 for more details”. Would saying “Applications that do not use the encryption API in Section 5.2 can use the export-only AEAD ID 0xFFFF when computing the key schedule” in Section 7.3 be accurate? If so, it would be more obvious that these two statements apply in the same conditions if they use the same phrasing. I may be going blind (and that would be a pity, since I had cataract surgery earlier this year), but I can’t see the difference between what’s said about DHKEM in Extract() and Expand() (in DHKEM): Extract() can be modeled as a random oracle. Expand() can be modeled as a pseudorandom function, wherein the first argument is the key. and what’s said about “elsewhere” in Extract() and Expand() (elsewhere): Extract() can be modeled as a random oracle. Expand() can be modeled as a pseudorandom function, wherein the first argument is the key. Is there a difference? I see text in Section 9.5 that looks like it might be related, but I just don’t have the background to know for sure. In 11.1. KEM Identifiers, “The "HPKE KEM Identifiers" registry lists identifiers for key encapsulation algorithms defined for use with HPKE. These are two-byte values, so the maximum possible value is 0xFFFF = 65535”, These “might” be clearer as “These identifiers” (same comment in 11.2 and 11.3). |
2021-06-18
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2021-06-18
|
09 | Stanislav Smyshlyaev | [Ballot comment] I am the document shepherd. |
2021-06-18
|
09 | Stanislav Smyshlyaev | [Ballot Position Update] New position, Yes, has been recorded for Stanislav Smyshlyaev |
2021-06-18
|
09 | David Oran | [Ballot Position Update] New position, No Objection, has been recorded for David Oran |
2021-06-18
|
09 | Colin Perkins | [Ballot Position Update] New position, No Objection, has been recorded for Colin Perkins |
2021-05-28
|
09 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2021-05-28
|
09 | Colin Perkins | IRTF state changed to In IRSG Poll from Awaiting IRSG Reviews |
2021-05-28
|
09 | Colin Perkins | Created IRSG Ballot |
2021-05-26
|
09 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-09.txt |
2021-05-26
|
09 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-05-26
|
09 | Christopher Wood | Uploaded new revision |
2021-03-23
|
08 | Colin Perkins | IRTF state changed to Awaiting IRSG Reviews from Waiting for IRTF Chair |
2021-02-15
|
08 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-08.txt |
2021-02-15
|
08 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-02-15
|
08 | Christopher Wood | Uploaded new revision |
2020-12-18
|
07 | Stanislav Smyshlyaev | Requesting publication as an RFC on behalf of CFRG. |
2020-12-18
|
07 | Stanislav Smyshlyaev | IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd |
2020-12-18
|
07 | Stanislav Smyshlyaev | Technical Summary This document describes a scheme for hybrid public-key encryption, defined for a combination of a key encapsulation mechanism, a key derivation function (in … Technical Summary This document describes a scheme for hybrid public-key encryption, defined for a combination of a key encapsulation mechanism, a key derivation function (in an Extract/Expand form) and an AEAD mechanism. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Working Group Summary After adopting the document it was presented in several face-to-face CFRG meetings. There were two Research Group Last Calls for the draft in 2020. One major change that had been made before the Second RGLC was addressing a security related concern described by Julia Len. Julia Len later confirmed that she is happy with the updated version of the draft. Crypto Review Panel reviews were solicited in June 2020 and August 2020. The reviews were provided by Jean-Philippe Aumasson and Stephen Farrell. Comments from these reviews were addressed in -05 and -06. The authors have answered the questions raised during the second Research Group Last Call, no questions remain unanswered. Document Quality There are at least ten implementations, see https://github.com/cfrg/draft-irtf-cfrg-hpke#existing-hpke-implementations. The construction is used in the Messaging Layer Security, Oblivious DNS Over HTTPS and TLS Encrypted Client Hello protocols. Personnel Stanislav Smyshlyaev is the Document Shepherd. Colin Perkins is the IRTF Chair. |
2020-12-16
|
07 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-07.txt |
2020-12-16
|
07 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-12-16
|
07 | Christopher Wood | Uploaded new revision |
2020-10-23
|
06 | (System) | Revised ID Needed tag cleared |
2020-10-23
|
06 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-06.txt |
2020-10-23
|
06 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-10-23
|
06 | Christopher Wood | Uploaded new revision |
2020-09-08
|
05 | Alexey Melnikov | Tag Revised I-D Needed set. |
2020-09-08
|
05 | Alexey Melnikov | IRTF state changed to Waiting for Document Shepherd from In RG Last Call |
2020-09-08
|
05 | Alexey Melnikov | Second RGLC was issued on August 18th and it ended on August 31st. |
2020-09-08
|
05 | Alexey Melnikov | Notification list changed to Stanislav Smyshlyaev <smyshsv@gmail.com> |
2020-09-08
|
05 | Alexey Melnikov | Document shepherd changed to Stanislav V. Smyshlyaev |
2020-07-30
|
05 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-05.txt |
2020-07-30
|
05 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-07-30
|
05 | Christopher Wood | Uploaded new revision |
2020-06-19
|
04 | Alexey Melnikov | Of course I meant May 24th |
2020-05-09
|
04 | Alexey Melnikov | Till March 24th 2020. |
2020-05-09
|
04 | Alexey Melnikov | IRTF state changed to In RG Last Call |
2020-05-09
|
04 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2020-05-08
|
04 | Christopher Wood | New version available: draft-irtf-cfrg-hpke-04.txt |
2020-05-08
|
04 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-05-08
|
04 | Christopher Wood | Uploaded new revision |
2020-05-05
|
03 | Richard Barnes | New version available: draft-irtf-cfrg-hpke-03.txt |
2020-05-05
|
03 | (System) | New version approved |
2020-05-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: irtf-chair@irtf.org, cfrg-chairs@ietf.org, Karthikeyan Bhargavan , Richard Barnes |
2020-05-05
|
03 | Richard Barnes | Uploaded new revision |
2019-11-08
|
02 | Alexey Melnikov | Added to session: IETF-106: cfrg Wed-1330 |
2019-11-04
|
02 | Richard Barnes | New version available: draft-irtf-cfrg-hpke-02.txt |
2019-11-04
|
02 | (System) | New version accepted (logged-in submitter: Richard Barnes) |
2019-11-04
|
02 | Richard Barnes | Uploaded new revision |
2019-11-04
|
01 | Richard Barnes | New version available: draft-irtf-cfrg-hpke-01.txt |
2019-11-04
|
01 | (System) | New version accepted (logged-in submitter: Richard Barnes) |
2019-11-04
|
01 | Richard Barnes | Uploaded new revision |
2019-07-21
|
00 | Alexey Melnikov | Intended Status changed to Informational from None |
2019-07-21
|
00 | Alexey Melnikov | This document now replaces draft-barnes-cfrg-hpke instead of None |
2019-07-04
|
00 | Richard Barnes | New version available: draft-irtf-cfrg-hpke-00.txt |
2019-07-04
|
00 | (System) | WG -00 approved |
2019-07-03
|
00 | Richard Barnes | Set submitter to ""Richard L. Barnes" ", replaces to (none) and sent approval email to group chairs: cfrg-chairs@ietf.org |
2019-07-03
|
00 | Richard Barnes | Uploaded new revision |