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

Richard Barnes <rlb@ipv.sx> Mon, 09 August 2021 07:56 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3A3A079E for <cfrg@ietfa.amsl.com>; Mon, 9 Aug 2021 00:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQoKcbVRUYPo for <cfrg@ietfa.amsl.com>; Mon, 9 Aug 2021 00:56:31 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270593A07A2 for <cfrg@irtf.org>; Mon, 9 Aug 2021 00:56:31 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id o13so17431330qkk.9 for <cfrg@irtf.org>; Mon, 09 Aug 2021 00:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CAFDDyk8yZegN6aWSZg=K7Wy+V2upq=GBuvGyQYowrRuehPDqYQ@mail.gmail.com> <CAL02cgTc34pSUOYqFiCKkfcobtj8y5=LashfsDNdabQ6g6P=gQ@mail.gmail.com> <2c0986bc-07c0-ed32-97b6-722fca39253e@lounge.org>
In-Reply-To: <2c0986bc-07c0-ed32-97b6-722fca39253e@lounge.org>
From: Richard Barnes <rlb@ipv.sx>
Date: Sun, 8 Aug 2021 21:56:17 -1000
Message-ID: <CAL02cgSoi=fHi296DYb17DsDNMphNSOKxeWqzTuH5XyQeJSXhw@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: Nick Sullivan <nick=40cloudflare.com@dmarc.ietf.org>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000050c9705c91bb995"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/YaseLW4TeUHhx004RyTnXOKVwbY>
Subject: Re: [CFRG] Questions for the group from the HPKE presentation
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.

--RLB


On Fri, Aug 6, 2021 at 1:56 PM Dan Harkins <dharkins@lounge.org> 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=
> 40cloudflare.com@dmarc.ietf.org> 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
>> CFRG@irtf.org
>> 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
>
>