Re: [CFRG] DAE for HPKE, was Re: I-D Action: draft-irtf-cfrg-dnhpke-02.txt

[Christopher Wood <[e-mail]>]

> On Oct 2, 2023, at 12:27 PM, Dan Harkins <[e-mail]> wrote:
> 
>   But getting back to this procedural issue. One of the editors of
> HPKE (and I believe the person who did the security analysis), when it 
> was still an I-D, said that "the door is not closed" on using a DAE cipher 
> mode. And I expressed confusion given the new text that just appeared 
> in -10 of that I-D, so clarifying text was added to say that you get an
> IND-CCA2 guarantee when you abide by the requirements in 9.4. The 
> implication being, you can get a DAE mode assignment but then you 
> will not have the IND-CCA2 guarantee. That was impression that the 
> editors were giving when they accepted the pull request. Now, post
> publication, I am being told something quite different. 

I believe this is a misinterpretation of facts. If you look at the entire email, Benjamin writes:

"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?"
This again points to the need to update the requirement that IND-CCA2 security is required for all future AEADs, as specified in Section 9.4.

In any case, regardless of what “impression” was given on the list, what matters here is the requirement as written in RFC9180, and that requirement is quite clear. If you want to make forward progress, the correct course of action is to try and build consensus around safely relaxing this requirement in RFC9180, rather than trying to work around the requirement itself.

Best,
Chris

> 
>   regards,
> 
>   Dan.
> 
> [1]  https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf
> 
>> ---
>> Mike Ounsworth
>>  
>> From: CFRG <[e-mail]> <mailto:[e-mail]> On Behalf Of Salz, Rich
>> Sent: Monday, October 2, 2023 8:30 AM
>> To: Richard Barnes <[e-mail]> <mailto:[e-mail]>; Eric Rescorla <[e-mail]> <mailto:[e-mail]>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: [EXTERNAL] Re: [CFRG] DAE for HPKE, was Re: I-D Action: draft-irtf-cfrg-dnhpke-02.txt
>>  
>> My interpretation of the question here is: - HPKE has been proven IND-CCA2 secure if the KEM and AEAD are IND-CCA2 secure - RFC 9180 makes no claims about the security of the construction if the AEAD is *not* IND-CCA2 secure - The request here 
>> My interpretation of the question here is:
>> - HPKE has been proven IND-CCA2 secure if the KEM and AEAD are IND-CCA2 secure
>> - RFC 9180 makes no claims about the security of the construction if the AEAD is *not* IND-CCA2 secure
>> - The request here is to register an AEAD algorithm that is affirmatively *not* IND-CCA2 secure (can't be, not even claimed to be)
>>  
>> If this is an accurate summary, then I don’t see a reason for the experts to reject the algorithm.
>>  
>> So the question for the RG is -- Are folks OK with values being registered that do not meet the security requirements in the RFC?
>>  
>> Well, the RFC doesn’t have that requirement.  It says “if X then Y” not “only X is valid.” But I gave it a quick read, so if I’m wrong please point to the section where it says IND-CCA2 is required.
>>  
>> The TLS registries have learned that we need to have a notes column, and a recommended-or-not column. Perhaps an update that adds a Note column and the draft could cay “not IND-CCA2”. In fact, the IANA action to add that column could be part of this draft.
>>  
>>  
>> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. 
>> 
>> _______________________________________________
>> CFRG mailing list
>> [e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/cfrg