Subject: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt

From: Jean-Philippe Aumasson <[email-masked]>
Date: Mon, 26 Oct 2020 15:08:55 +0100

Hi!

quick comments on the new draft, as solicited by the chairs (thanks for
reminding me of this!):

as commented in my review, and as discussed more recently with Ben Lipp, I
just find that directly defining the KDR in terms extract/expand internal
operations will prevent the adoption of other KDFs than HKDF. The
construction could be defined in terms of a generic KDF block and retain
its security properties (KeySchedule() might have to be adapted).

Otherwise no objection :)

Cheers,

JP

--

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Crypto Forum RG of the IRTF.

        Title           : Hybrid Public Key Encryption
        Authors         : Richard L. Barnes
                          Karthik Bhargavan
                          Benjamin Lipp
                          Christopher A. Wood
Filename        : draft-irtf-cfrg-hpke-06.txt
Pages           : 87
Date            : 2020-10-23

Abstract:
   This document describes a scheme for hybrid public-key encryption
   (HPKE).  This scheme provides authenticated public key encryption of
   arbitrary-sized plaintexts for a recipient public key.  HPKE works
   for any combination of an asymmetric key encapsulation mechanism
   (KEM), key derivation function (KDF), and authenticated encryption
   with additional data (AEAD) encryption function.  We provide
   instantiations of the scheme using widely-used and efficient
   primitives, such as Elliptic Curve Diffie-Hellman key agreement,
   HKDF, and SHA2.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-hpke-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt  internet-drafts

---

From: Loup Vaillant-David <[email-masked]>
Date: Mon, 26 Oct 2020 17:19:05 +0100

Hi,

> as commented in my review, and as discussed more recently with Ben
> Lipp, I just find that directly defining the KDR in terms
> extract/expand internal operations will prevent the adoption of other
> KDFs than HKDF.

I believe this is already happening here and there. The Noise protocol
for instance could have used a generic KDF block, but instead have
settled on HKDF, even when the underlying hash is Blake2b.

(Now JPA here obviously knows this, but for those who did not invent
Blake, Blake2b has a keyed mode that as far as I know is a fine KDF.)

Loup.

---

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Mon, 26 Oct 2020 16:49:14 +0000

Hi all,

I agree with JPA here.

A sponge-construction hash function can be a good KDF such as a KMAC or SHAKE128 (or 256) (m, d) for any fixed application-specific value d where m is input and d is the length of the output.

Regards,
Quynh.
________________________________
From: Cfrg <[email-masked]> on behalf of Jean-Philippe Aumasson <[email-masked]>
Sent: Monday, October 26, 2020 10:08 AM
To: [email-masked] <[email-masked]>
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt

Hi!

quick comments on the new draft, as solicited by the chairs (thanks for reminding me of this!):

as commented in my review, and as discussed more recently with Ben Lipp, I just find that directly defining the KDR in terms extract/expand internal operations will prevent the adoption of other KDFs than HKDF. The construction could be defined in terms of a generic KDF block and retain its security properties (KeySchedule() might have to be adapted).

Cheers,

JP

--

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum RG of the IRTF.

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-hpke%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IVt0ZuwFRX95wPmtB0d9yNbLbRCdhyfuU8PnPz3JWo4%3D&reserved=0>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-06.html<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-irtf-cfrg-hpke-06.html&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3pki68T7PGEpMxgXD3LzaPB25xF1yvAejVqP6uiCjeA%3D&reserved=0>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-hpke-06<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-irtf-cfrg-hpke-06&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948572867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vaTyIy8uEMj5P2HXHy%2BiWbcsisToYr1GzilZmiuQnu4%3D&reserved=0>

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=12%2FJbuGen2vw8OnF9UHebilkVHSK2cfkG7EuFzuqw8U%3D&reserved=0>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://gcc02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h0TzBJysx%2B6Tahqpqtakc1007jTWpWi97DUWEqnfO4Y%3D&reserved=0>

---

From: Christopher Patton <[email-masked]>
Date: Mon, 26 Oct 2020 10:04:49 -0700

Hi all,

