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

Christopher Wood <caw@heapingbits.net> Tue, 13 July 2021 16:44 UTC

Return-Path: <caw@heapingbits.net>
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 B660D3A0924 for <cfrg@ietfa.amsl.com>; Tue, 13 Jul 2021 09:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ZJTfOy4v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=runUrYO7
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 7C4AZcrwO5cf for <cfrg@ietfa.amsl.com>; Tue, 13 Jul 2021 09:44:02 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918173A091C for <cfrg@irtf.org>; Tue, 13 Jul 2021 09:44:02 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7D90D5C0110 for <cfrg@irtf.org>; Tue, 13 Jul 2021 12:44:01 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 13 Jul 2021 12:44:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=G6NwP P1Efrk2uN/a3N4hY2S/qfN2lo+KWqsDdE3H04U=; b=ZJTfOy4vquRJ9Gr61ys3m y19LXFdma6lqOsEInSHkbHya1Z69XHtUBlWq+vMsmF2FYkrQ7D0ejYgLGBdIQqvL fLRsgZQ3y12odhLl3+Cn1LhAZU2EYvdKiPRavaXFr8mbR2qUHBUNE00sqtC0LbA2 DQIfocLWSHLMLKnNv9O1nOqQq2mgsYMlOH9s/XkCkG9gmQAPIjvyZgcfiUwXDGGf O5fabvDBE+Y9Xmf1r6njMBgCUaG6zGe8Hc5Ms6GfAZCBT12IUwEDvh+Ym4QRL8R4 ZlraZ34yi4lJdL+bdjQTOL2Z17HH8EH+WS6jNzjzSG7s/ULYQbxm5zrKY5rq4RWy w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=G6NwPP1Efrk2uN/a3N4hY2S/qfN2lo+KWqsDdE3H0 4U=; b=runUrYO7zcQFp/FAmH3ZdUwp3HgQbE/xxYmTdUVEbG3ulTEMVHORDKbnV 31+EtHI5Fi6jXrLgKoYy2qFW3B8IEosItY/miksmbeHi2nLk/U7HIxK0e5x++9vg U6urKrTj7kCdN9otkKM/3MIpRj2GZ9uApz5BB8tdCyp1G9JeqlPIZpfcT0GEaogQ pfmhM4zs2hMpoHZEcw+1YXdgi8tIoZbhKnS3faA0TGGbm9KCaCW8jgir3fuWJ2m/ HSmZJWHKFATgfk08jdkm9HtY4RjpaRDaNRWs6DJ4czWjvsYIXP6rClfLfJi1FUnI N6WrKp8/3NCBMaencMEN1dOMnx61Q==
X-ME-Sender: <xms:0cLtYIrUvuVsbTjPszRrZ25uvdWw1xedxD-mqQitteQjNByjhRmZog> <xme:0cLtYOqWYigYeQisc5W3d5till419V6mREIWEQ5lmnyLqCMERypTrmhgW4LyQ4yRZ 7vrynXNgFNzngtKsWo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeeltdeludejgf ellefhhfdvgfejfefghfefgffffeeuheekueeuffeiffeijeeutdenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghdpihhrthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhn ghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:0cLtYNPVqMgP4eJSwhiLDJhhzRZoruvSmjDNlTUahud0MupFgqLgmg> <xmx:0cLtYP4IZn1lve10RRH7DraTTs5HD1rBVjY8ijnBtdV4DjHpLboCyQ> <xmx:0cLtYH7M8dp_F7GrVyPakXMSNmEa-uRpXJ__CHgarUFRMQcsfwvVqw> <xmx:0cLtYJGG3R3vT3DZy2KkbLPVbY8AZedc9N7cybMldqVvlYGau2SnyA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 03D053C0B04; Tue, 13 Jul 2021 12:44:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: <c6f748d5-8e24-4272-a9bf-974b2ab09668@www.fastmail.com>
In-Reply-To: <5db11a21-a519-149b-3b14-6a7249e713d3@inria.fr>
References: <162567329247.15923.4311477568566128956@ietfa.amsl.com> <856d159d-1b7e-ee22-a1da-32b78704da54@lounge.org> <0e12f957-3472-84b9-e152-8372ae520535@lounge.org> <5db11a21-a519-149b-3b14-6a7249e713d3@inria.fr>
Date: Tue, 13 Jul 2021 09:43:40 -0700
From: Christopher Wood <caw@heapingbits.net>
To: cfrg@irtf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/2_7JxZryukMn-Ri_76HBRDVuX0o>
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 16:44:09 -0000

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

On Tue, Jul 13, 2021, at 3:58 AM, Benjamin Lipp wrote:
> 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
> > 
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>