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

   For some reason Richard's email didn't appear in my mailer, but
it is in the CFRG archive so I was able to read it....

On 10/2/23 6:40 AM, Mike Ounsworth wrote:
>
> > 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.
>
> I’m with Richard that the label “Not IND-CCA2” includes both otherwise 
> perfectly acceptable DAE ciphers, and also ROT13, and so is not a 
> helpful label in terms of guiding non-cryptographer sysadmins and 
> policymakers.
>
> If we think that the deterministic nonce-less AEADs in draft-irtf-cfrg-dnhpkeare ok-ish, then we need a better label than “Not IND-CCA2”.
>
>

   AES-SIV has a security proof (see [1]) so the option shouldn't be to
lump it in with ROT13. I'm sure we could come up with a reasonable
name for a column in the registry that addresses what the mode offers
if that's what the RG wants to do.

   But Richard says that a people wouldn't have confidence that using
HPKE with one of these modes is "safe". The requirement that the
construction with this mode is "safe" should be in the document that
registers the mode, not the IANA registry. And I think my I-D does
that. People don't implement the IANA registry, they implement the RFC,
and they would be able to read the Security Considerations about using
what it is they are implementing.

   The unfortunate downside to this interpretation of the assignment
rules is that HPKE cannot be used in an application on a lossy network.
The world is not TCP and HPKE could be useful in applications that
cannot guarantee in order delivery of every single packet. Preventing
that is A Bad Thing (tm) in my opinion.

   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.

   regards,

   Dan.

[1] https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf

> ---
>
> *Mike*Ounsworth
>
> *From:*CFRG <cfrg-bounces@irtf.org> *On Behalf Of *Salz, Rich
> *Sent:* Monday, October 2, 2023 8:30 AM
> *To:* Richard Barnes <rlb@ipv.sx>; Eric Rescorla <ekr@rtfm.com>
> *Cc:* cfrg@irtf.org
> *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
> 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