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

[Neil Madden <[e-mail]>]

> On 2 Oct 2023, at 13:53, Richard Barnes <[e-mail]> wrote:
> 
> 
> EKR - I think the point is less procedural / adversarial than you're thinking.  The point of this thread is more seeking feedback for the experts on how to interpret the text in RFC 9180.
> 
> 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)
> 
> So the question for the RG is -- Are folks OK with values being registered that do not meet the security requirements in the RFC?  Or does Specification Required truly mean that anything that is written down is OK?  Note that the expansive interpretation here would allow obviously insecure things, e.g., null ciphers or ROT13.  (Not saying this request is so obviously insecure, but it doesn't meet the RFC's security bar, and we should create a new, undocumented bar, so we're left with no bar.)
> 
> My personal analysis is that the expansive interpretation is risky, especially if we broaden the lens to CFRG more broadly.  In recent years, there has been a positive trend toward making crypto tools harder to misuse -- nonce-reuse-resistant AEAD, more rigid elliptic curves, etc.  In algorithm-agile schemes like HPKE, allowing algorithms that are not safe in context goes against this trend.  You wouldn't be able to have confidence your PKE is secure just because you're using HPKE with a registered algorithm, you would have to do a bunch of secondary research to verify that the algorithm is good.  This degrades the value of all the good vetting that CFRG does, because the consumer is left with uncertainty as to whether a given construction is safe.  My evaluation in this case is to avoid heading down this particular slippery slope.

I may be wrong, but my (admittedly mostly intuitive) understanding is that using a DAE scheme in this way would result in HPKE being IND-CCA2 secure, because the KEM ensures each message uses a fresh key. (ie is HPKE in fact IND-CCA2 if the symmetric scheme only provides *one-time ciphertext integrity* per Boneh/Shoup section 9.1.1 https://toc.cryptobook.us/book.pdf#page375 ?)

If so that would seem a safer relaxation of the requirement that rules out rot13 etc. 

— Neil