I agree that we shouldn't discourage adoption of alternatives to HKDF.
However, I don't think the spec does so: it merely requires adherence to
the Extract-then-Expand API. There should be ways to securely "wrap"
alternatives into Extract-then-Expand API providers, perhaps at the cost of
CPU cycles. (E.g., how Noise uses Blake2b as pointed out above.)

Best,
Chris P.

On Mon, Oct 26, 2020 at 9:49 AM Dang, Quynh H. (Fed) <quynh.dang=
[email-masked]> wrote:

> Hi all,
>
> I agree with JPA here.
>
> A sponge-construction hash function can be a good KDF such as a KMAC or
> SHAKE128 (or 256) (m, d) for any fixed application-specific value d where m
> is input and d is the length of the output.
>
> Regards,
> Quynh.
> ------------------------------
> *From:* Cfrg <[email-masked]> on behalf of Jean-Philippe Aumasson <
> [email-masked]>
> *Sent:* Monday, October 26, 2020 10:08 AM
> *To:* [email-masked] <[email-masked]>
> *Subject:* [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt
>
>
> Hi!
>
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-hpke%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IVt0ZuwFRX95wPmtB0d9yNbLbRCdhyfuU8PnPz3JWo4%3D&reserved=0>
>
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-irtf-cfrg-hpke-06.html&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3pki68T7PGEpMxgXD3LzaPB25xF1yvAejVqP6uiCjeA%3D&reserved=0>
>
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-irtf-cfrg-hpke-06&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948572867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vaTyIy8uEMj5P2HXHy%2BiWbcsisToYr1GzilZmiuQnu4%3D&reserved=0>
>
>
> until the htmlized version and diff are available at tools.ietf.org
> <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=12%2FJbuGen2vw8OnF9UHebilkVHSK2cfkG7EuFzuqw8U%3D&reserved=0>
> .
>
> <https://gcc02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h0TzBJysx%2B6Tahqpqtakc1007jTWpWi97DUWEqnfO4Y%3D&reserved=0>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 28 Oct 2020 16:21:54 -0700

On Mon, Oct 26, 2020, at 10:04 AM, Christopher Patton wrote:
> However, I don't think the spec does so: it merely requires adherence 
> to the Extract-then-Expand API. There should be ways to securely "wrap" 
> alternatives into Extract-then-Expand API providers, perhaps at the 
> cost of CPU cycles. (E.g., how Noise uses Blake2b as pointed out above.)

+1.

The two-step Extract-then-Expand split does not rule out other KDFs and allows best use of HKDF out of the box. Consequently, I don't think the HPKE specification should change at this point.

Best,
Chris

> 
> Best,
> Chris P.
> 
> On Mon, Oct 26, 2020 at 9:49 AM Dang, Quynh H. (Fed) 
> <quynh.dang=[email-masked]> wrote:
> > Hi all,
> > 
> > I agree with JPA here.
> > 
> > *From:* Cfrg <[email-masked]> on behalf of Jean-Philippe Aumasson <[email-masked]>
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-hpke%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IVt0ZuwFRX95wPmtB0d9yNbLbRCdhyfuU8PnPz3JWo4%3D&reserved=0>
> > 
> > https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-06.html <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-irtf-cfrg-hpke-06.html&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948562903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3pki68T7PGEpMxgXD3LzaPB25xF1yvAejVqP6uiCjeA%3D&reserved=0>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-hpke-06 <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-irtf-cfrg-hpke-06&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948572867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vaTyIy8uEMj5P2HXHy%2BiWbcsisToYr1GzilZmiuQnu4%3D&reserved=0>
> > 
> > 
> > until the htmlized version and diff are available at tools.ietf.org <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=12%2FJbuGen2vw8OnF9UHebilkVHSK2cfkG7EuFzuqw8U%3D&reserved=0>.
> > 
> > ftp://ftp.ietf.org/internet-drafts/ <https://gcc02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cquynh.dang%40nist.gov%7Ce8fead0f0a784fa9b1a308d879b8cefd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637393181948582821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h0TzBJysx%2B6Tahqpqtakc1007jTWpWi97DUWEqnfO4Y%3D&reserved=0>
> > 
> >