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

Dan Harkins <dharkins@lounge.org> Mon, 12 July 2021 21:53 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4553A0E95 for <cfrg@ietfa.amsl.com>; Mon, 12 Jul 2021 14:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSZ6ESk6MOPp for <cfrg@ietfa.amsl.com>; Mon, 12 Jul 2021 14:53:49 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFC93A0EFF for <cfrg@irtf.org>; Mon, 12 Jul 2021 14:53:49 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QW521IU1JHMNO@wwwlocal.goatley.com> for cfrg@irtf.org; Mon, 12 Jul 2021 16:53:46 -0500 (CDT)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QW50062WJHKUE@trixy.bergandi.net> for cfrg@irtf.org; Mon, 12 Jul 2021 14:53:45 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 12 Jul 2021 14:53:45 -0700
Date: Mon, 12 Jul 2021 14:53:44 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org>
To: benjamin.lipp@inria.fr
Cc: cfrg@irtf.org
Message-id: <0e12f957-3472-84b9-e152-8372ae520535@lounge.org>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_/IhUJ53PhmO95oPWpQzDOQ)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
References: <162567329247.15923.4311477568566128956@ietfa.amsl.com> <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org>
X-PMAS-Software: PreciseMail V3.3 [210712a] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/cOnoERdd2FdqVw2kswhyTky6PPo>
Subject: Re: [CFRG] I-D Action: draft-irtf-cfrg-hpke-10.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2021 21:53:55 -0000

   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.

On Mon, 12 July 2021 18:05 UTC, Benjamin Lipp wrote:
> I don't think the addition of Section 9.4 closes the door for the draft
> on DNHPKE.

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

> 
> 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 […]
> 
> https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-10.html  <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-10.html>
> 
> 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 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.

> 
> 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  <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?

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.

On 7/12/21 9:39 AM, Dan Harkins wrote:
>
>   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, internet-drafts@ietf.org wrote:
>> 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/
>>
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> 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