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

[Benjamin Lipp <[e-mail]>]

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
>