Re: [CFRG] Questions for the group from the HPKE presentation

[Richard Barnes <[e-mail]>]

W.r.t. (1), the obvious solution to me would be a reordering window outside
of the HPKE implementation.  Even if the HPKE implementation required
in-order delivery, the application payloads containing HPKE ciphertexts
could have a sequence number indicating the order in which they were
produced, and the receiving application could use this to ensure that they
were fed to the HPKE implementation in order.

--RLB


On Fri, Aug 6, 2021 at 1:56 PM Dan Harkins <[e-mail]> wrote:

>
> On 8/6/21 3:49 PM, Richard Barnes wrote:
>
> 1. I don't think this question is well-formed.  HPKE isn't an API, it is a
> construction.  In fact, the "API considerations" section of the HPKE spec
> is there precisely because there might be different APIs to an HPKE
> implementation.
>
>
>   It may not be perfectly formed but its obvious what is being asked. My
> answer
> to it is that once you find out that your contexts are out of sync it's
> too late.
> I think it's more important to just be able to deal with out-of-order and
> lost
> packets.
>
>   Yes, it's "a construction"...that hides a datum from the user and makes
> the
> construction fragile for some use cases. So I'd like to remove that
> fragility for
> those use cases. The easiest and least intrusive, to the construction, way
> is
> to just have Nn=0 for these new AEAD algorithms and not worry about the
> nonce.
>
>   One thing I failed to mention during my presentation is that even if the
> user adds a counter/nonce as AAD or a plaintext tweak (to hide whether the
> same
> thing is encrypted twice) and screws it up, the DAE security guarantees
> remain. SIV is the original misuse-resistant mode.
>
>   Instead "resetting the nonce counter" we could do something analogous
> to what
> IPsec does with a floating window that prevents replay but allows
> out-of-order
> delivery modulo some limit (really late packets will just get dropped).
> But that
> might require some changes to the API...err, the construction, so we'd be
> back
> to a reformed question #1.
>
> Given all that, I would be in favor of no action here.  There are several
> existing ways for an HPKE-based protocol to deal with out-of-order delivery.
>
>
>   You mean like using deterministic authenticated encryption? If not that,
> then what
> exactly are you referring to?
>
>
> 2. Personally, I don't have a use case for either of these.
>
>
>   Well, will you admit that while these might not be your use cases that
> they are
> legitimate nonetheless?
>
>   Serialization should have never used SEC uncompressed format. There's no
> valid
> reason to do that. I regret that I didn't bring this issue up until it was
> officially "too late". But that can be rectified pretty easily and no one
> will force
> you to use compact representation if you really don't want to.
>
>   Dan.
>
> On Fri, Aug 6, 2021 at 12:31 PM Nick Sullivan <nick=
> [e-mail]> wrote:
>
>> Dear CFRG participants,
>>
>> At IETF 111, Dan Harkins made a presentation
>> <https://datatracker.ietf.org/meeting/111/materials/slides-111-cfrg-new-kems-and-aeads-for-hpke-00>
>> with two proposals:
>> - a proposal to define new codepoints for HPKE representing new KEMs for
>> compressed NIST points
>> - a proposal to define new codepoints to support deterministic
>> authenticated encryption schemes that don't use a nonce. This is in service
>> of the use case of out-of-order delivery of ciphertexts. *In the
>> discussion, it was noted that HPKE uses a nonce to ensure that it never
>> leaks whether the same plaintext was encrypted twice and that this proposal
>> does not provide this security property.*
>>
>> Also during the discussion, an alternative proposal was made to solve the
>> out-of-order use case: modify the API for HPKE to enable the user to reset
>> the nonce counter. This API would enable out-of-order delivery of
>> ciphertexts with existing HPKE AEADs.
>>
>> The chairs would like to ask the group a few questions:
>> 1) Does the research group support adding an API to HPKE for resetting
>> the nonce counter?
>> 2) Is there interest in pursuing a work item to explore defining either
>> of the following:
>> - new codepoints for compressed curve points in HPKE?
>> - new codepoints for deterministic authenticated encryption in HPKE (given the
>> answer to (1) was no)?
>>
>>
>>
>> Regards,
>> Nick (for the chairs)
>> _______________________________________________
>> 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
>
>