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

Christopher Wood <caw@heapingbits.net> Mon, 09 August 2021 14:08 UTC

Return-Path: <caw@heapingbits.net>
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 C77473A13F2 for <cfrg@ietfa.amsl.com>; Mon, 9 Aug 2021 07:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=oszXOgjL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BH5Uovoo
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 z4tF-6qTwsFh for <cfrg@ietfa.amsl.com>; Mon, 9 Aug 2021 07:08:39 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87D23A13E3 for <cfrg@irtf.org>; Mon, 9 Aug 2021 07:08:38 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BDECB5C0050 for <cfrg@irtf.org>; Mon, 9 Aug 2021 10:08:37 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 09 Aug 2021 10:08:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=//VqMbf7xMtPPESlN64MRx4RCAqCbrA cvFhJK+UDsH0=; b=oszXOgjLGBmpkMf1UhGrP80zascS2rDeX/qYGmf9Jp4XI/f 6IcEywKjUJBAhaq7QHrQ/pyLLbJbzOQ0nhAX9iXtr7rX3z6kSoLKW39DDrLtSPG+ 1A9rjrNWjlGyLpalYpk4aIMjNSeB1yNyvY6YbcDPJKSMb5yskQqZOkeAxSWG568v 72UKhjSGadT0BBgxhItzkGT3pB06cdbWW7HfVexrwMxNNsqRGC2uh+Cy/WXnttok sTllQMl7o/Hken38d/UudbkNDZYxxxz4URwJp7tNI+cW27JmPP8g7lpA8Ju90NlH 07QJhYgj/R8/rh8IsCHR00JYXzQwaKVPDAmWHqg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=//VqMb f7xMtPPESlN64MRx4RCAqCbrAcvFhJK+UDsH0=; b=BH5Uovoo65kXZsO8szCTUl XfNeUDY+mJ+R5OtpQW1v7dmF04eYWLLaJ+ECM8+R/9GlBTr4lNliH0qvHaJyUHjM fZeTejsX1y8/d1BRgLWM6W+lfhthQluIZ3ah/B0akDAq+KgsNq+fpAFu6pv1HQzW 1tQ2atzp5nTdSGRcH6x79p5n4zmLSgeVIkM/0inNzVJQe9Sd/2aYMP7a9qY5m2k/ gBlDEJWeZUuDKZw10MgiKAV0NzPB0OX1uqL3/VKt65riIWNhjX2Kt0eW43K/OHnD cwPNmPzTKvgc6HQxWD7oe/DoEx/YHbtiO1gLZIIgK8Ct1qTpTiwM0OesPCszitQw ==
X-ME-Sender: <xms:5TYRYdm29w_CyyPl8A96mXHo-3NmSPtXcTmRcSctdwWTmnD3wvM6HA> <xme:5TYRYY3swWDEqgfD7MZhi7wZEpln_RA-7D9dA7bc6h00cNF1W_U9TOB4bZXcjWGd3 i_fU2K_DJqWx2dhKJA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeejgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepvdfgtdfhudelte dufeegffffgfeltdffvddtvdffkeffkeffffekgfelgeefhfegnecuffhomhgrihhnpehi vghtfhdrohhrghdpihhrthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:5TYRYTq-dLxCowUN3C54hZ6a-lChjf00qdqWqiHhVtAzziMkFYgtrw> <xmx:5TYRYdmG-A7n6ezOvYIf0V0htr5vQTsgTVIS4CT5IxSF0QUOVjLlBQ> <xmx:5TYRYb0kSGNNiy4YZnHERrgx7Ex9njPLDRyeeWE8jMyCQ-O5Xk278A> <xmx:5TYRYcDDLKqNVwt962-_2aHqGqNFbu6bmD7yoSyciHIJP0ZZeSIndQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 112053C0449; Mon, 9 Aug 2021 10:08:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-552-g2afffd2709-fm-20210805.001-g2afffd27
Mime-Version: 1.0
Message-Id: <a582bedb-35ce-41ba-ba9b-2dd1c074b248@www.fastmail.com>
In-Reply-To: <CAL02cgSoi=fHi296DYb17DsDNMphNSOKxeWqzTuH5XyQeJSXhw@mail.gmail.com>
References: <CAFDDyk8yZegN6aWSZg=K7Wy+V2upq=GBuvGyQYowrRuehPDqYQ@mail.gmail.com> <CAL02cgTc34pSUOYqFiCKkfcobtj8y5=LashfsDNdabQ6g6P=gQ@mail.gmail.com> <2c0986bc-07c0-ed32-97b6-722fca39253e@lounge.org> <CAL02cgSoi=fHi296DYb17DsDNMphNSOKxeWqzTuH5XyQeJSXhw@mail.gmail.com>
Date: Mon, 09 Aug 2021 07:08:15 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: cfrg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/tlnRLIdTV-wImogEr404IUpzj00>
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 14:08:45 -0000

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.
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 <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 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>