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

[Christopher Wood <[e-mail]>]

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, [e-mail] 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
> >>> [e-mail]
> >>> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>