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

Benjamin Lipp <benjamin.lipp@inria.fr> Mon, 12 July 2021 18:05 UTC

Return-Path: <benjamin.lipp@inria.fr>
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 EC6E03A07BA for <cfrg@ietfa.amsl.com>; Mon, 12 Jul 2021 11:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=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 dY4cQ89ENeUU for <cfrg@ietfa.amsl.com>; Mon, 12 Jul 2021 11:05:32 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 8F34E3A07B2 for <cfrg@irtf.org>; Mon, 12 Jul 2021 11:05:31 -0700 (PDT)
IronPort-HdrOrdr: A9a23:igfNW62EDBBiSP4tWyuJCgqjBSJyeYIsimQD101hICG9Lfb0qyn+pp4mPEHP4wr5AEtQ4uxpOMG7MBDhHO1OkPMs1NaZLUTbUQ6TQL2KgrGSpAEIdxeeygcZ79YZT0EcMqy9MbEZt7ed3ODQKb9Jr7e6GeKT9J7jJhxWPGNXgtRbnmNE43GgYyhLrWd9ZaYRJd653I5qtjCgcXMYYoCQHX8eRdXOoNXNidbPfQMGLwRP0njBsRqYrJrBVzSI1BYXVD1ChZ0493LergD/7qK/99mm1x7n0XPJ5Zg+oqqh9jIDPr3NtiEmEESvtu+aXvUlZ1REhkFwnAib0idorDALmWZmAy080QKWQoj/m2qR5+Cp6kdT15al8y7WvZKrm72HeBsqT8VGno5XaR3f9g4pu8x9yrtC2yaDu4NQFg6oplW02zFmbWAYqqOYmwtVrQcotQ0XbWLeUs4lkaUPuEdOVJsQFiPz744qVOFoEcHH/f5TNVeXdWrQsGVjyMGlGi1bJGbNfmES/siOlzRGlnFwyEUVgMQZg3cb7Zo4D51J/f7NPKhknKxHCsUWcaV+DuEcRtbfMB2HffsNChPkHb3DLtB0B5vgke+H3FwF3pDfRHVT9upNpH3oaiIpiVIP
X-IronPort-AV: E=Sophos;i="5.84,234,1620684000"; d="scan'208";a="519607334"
Received: from max86-3_migr-88-124-91-211.fbx.proxad.net (HELO [192.168.1.52]) ([88.124.91.211]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 12 Jul 2021 20:05:28 +0200
From: Benjamin Lipp <benjamin.lipp@inria.fr>
To: cfrg@irtf.org, dharkins@lounge.org
References: <162567329247.15923.4311477568566128956@ietfa.amsl.com> <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org>
Message-ID: <0effccc3-a459-0330-d999-275c75e1cb1b@inria.fr>
Date: Mon, 12 Jul 2021 20:05:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MOMY2a3srTUpgW2F_76kySv5IKw>
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 18:05:46 -0000

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 […]

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


On 12/07/2021 18:39, 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
>