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

Richard Barnes <> Mon, 09 August 2021 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB3A3A079E for <>; Mon, 9 Aug 2021 00:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cQoKcbVRUYPo for <>; Mon, 9 Aug 2021 00:56:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 270593A07A2 for <>; Mon, 9 Aug 2021 00:56:31 -0700 (PDT)
Received: by with SMTP id o13so17431330qkk.9 for <>; Mon, 09 Aug 2021 00:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=esV8yCUfCaAWSPyX6F78h0QxtWdZzh9PaVdERVHypp4=; b=ZU718jWhnHLYZjkvHXJxeNyRNFR6tbeLvtJbjAMoet7jx8uittrMKWJg9p9SpAfvpO JO4rqt6MtH9B0i4JGeYfus2OIDfl2m+eOG47LirT/WmUtzptcx9vMxu+XOBnG8zMqG9p qshpd8TQIXhqh7qgRyi1U5z7tFU2hjCdxECeUbwUx1/vWVZYdD9yqN5s1MFwZhLHJsoP qim5uvMeFh0pplxJpaBnwLWgPvrzJpmCI+EVP5iF33hA3fPfeqCI/u4qpiw7/IYQJ0vt hN8qJ3UpcFJytBVEbZ3csVHjRmF3D3EdZu67z2ximFlBVrJ3syi1G+VDklkf8Wl8tfyw O2kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=esV8yCUfCaAWSPyX6F78h0QxtWdZzh9PaVdERVHypp4=; b=SBpFhyvbMV2xyC21T1saVcItI53Vbe7hV9ms+wS7qn7GNTD/mA3J7LYrgrSehOBlZn 2tyIfctPHu8VYTCGVX/KXPFhn6vSPNbRt+jVxsbfsUlxd2smtLHpTQsvilfTCiJTeFc0 k5CjXhu/mknSCqdocQ/bm48ULJy1lV/NoVf7XhDT03AJpWuW4Vla5Q7nMR3a7p9DSpSF Pq+EzccN/2tfOBnmWmmd28pL0fqrpRrzVooSa0prIXT4CTGjqQKcKibi9dI2/5cYaPbD z7Tk/bi1BU2CCE9WzZufWd0M1UgL8pyZSll4RaPM1X0ID2HnoEcE3jcV4PZU4dfVNITN GxYw==
X-Gm-Message-State: AOAM5322U9lL4FdMY/6PnAWVCDrASHunTWYsxzImcR7hn0t06llPTKmY /mop9QQGNyO2Baj71IQWSox2D5XY92PXyuXdWX2v3w==
X-Google-Smtp-Source: ABdhPJzkxEfGywPnpsCpkObuzPiFHOtWO8pC/7OVpUEHqeBQdLR6aXi7/wvB9RJ9LuB8D55khp5nEtmNB69T0hPmDtM=
X-Received: by 2002:a05:620a:12f6:: with SMTP id f22mr2230784qkl.159.1628495788964; Mon, 09 Aug 2021 00:56:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Sun, 8 Aug 2021 21:56:17 -1000
Message-ID: <>
To: Dan Harkins <>
Cc: Nick Sullivan <>, CFRG <>
Content-Type: multipart/alternative; boundary="000000000000050c9705c91bb995"
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 07:56:38 -0000

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.


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