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

[Dan Harkins <[e-mail]>]

On 8/9/21 7:08 AM, Christopher Wood wrote:
> For what it's worth, I agree with Richard here. As I understand the situation, this is solvable by the application or wrapper protocol. TLS 1.3, for example, assumes the same sort of reliable, in-order delivery to keep per-record nonces in sync, and that seems to work just fine: https://datatracker.ietf.org/doc/html/rfc8446#section-5.3.
>
> To answer the questions from the original post:
>
> 1) No (as per above), but also because adding this type of API seems really unsafe for AEADs that cannot survive nonce reuse.

   But SIV *can* survive nonce reuse. It is the original misuse-resistant
AEAD mode. The existing AEAD modes cannot survive nonce reuse and they would
be unchanged in my proposal.

   Dan.

> 2) Registering new compressed point format KEMs seems fine -- that's why we have the registry! I don't think we should add DAE ciphersuites given how they impact the security posture of HPKE. This seems to have the effect of making different application decisions regarding the AEAD yield different security outcomes, which I would claim is a regression.
>
> Best,
> Chris
>
> On Mon, Aug 9, 2021, at 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]> 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
>> _______________________________________________
>> CFRG mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> 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