Re: [CFRG] Fixing the multi-shot API of HPKE

Richard Barnes <rlb@ipv.sx> Mon, 15 February 2021 20:33 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 3FF993A1109 for <cfrg@ietfa.amsl.com>; Mon, 15 Feb 2021 12:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[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=ham 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 0TaAD_8-8gvE for <cfrg@ietfa.amsl.com>; Mon, 15 Feb 2021 12:33:24 -0800 (PST)
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 2AACF3A1108 for <cfrg@irtf.org>; Mon, 15 Feb 2021 12:33:23 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id b14so7601701qkk.0 for <cfrg@irtf.org>; Mon, 15 Feb 2021 12:33:23 -0800 (PST)
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=E1XV6TXcLhudNShOhBKpjZ5mtk8oWP+5US3t2/FCMf8=; b=tVqQ1KddMwFIgBSt4f+FrJFqUaUZy41U1p1yUT6iniahHZ7OLisbSW344BKDf/IIU4 65O0SfBWxgYdHggn6e8a+klu4Yv0t0x93l8l0mpwiDZjoWa35dN+X5uhm6ILimV2gb/+ UYFSX0J3XjqebYp/RBBqVWe1ezixY/8TJX/nCVADyS+xdysUyqEFDZeYPWtaMd6bpDGl daUvEoODKFyL3DUWfGH8iUhsuYhwqJKaHEv8SSiaNz9X2HaOldgLW8usYKVDQUmpA/cj /UI+2QtYLkD/YP9SBWXudip6W7I/tKAI630+YCrIF9qZOzhcwbc/FlPVzwMECzYgDWD2 wMOQ==
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=E1XV6TXcLhudNShOhBKpjZ5mtk8oWP+5US3t2/FCMf8=; b=GLQ30sOk5fkTG4UOqnspIF04hoIEL3hfhgauOmn9YjF2V3R9E0+IjH+fS+JsmThg0l whfyaXdoSUQO8FpB6q2GCCxaT9DzuQ3ieILm3cl84OY9GlFhEsk8Hr0MuBqJAFRbI0+0 jwufBZnH6qlClUpoExksamDMBVrj79bC0TAn78dK4tVnMtpwTtxhxQjqYBD6CVL8Lvqv AVcKmwvQO7tkvU0EZU7GiN8Xi/FcHgYhGl4afCgcEEhdBSrtEXZETha4eEvRvVHHl/hb /b9ZEHZrFibr5zBK1vr6pgziQC1pleOpdioDBcWzwlIVQXIncJ7O9G26ZQ1EnGDhtWZ7 OkuQ==
X-Gm-Message-State: AOAM530kVVUWn7lomgzkTfIJA6lRW1V/unpuWmxBtIHpXozmfk9S9qWz 4vMjbEAEyUWn3LYHeR8/He9679Upyf1X5FbUWtPfZg==
X-Google-Smtp-Source: ABdhPJxDn2VUYmdKS+qtnTez5GFfR11eYHXo4ksJKQ8Ed9DuA5RZ7zkCZ0rG5YblHwLZzErseszf36eWP7iflBdheFg=
X-Received: by 2002:a37:4b52:: with SMTP id y79mr16482661qka.132.1613421202834; Mon, 15 Feb 2021 12:33:22 -0800 (PST)
MIME-Version: 1.0
References: <c089c88b-c5f6-f228-31a3-fb4e97a436c8@lounge.org> <4FCD508B-0ECB-4F7B-B252-B92CDFBC5B8B@gmail.com> <1ded9ec0-4da1-981d-fedc-709ca301c166@lounge.org> <CAL02cgQCnb3BhOp1Qmsi1tN2j1Tx3p5_QCta=eBKvtH9hzApFg@mail.gmail.com> <51802415-536e-3d8c-1c1f-b7ff00be533e@lounge.org>
In-Reply-To: <51802415-536e-3d8c-1c1f-b7ff00be533e@lounge.org>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 15 Feb 2021 15:33:07 -0500
Message-ID: <CAL02cgT3BA65dP9o+stB9PGvv-hRGU=_k-vhsWnuwMFU1LDpAg@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000ab212c05bb65e5f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/3f9gAvSYBl4IWD6KOGEdqdAO6r4>
Subject: Re: [CFRG] Fixing the multi-shot API of HPKE
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, 15 Feb 2021 20:33:27 -0000

Hi Dan,

Thanks for the suggested text.  I adapted it into the document in this PR:

https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/209

Cheers,
--Richard

On Mon, Feb 15, 2021 at 1:33 PM Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hi Richard,
>
> On 2/15/21 8:31 AM, Richard Barnes wrote:
>
> Hi Dan,
>
> HPKE is not intended to be a full network protocol; it is supposed to be
> embedded in an application that assures properties such as those you
> mention.  Section 8.6, "External Requirements / Non-Goals" [1] has some
> text on this.  If you think we can be clearer in these disclaimers,
> suggested text / PRs would be welcome.
>
>
>   Right, it's designed to be a fairly low-level primitive. Section 8.6 is
> describing the non-goals of HPKE. It's basically, "if you want this feature
> you need to handle this on your own", which is perfectly understandable. No
> need to be clearer there.
>
>   But this is the other way around. This is an expectation that HPKE places
> on any high-level protocol that might want to use it. It might be nice to
> have a (sub-)section formally devoted to this instead of burying the
> requirement in a discussion of how the sequence number is managed inside of
> an opaque HPKE context where its importance could easily be missed.
>
>   Actually since this is an external requirement, you could make the title
> of
> 8.6 just be "External Requirements", make the current content of 8.6 be a
> sub-section 8.6.1 entitled "Non-Goals" and then make an 8.6.2 entitled
> "Requirements on Upper-Layer Protocol" that says this requirement formally:
>
>     A high-level protocol that uses HPKE's stateful API MUST provide
>     for guaranteed in-order delivery of packets to ensure that all
>     ciphertexts are presented to ContextR.Open() in the order in which
>     they were generated by ContextS.Seal().
>
>     A high-level protocol MUST be able to detect packet loss and to
>     abandon any HPKE state that becomes unsynchronized as a result of
>     unrecoverable packet loss. Any packet number a high-level protocol
>     assigns to an HPKE message SHOULD be (part of) the AAD passed to
>     ContextS.Seal() and ContextR.Open() and it is the responsibility of
>     the high-level protocol to specify how that is accomplished.
>
>     A high-level protocol SHOULD provide a means of re-establishing
>     synchronized state in the event that contexts get hopelessly out
>     of sync. If this feature is provided it MUST NOT open the protocol
>     up to any additional attack-- that is, the only way an attacker can
>     induce parties to resynchronize is by dropping packets or otherwise
>     denying service.
>
> Something along those lines but in your voice.
>
>   But I still maintain that adding AES-SIV is the way to go :-)
>
>   regards,
>
>   Dan.
>
> --Richard
>
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-07#section-8.6
>
>
> On Sat, Feb 13, 2021 at 7:29 AM Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>>    Hi Karthik,
>>
>> On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote:
>> > Hi Dan,
>> >
>> > I don’t fully understand the problem you are alluding to.
>> >
>> >>     "It is up to the application to ensure that encryptions and
>> >>      decryptions are done in the proper sequence, so that encryption
>> >>      and decryption nonces align.”
>> > The HPKE stateful API guarantees that nonces cannot be misused, even if
>> you use AES-GCM or Chacha-Poly. (Of course, you could also add a SIV
>> ciphersuite.)
>> > Furthermore, it guarantees that the stream of plaintext messages
>> received by the decryptor is a prefix of the stream of plaintext messages
>> sent by the encryptor.
>>
>>    It's not an issue of misuse, it's an issue of the sender and
>> receiver contexts getting out of sync through entirely normal
>> network behavior and becoming unusable.
>>
>> > In the current design, if two ciphertexts are decrypted out-of-order,
>> both decryptions will fail.
>> > So the problem alluded to in the text above is one of functionality;
>> the application has to ensure (using some meta-data) that it is calling
>> decrypt in the right order.
>> > The application usually has to do something like this anyway to put the
>> plaintext stream together.
>> >
>> > I do not see how using AES-GCM-SIV is going to solve the above issue;
>> yes, it would allow you to decrypt the plaintext in any order, but  the
>> HPKE receiver would not be able to authenticate the correct order.
>> > Am I missing something?
>>
>>    AES-GCM-SIV requires a nonce (although reuse is not tragic in the
>> way it is for GCM) so there still needs to be some guarantee that the
>> nonce plugged into the receiver is the same as the one plugged into
>> the sender when the ciphertext was created. This is a proposal for
>> AES-SIV (defined by Rogaway and Shrimpton) which can do deterministic
>> AEAD (it can also be passed a nonce to be more like a traditional AEAD
>> mode, albeit slower, but that's not what I'm proposing here). No nonce
>> so nothing to worry about getting out of order.
>>
>>    Regarding the correct order, for a streaming application yes that's
>> true. The correct order would still be needed and whatever technique
>> you use to ensure that decrypted packets get ordered correctly could
>> probably be used to ensure that packets are decrypted in order. But
>> there are other interesting applications of HPKE that are not streaming
>> and each message can be thought of as self-contained. Imagine a sensor
>> obtaining some environmental data and then sending it off to a server
>> for correlation and processing every <time slice>. It would be quite
>> easy for such a sensor and server to get their HPKE contexts out of
>> sync and that would be a real PITA.
>>
>>    regards,
>>
>>    Dan.
>>
>> > -Karthik
>> >
>> >
>> >
>> >> On 13 Feb 2021, at 00:29, Dan Harkins <dharkins@lounge.org> wrote:
>> >>
>> >>
>> >>    Hello again,
>> >>
>> >>    The HPKE spec defines a single shot API for doing things like
>> key-wrapping.
>> >> You pass in the recipient's public key and some plaintext and get back
>> a
>> >> ciphertext. And that's it. One and done.
>> >>
>> >>    There is also (what I'll call for lack of a better word) a
>> multi-shot API.
>> >> The idea here is that there's a single asymmetric crypto operation
>> involving
>> >> the recipient's pubic key to derive some state that resides in an
>> opaque HPKE
>> >> context and then multiple calls to encrypt distinct plaintexts. The
>> state
>> >> created includes a base nonce and a sequence number (initialized to
>> zero).
>> >> Each call to another encryption (decryption) increments the sequence
>> number
>> >> which is xor'd with the base nonce and passed to the AEAD algorithm.
>> The HPKE
>> >> APIs take a plaintext, and AAD, and produce a ciphertext, and vice
>> versa.
>> >>
>> >>    This multi-shot API is fine if your world is Guaranteed In Order
>> Delivery
>> >> of Packets but that's not the world we all live in. As such, it'll only
>> >> be a matter of time before the sender and receiver are out of sync. The
>> >> HPKE draft alludes to this problem this way:
>> >>
>> >>
>> >>
>> >> Well that's a pain! One of the nice things about HPKE is that one
>> doesn't
>> >> need to worry about the nitty gritty of crypto state management
>> anymore,
>> >> it's all hidden. The API is nice and clean-- pass in a plaintext and
>> get a
>> >> ciphertext, pass in a ciphertext and get a plaintext.
>> >>
>> >>    If there was an AEAD mode that did not require a nonce it could be
>> used
>> >> in HPKE's multi-shot API without need for the application to manage
>> state
>> >> and guarantee the parties stay in sync. Thankfully there is such an
>> AEAD
>> >> mode: AES-SIV (RFC 5297).
>> >>
>> >>    When I brought this up earlier (and also on github) in the context
>> of
>> >> misuse resistance the response was, there's an export-only API that
>> will
>> >> give you a secret and you can go do any AEAD mode you feel like,
>> including
>> >> AES-SIV, issue closed.
>> >>
>> >>    While that is technically true, it applies equally to the AEAD
>> functions
>> >> that HPKE already defines-- you can export a secret and do AES-GCM-256
>> >> outside of HPKE while managing the necessary state yourself. Yet HPKE
>> >> defines AEAD functions whose state resides in an opaque context so
>> there
>> >> is obviously value in having that functionality. I just want to get
>> that
>> >> value-- a clean, multi-shot API where I don't need to worry about
>> managing
>> >> state or guaranteeing people remain in sync-- for people who don't live
>> >> in the world of Guaranteed In Order Delivery of Packets.
>> >>
>> >>    So I'd like to ask the group whether they see value in having a
>> nonce-less
>> >> AEAD mode in HPKE. If so I'll be happy to resurrect the text changes I
>> >> proposed and will be happy to contribute test vectors from my HPKE
>> >> implementation which already does AES-SIV.
>> >>
>> >>    One issue is that there are different security properties for a
>> >> deterministic authenticated encryption scheme than for a probabilistic
>> >> scheme. This is discussed in [1] and the security considerations would
>> >> have to mention this. But I don't see that as a formidable problem.
>> >>
>> >>    regards,
>> >>
>> >>    Dan.
>> >>
>> >> [1] Rogaway and Shrimpton, "Deterministic Authenticated Encryption",
>> >>      EUROCRYPT, 2006
>> >>
>> >> --
>> >> "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
>>
>> --
>> "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
>>
>
> --
> "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
>
>