Subject: [CFRG] I-D Action: draft-irtf-cfrg-hpke-10.txt

From: [email-masked]
Date: Wed, 07 Jul 2021 08:54:52 -0700

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-10.txt
	Pages           : 104
	Date            : 2021-07-07

Abstract:
   This document describes a scheme for hybrid public-key encryption
   (HPKE).  This scheme provides a variant of public-key encryption of
   arbitrary-sized plaintexts for a recipient public key.  It also
   includes three authenticated variants, including one which
   authenticates possession of a pre-shared key, and two optional ones
   which authenticate possession of a KEM private 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.  Some authenticated
   variants may not be supported by all KEMs.  We provide instantiations
   of the scheme using widely used and efficient primitives, such as
   Elliptic Curve Diffie-Hellman key agreement, HKDF, and SHA2.

   This document is a product of the Crypto Forum Research Group (CFRG)
   in the IRTF.

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-10.html

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

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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 12 Jul 2021 09:39:32 -0700

Hello,

   -10 includes a new section, 9.4, that says:

      "All AEADs MUST be IND-CCA2-secure, as is currently true for all AEADs
       listed in Section 7.3"

I don't believe this was discussed on the list and I don't agree with it.
Using the AEADs in section 7.3 will give you a construction that is IND-CCA2
secure but I don't think that all uses of HPKE MUST be.

   I have a draft on adding support for deterministic authenticated 
encryption
to HPKE and this subtle addition to -10 closes the door on that. Since 
we did
not discuss this addition I'd like to start discussing it before this draft
gets too far.

   regards,

   Dan.

On 7/7/21 8:54 AM, [email-masked] wrote:
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Benjamin Lipp <[email-masked]>
Date: Mon, 12 Jul 2021 20:05:28 +0200

Hello,

I don't think the addition of Section 9.4 closes the door for the draft
on DNHPKE.

The following sentence on IND-CCA2 security of HPKE has been included in
the HPKE draft already before -10:

> The HPKE construction defined herein is secure against (adaptive)
> chosen ciphertext attacks (IND-CCA2 secure) under classical
> assumptions about the underlying primitives […]

In my view, the newly added Section 9.4 merely makes it more explicit
what security property of the AEAD is necessary to actually achieve this
security guarantee. Also, IND-CCA2 for the AEAD has already been
mentioned as a hypothesis for the security analysis in Section 9.1
before -10.

The draft on DNHPKE contains the following paragraph:

> The security guarantee of the HPKE AEAD modes is IND-CCA2. This is achieved in part through the unique nonce requirement they all share. By removing the requirement for a unique nonce, the security guarantee of HPKE is changed for these new DAE cipher modes but the security of the existing AEAD modes is unchanged.

https://www.ietf.org/archive/id/draft-harkins-cfrg-dnhpke-00.html

Here, the DNHPKE draft changes the security guarantee for HPKE. If the
draft can do that, it should also be able to override the requirement
for AEADs used within HPKE?

Best regards,
Benjamin.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 12 Jul 2021 14:53:44 -0700

Hi Benjamin,

   I've been having trouble with my mailer and I see in the archives you 
responded
but it's not getting successfully delivered. Oh well, pardon the crafted 
response
but I did want to reply without any more delay.

> I don't think the addition of Section 9.4 closes the door for the draft

   Perhaps I am misreading things or your intent. Please read on.

> https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-10.html  <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-10.html>
> 

The text that's been there for a while talks about the construction defined
in the draft. And yes, use those KEMs and those KDFs and those AEADs and
that's what you get.

But now the draft says,

   "Future specifications may introduce new KEM, KDF, and AEAD algorithm
    identifiers provided they adhere to the security requirements in Section
    9.2, Section 9.3, and Section 9.4, respectively."

And then 9.4 says all AEADs MUST provide IND-CCA2.

   So my reading is that future specifications, like DNHPKE, can introduce
a new AEAD algorithm, which I want to do, provided it provides IND-CCA2,
which SIV does not.

> https://www.ietf.org/archive/id/draft-harkins-cfrg-dnhpke-00.html  <https://www.ietf.org/archive/id/draft-harkins-cfrg-dnhpke-00.html>
> 

Well I think DNHPKE can change the security guarantee because it's using
new algorithms and there was nothing in -09 that prohibited a newly
defined algorithm from providing a different security guarantee. But if
those algorithms are prohibited then I think we have a problem.

   If your intent is to not prohibit an AEAD algorithm which lacks IND-CCA2
from getting a magic number assigned to it from the HPKE repository of AEAD
algorithms then great, I misunderstood. Hopefully DNHPKE will get traction
and be adopted and get the code points assigned.

   If that is your intent I think it can be phrased differently. For instance,
the text in section 7 could be re-written something like:

   "The HPKE construct defined here provides IND-CCA2. Future specifications
    may introduce new KEM, KDF, and AEAD algorithm identifiers and retain this
    security guarantee provided they adhere to the requirements in Section 9.2,
    Section 9.3, and Section 9.4, respectively."

That way it's clear that the intent is to keep the guarantee you need all
the right parts together and if you don't keep all the parts together you
don't get the guarantee.

   regards,

   Dan.

---

From: Benjamin Lipp <[email-masked]>
Date: Tue, 13 Jul 2021 12:58:58 +0200

Hi Dan,

On 12/07/2021 23:53, Dan Harkins wrote:
> but it's not getting successfully delivered.

That is probably my fault – I first tried to post to the list from the
wrong sender address and so you have probably received my mail twice.
Sorry for that.

> a new AEAD algorithm, which I want to do, provided it provides IND-CCA2,

I see now what you mean. I agree the phrasing is problematic or at least
inconvenient if we indeed want to keep the possibility open that some
variants of HPKE do not provide IND-CCA2 but something else/weaker.
Thanks for clarifying.

> the right parts together and if you don't keep all the parts together you

Thanks for this suggestion.

I'll bring it to the attention of my co-authors such that we can discuss
what the intent actually was.

Best regards,
Benjamin.

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 13 Jul 2021 09:43:40 -0700

Hi Dan, all,

FYI, we just merged this PR to clarify the editorial change:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/233

We'll cut a new version of the draft ASAP.

Best,
Chris

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Jul 2021 10:05:11 -0700

Chris, Benjamin, et al,

   Thank you very much! That addresses my concern.

   regards,

   Dan.

---

From: Franziskus Kiefer <[email-masked]>
Date: Fri, 16 Jul 2021 09:25:56 +0200

Hi all,

>  7.3. Authenticated Encryption with Associated Data (AEAD) Functions

Looking at the IANA considerations I'm wondering why HPKE defines new AEAD
parameters instead of using the existing ones from
https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml.
Maybe I missed an earlier discussion on it. But I don't see the need for
new AEAD parameters.

Best,
Franziskus