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

Dan Harkins <> Mon, 09 August 2021 08:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EE203A095D for <>; Mon, 9 Aug 2021 01:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fr0v8eSi-hZy for <>; Mon, 9 Aug 2021 01:36:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C85053A095C for <>; Mon, 9 Aug 2021 01:36:08 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <> for; Mon, 09 Aug 2021 03:36:07 -0500 (CDT)
Received: from blockhead.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <> for; Mon, 09 Aug 2021 01:33:51 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by ([]) (PreciseMail V3.3); Mon, 09 Aug 2021 01:33:51 -0700
Date: Mon, 09 Aug 2021 01:36:05 -0700
From: Dan Harkins <>
In-reply-to: <>
To: Richard Barnes <>
Cc: Nick Sullivan <>, CFRG <>
Message-id: <>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8NE/TWE8XSJLbqYPIpD1wA)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO blockhead.local)
References: <> <> <> <>
X-PMAS-Software: PreciseMail V3.3 [210807] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [CFRG] Questions for the group from the HPKE presentation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Aug 2021 08:36:14 -0000

   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.


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 < 
> <>> 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
>>     <
>>     <>> wrote:
>>         Dear CFRG participants,
>>         At IETF 111, Dan Harkins made a presentation
>>         <>
>>         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
>> <>
>>         <>
>     -- 
>     "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