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

Benjamin Lipp <benjamin.lipp@inria.fr> Tue, 13 July 2021 10:59 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 E94F93A138E for <cfrg@ietfa.amsl.com>; Tue, 13 Jul 2021 03:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 VI7aF5f1zM3J for <cfrg@ietfa.amsl.com>; Tue, 13 Jul 2021 03:59:04 -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 281063A138C for <cfrg@irtf.org>; Tue, 13 Jul 2021 03:59:03 -0700 (PDT)
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AucJUV6ypOLcyg1F1r9B1KrPwFr1zdoMgy1kn?= =?us-ascii?q?xilNoHtuA66lfqGV7ZcmPHrP41wssR4b9OxoR5PwJ080maQY3WBpB8bHYOC+gh?= =?us-ascii?q?rOEGgB1+XfKkzbexEWn9Q1vZuIGJIeNDSfNzdHZM/BkXCF+9FM+qjjzJyV?=
X-IronPort-AV: E=Sophos;i="5.84,236,1620684000"; d="scan'208";a="519737953"
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; 13 Jul 2021 12:58:58 +0200
To: Dan Harkins <dharkins@lounge.org>
Cc: cfrg@irtf.org
References: <162567329247.15923.4311477568566128956@ietfa.amsl.com> <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org> <0e12f957-3472-84b9-e152-8372ae520535@lounge.org>
From: Benjamin Lipp <benjamin.lipp@inria.fr>
Message-ID: <5db11a21-a519-149b-3b14-6a7249e713d3@inria.fr>
Date: Tue, 13 Jul 2021 12:58:58 +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: <0e12f957-3472-84b9-e152-8372ae520535@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/V7rB7sg5zvjIXguKMtl2XZzxt1Q>
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: Tue, 13 Jul 2021 10:59:09 -0000

Hi Dan,

On 12/07/2021 23:53, Dan Harkins wrote:
>   I've been having trouble with my mailer and I see in the archives you
> responded
> 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.


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

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.


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

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.





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