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

[Dan Harkins <[e-mail]>]

   But that won't work because even if an implementation is able to
use a reordering window, the existing HPKE "construction" uses a
nonce inside of the HPKE context that is unknowable to the user who
is managing the reordering window. A reordering window is only
useful when misorder is not tragic, and that is not the case with
the current HPKE specification.

   Any change to use a reordering window would require a change to
the API/construction such that it doesn't use an opaque sequence
number/nonce. And that is exactly what I'm proposing.

   Dan.

On 8/9/21 12:56 AM, Richard Barnes wrote:
> 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] 
> <mailto:[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
>     somethinganalogous 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]
>>     <mailto:[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
>>         thatHPKE 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] <mailto:[e-mail]>
>>         https://www.irtf.org/mailman/listinfo/cfrg
>>         <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
>

-- 
"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