Re: [CFRG] RGLC on draft-irtf-cfrg-dnhpke-03

I strongly agree with Chris's analysis here.

The KEMs are fine.  They've already been registered; we should publish them.

The new "AEAD"s are not acceptable.  The major security claim of RFC 9180
is that "[HPKE] is IND-CCA2-secure as long as the underlying KEM and AEAD
schemes are IND-CCA2-secure".  The DAE schemes in this draft are not
IND-CCA2-secure, so none of the security analysis that underlies RFC 9180
applies -- all bets are off.  So there are two problems with just plugging
DAE into HPKE:

1. This new construction would provide substantially different security
properties than HPKE
2. This draft does not provide supporting analysis for *any* security
properties

As Chris says, the former problem is reason enough to call a KEM+DAE
something other than "HPKE".  The latter problem means that even if one
were OK with the different security properties here, we should not publish
this document because CFRG should not be in the business of publishing
cryptographic constructions without any actual security analysis.

As a final note, I would just point out that the even document's putative
justification for DAE is false.  It is perfectly possible to use HPKE in
lossy networks.

--Richard

On Thu, Dec 7, 2023 at 5:27 PM Deirdre Connolly <durumcrustulum@gmail.com>
wrote:

> I agree.
>
> On Thu, Dec 7, 2023, 5:15 PM Christopher Wood <caw@heapingbits.net> wrote:
>
>> This has been discussed lots of times on the list before. The current
>> state of the document doesn’t help make this discussion easy. Basically,
>> there are two things at stake here:
>>
>> 1. The new KEMs, for which code points have already been allocated:
>> https://www.iana.org/assignments/hpke/hpke.xhtml
>> 2. The new AEADs, which is a point of debate. I won’t reiterate the
>> argument here and point to my prior issue with the document:
>> https://mailarchive.ietf.org/arch/msg/cfrg/mP7swra3Mfni5KoPg2NKFccWTOk/
>>
>> That said, I do not think this document should be published in its
>> current state. Changing the HPKE contract is no small thing, yet that’s
>> precisely what (2) does, and it does so in the absence of analysis which
>> says what the properties of HPKE with DAE (that is, not an IND-CCA2-secure
>> AEAD) are. The responsible thing to do is to put (2) into a separate
>> document, for a separate construction that is NOT HPKE, but something
>> different.
>>
>> Best,
>> Chris
>>
>> On Nov 16, 2023, at 9:42 AM, Alexey Melnikov <alexey.melnikov@isode.com>
>> wrote:
>>
>> Dear CFRG participants,
>>
>> This message is starting 3 weeks RGLC on draft-irtf-cfrg-dnhpke-03
>> ("Deterministic Nonce-less Hybrid Public Key Encryption"), that will end on
>> December 7th 2023. If you've read the document and think that it is ready
>> (or not ready) for publication as an RFC, please send a message in reply to
>> this email or directly to CFRG chairs (cfrg-chairs@ietf.org). If you
>> have detailed comments, these would also be very helpful at this point.
>>
>> Thank you,
>> Alexey, for CFRG chairs
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://mailman.irtf.org/mailman/listinfo/cfrg
>>
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://mailman.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
>