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

[Richard Barnes <[e-mail]>]

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.

Nonetheless, if there's consensus in the RG on this point, we experts might
reconsider our evaluation.  Not looking for an adjudication / overrule,
just advice.

--Richard

On Sun, Oct 1, 2023 at 6:56 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Sun, Oct 1, 2023 at 3:46 PM Dan Harkins <[e-mail]> wrote:
>
>>
>>   Hi Eric,
>>
>> On 10/1/23 2:15 PM, Eric Rescorla wrote:
>>
>> On Fri, Sep 29, 2023 at 12:02 PM Dan Harkins <[e-mail]> wrote:
>>
>>>
>>>    Hello,
>>>
>>>    First of all, there's a new version of draft-irtf-cfrg-dnhpke out.
>>> Please take a look.
>>>
>>>    At IETF 116 I was told I could get IANA assigned values without
>>> the draft becoming an RFC so I applied. I got KEM assignments for
>>> compressed output but the experts are refusing to approve assignment
>>> for DAE support because it's not IND-CCA2.
>>>
>>>    So let me digress briefly....
>>>
>>>    In [1], I noted that this requirement that "all AEADs must be
>>> IND-CCA2 secure" appeared in -10 of the HPKE I-D without any real
>>> discussion (it wasn't in -09 and there was no discussion on the
>>> list) and that I was concerned that they were closing the door on
>>> my proposal. But I was told in [2] by an author of HPKE, and the
>>> guy who did the security analysis, that the door wasn't closed and
>>> that adding new DAE ciphers which were not IND-CCA2 did not affect
>>> the existing ciphers which were. There was even a pull request for
>>> HPKE to clarify (see [3]) which I was under the impression allowed
>>> for addition of new ciphers which were not IND-CCA2 since they were
>>> not diluting existing security guarantees.
>>>
>>>    But now I'm being told by the experts that there is an absolute
>>> prohibition on using HPKE with a cipher which is not IND-CCA2. I
>>> believe that is incorrect and certainly that was not part of the
>>> RGLC approval of the HPKE I-D.
>>>
>>>    I would like to hear what other people think and would like the
>>> experts to be overruled and to approve assignment of the DAE ciphers
>>> defined in draft-irtf-cfrg-dnhpke-02.
>>>
>>
>> Without taking a position on the merits of this issue, it's not clear to
>> me that CFRG can in fact overrule the experts. Here is what RFC 8126 says
>> about appeals of registration decisions (
>> https://datatracker.ietf.org/doc/html/rfc8126#section-10):
>>
>>    Appeals of protocol parameter registration decisions can be made
>>    using the normal IETF appeals process as described in [RFC2026],
>>    Section 6.5 <https://datatracker.ietf.org/doc/html/rfc2026#section-6.5>.  That is, an initial appeal should be directed to the
>>    IESG, followed (if necessary) by an appeal to the IAB.
>>
>>
>> That does seem a bit odd for a registry created by an IRTF document, but nevertheless, I think the process would require you to take it to the IESG.
>>
>>
>>   My point is that the experts are wrong in their interpretation of what
>> RFC 9180
>> says. There was discussion on the list about forbidding determinstic AE
>> cipher
>> modes and one of the editors (who I believe is also the guy who did the
>> security
>> analysis) said they weren't prohibited. The editors even agreed to a pull
>> request
>> to clarify this. It was certainly presented as "door not closed" when
>> discussed in
>> RGLC, yet when RFC 9180 comes out the experts say "door is closed". So I
>> believe they are enforcing a rule that the RG was told was not there
>> prior to
>> publication. If the RG agrees then I do not think this prohibition exists
>> and
>> the experts are mistaken in their reading of the RFC.
>>
>
> Hi Dan,
>
> I understand the point you're making, though, as I said, I haven't really
> formed
> an opinion about the merits of your argument.
>
> My only point here is that I don't believe there is any process by which
> the
> RG tells the Experts that they are reading the document wrong, other than
> to publish an RFC (e.g., further clarifying, or perhaps just registering
> the
> code point. So, even if everyone in the RG other than the experts were to
> disagree with the experts, that would just be advisory and not binding.
>
> To be clear, I think this is a bug in 8126 and there needs to be some
> IRTF-specific text, but presumably that's not going to happen today.
>
> -Ekr
>
>
>
>>   I do appreciate you pointing out the appeals process though. It may
>> come
>> to that.
>>
>>   regards,
>>
>>   Dan.
>>
>> -Ekr
>>
>>
>>
>>>    thanks and regards,
>>>
>>>    Dan.
>>>
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/cfrg/dAhw4TluqDfzKvtatqXvXbW0GVY/
>>> [2]
>>> https://mailarchive.ietf.org/arch/msg/cfrg/MOMY2a3srTUpgW2F_76kySv5IKw/
>>> [3] https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/233
>>>
>>> On 9/28/23 11:41 AM, [e-mail] wrote:
>>> > Internet-Draft draft-irtf-cfrg-dnhpke-02.txt is now available. It is a
>>> work
>>> > item of the Crypto Forum (CFRG) RG of the IRTF.
>>> >
>>> >     Title:   Deterministic Nonce-less Hybrid Public Key Encryption
>>> >     Author:  Dan Harkins
>>> >     Name:    draft-irtf-cfrg-dnhpke-02.txt
>>> >     Pages:   38
>>> >     Dates:   2023-09-28
>>> >
>>> > Abstract:
>>> >
>>> >     This document describes enhancements to the Hybrid Public Key
>>> >     Encryption standard published by CFRG.  These include use of
>>> "compact
>>> >     representation" of relevant public keys, support for key-wrapping,
>>> >     and two ways to address the use of HPKE on lossy networks: a
>>> >     determinstic, nonce-less AEAD scheme, and use of a rolling sequence
>>> >     number with existing AEAD schemes.
>>> >
>>> > The IETF datatracker status page for this Internet-Draft is:
>>> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-dnhpke/
>>> >
>>> > There is also an HTMLized version available at:
>>> > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-dnhpke-02
>>> >
>>> > A diff from the previous version is available at:
>>> > https://author-tools.ietf.org/iddiff?url2=draft-irtf-cfrg-dnhpke-02
>>> >
>>> > Internet-Drafts are also available by rsync at:
>>> > rsync.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
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>