From nobody Mon Feb 15 12:33:28 2021 Return-Path: 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 ; 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 ; 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 ; Mon, 15 Feb 2021 12:33:23 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id b14so7601701qkk.0 for ; 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: <4FCD508B-0ECB-4F7B-B252-B92CDFBC5B8B@gmail.com> <1ded9ec0-4da1-981d-fedc-709ca301c166@lounge.org> <51802415-536e-3d8c-1c1f-b7ff00be533e@lounge.org> In-Reply-To: <51802415-536e-3d8c-1c1f-b7ff00be533e@lounge.org> From: Richard Barnes Date: Mon, 15 Feb 2021 15:33:07 -0500 Message-ID: To: Dan Harkins Cc: Karthikeyan Bhargavan , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="000000000000ab212c05bb65e5f2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 20:33:27 -0000 --000000000000ab212c05bb65e5f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 featu= re > 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 plac= es > 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 titl= e > 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 formall= y: > > 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 wrote: > >> >> Hi Karthik, >> >> On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote: >> > Hi Dan, >> > >> > I don=E2=80=99t 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.=E2=80=9D >> > The HPKE stateful API guarantees that nonces cannot be misused, even i= f >> 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 message= s >> 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 th= e >> 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