Re: [CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hpke-09: (with COMMENT)

Christopher Wood <caw@heapingbits.net> Tue, 29 June 2021 12:59 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 AC18A3A33BF; Tue, 29 Jun 2021 05:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=heapingbits.net header.b=nVy9PJXV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kOuUKNGi
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 dbSY3r-FmZIH; Tue, 29 Jun 2021 05:59:39 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6373A33A9; Tue, 29 Jun 2021 05:59:39 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id C947832000E5; Tue, 29 Jun 2021 08:59:33 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 29 Jun 2021 08:59:34 -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 :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=+K tqoZ+gN+RLRBU1LOpiBHz79PXyNx8k7G+wGj2Av4k=; b=nVy9PJXVqzm7uDLHA1 ImvQraRK6fjGYnCNFeZrYd77HQ9lYNJDa1EYMjZ9gUk6bdZPubY0VtQJoLzIJ1nz bua1eL/3t991Z/YfRWWifRoNKcOsJSoKFAA2ukOBcJFXytaYlI2mzvxJGWwYy8UZ Lfpsmy9OCxyBWzXF0carDZe0zCyUVdU7LEF/CiXVAp3/ND+HhTCJH2Vpx7qO5FJo h0v0VZN+6AyiVHodk4ZPOiCbeHr4tOp2ihj1UrcLzyXO5xCcTQewm6UU3xGf4fmi O1twi7LgLf6YbITZ3sLv72rMXa/xB2LHHxnVVajbuiWegv3mDvydDB4PEoryjqIp xRGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=+KtqoZ+gN+RLRBU1LOpiBHz79PXyNx8k7G+wGj2Av 4k=; b=kOuUKNGiEKQxkvki8LbZjmPca56UWTC89ciif40gG0+jJVyKLVVEn69U3 2YlY1jD9PeasJlkUs3wBOutDURVchKULJ5LKFeV9NLQ//AxvY1iAQPspixdy+E1v lnCFpCiOyvoZguVQSRYRP+VZE31YGVqoeIdRYjh5bTI6kNzF7E+6NK/rH0xH2oLb Omeq8h+QTsWQQE+ASBkEJowYjh27xynUyZKBV2PtLSfoaGNtorbkYkpTRoCcKVy/ YJlUpNEp+MDLAswDtoO4BYm/HGCDVuWoBCEbeFlV5UpUv321Jr4xrk218J8ilPkX YTPghCdm8jEwCBFJmEQuHBPueC+AA==
X-ME-Sender: <xms:NBnbYMWwJGZjDq-hapNDUjZVTTBGFYN_WTVm8KbxOn0bPPTLyUheDQ> <xme:NBnbYAleAogZEcrx0DUEqtJnMbYT_KO6bFZXm7kCbWTZtFt-k52Gwfjz36N6TYd5h ZKhAifugZchWcTXlRk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeitddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucggtffrrghtthgvrhhnpeffkefhudethfelleeuteelkedvfeehleefvdefieeg geejteevhfegffejffettdenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfh drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:NBnbYAZ4Kn8-K6hx4JdnDK4LUXDGc1qW8AIeRFiFwC0DHMTSAaWLFA> <xmx:NBnbYLXqVWspUX9M2orpp6JdGcjBkM4TpZREEzxJ0ZwB039HcUefmw> <xmx:NBnbYGlRk3U440b7GCTpLH321aGPeAgBqieMmWuygcgsotbWYxMZyQ> <xmx:NRnbYIjbN3XZSFmsEauoAHOP2yI7VL9Z4_Q8bGUMgmjiFajusAEGiQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E5A4F3C003D; Tue, 29 Jun 2021 08:59:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-Id: <e15afc2b-4a41-42ca-a564-1d1162dab128@www.fastmail.com>
In-Reply-To: <162403552387.29040.7069216010328580026@ietfa.amsl.com>
References: <162403552387.29040.7069216010328580026@ietfa.amsl.com>
Date: Tue, 29 Jun 2021 05:59:11 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>, "The IRSG" <irsg@irtf.org>
Cc: draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org, cfrg@ietf.org, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/kgRDzEndUllE02QxM3ufThZs57Y>
Subject: Re: [CFRG] =?utf-8?q?Spencer_Dawkins=27_No_Objection_on_draft-irtf-c?= =?utf-8?q?frg-hpke-09=3A_=28with_COMMENT=29?=
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: Tue, 29 Jun 2021 12:59:46 -0000

Thanks, Spencer! I wrote the following PR to address these comments:

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

Best,
Chris

On Fri, Jun 18, 2021, at 9:58 AM, Spencer Dawkins via Datatracker wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-irtf-cfrg-hpke-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This isn't even remotely a topic I'm smart about, but the document was clearly
> written, and I can imagine using it as an implementer. I do have some nits, so
> please Do The Right Thing.
> 
> At the bottom of Section 5, this sentence, "The procedures described in this
> session are laid out in a Python-like pseudocode", and that's the only
> occurence of "session" in the document. I don't know what "this session" is
> intended to refer to - I can guess, but I'd be guessing. Is it something like
> "in the following *sections*"?
> 
> In this text, "This assurance is based on the assumption that AuthDecap(enc,
> skR, pkS) produces the correct KEM shared secret only if the encapsulated value
> enc was produced by AuthEncap(pkR, skS), where skS is the private key
> corresponding to pkS", is "assumption" the right word? "Assumption" makes me
> look for some mention of evidence that would support that assumption, but
> reading further, I'm led to believe that this is a fundamental property, not an
> assumption.
> 
> In this text, "In many cases, applications encrypt only a single message to a
> recipient's public key", is "to the recipient's public key" the right way to
> say this? I was guessing this meant "In many cases, applications encrypt only a
> single message using a recipient's public key"
> 
> In this text, "The precise likelihood of DeriveKeyPair() failing with
> DeriveKeyPairError depends on the group being used, but it is negligibly small
> in all cases", is there any obvious action that an implementer could take if
> this DOES happen?
> 
> I wonder if Section 7.1.5. KEM Key Reuse should appear in the security
> considerations section, or perhaps even just be mentioned there, with a
> reference to its current location. Perhaps even in Section 9.2? But just having
> this appear in Section 7 without a mention in Section 9 seems counterintuitive.
> 
> Hmmm. Section 5.3 says this: “Applications that do not use the encryption API
> in Section 5.2 can use the export-only AEAD ID 0xFFFF when computing the key
> schedule. Such applications can avoid computing the key and base_nonce values
> in the key schedule, as they are not used by the Export interface described
> above”, but Section 7.3 says “The 0xFFFF AEAD ID is reserved for applications
> which only use the Export interface; see Section 5.3 for more details”. Would
> saying “Applications that do not use the encryption API in Section 5.2 can use
> the export-only AEAD ID 0xFFFF when computing the key schedule” in Section 7.3
> be accurate? If so, it would be more obvious that these two statements apply in
> the same conditions if they use the same phrasing.
> 
> I may be going blind (and that would be a pity, since I had cataract surgery
> earlier this year), but I can’t see the difference between what’s said about
> DHKEM in
> 
> Extract() and Expand() (in DHKEM): Extract() can be modeled as a random oracle.
> Expand() can be modeled as a pseudorandom function, wherein the first argument
> is the key.
> 
> and what’s said about “elsewhere” in
> 
> Extract() and Expand() (elsewhere): Extract() can be modeled as a random
> oracle. Expand() can be modeled as a pseudorandom function, wherein the first
> argument is the key.
> 
> Is there a difference? I see text in Section 9.5 that looks like it might be
> related, but I just don’t have the background to know for sure.
> 
> In 11.1. KEM Identifiers, “The "HPKE KEM Identifiers" registry lists
> identifiers for key encapsulation algorithms defined for use with HPKE. These
> are two-byte values, so the maximum possible value is 0xFFFF = 65535”, These
> “might” be clearer as “These identifiers” (same comment in 11.2 and 11.3).