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

Christopher Wood <> Tue, 29 June 2021 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC18A3A33BF; Tue, 29 Jun 2021 05:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
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: (amavisd-new); dkim=pass (2048-bit key) header.b=nVy9PJXV; dkim=pass (2048-bit key) header.b=kOuUKNGi
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dbSY3r-FmZIH; Tue, 29 Jun 2021 05:59:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F6373A33A9; Tue, 29 Jun 2021 05:59:39 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C947832000E5; Tue, 29 Jun 2021 08:59:33 -0400 (EDT)
Received: from imap41 ([]) by compute5.internal (MEProxy); Tue, 29 Jun 2021 08:59:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Tue, 29 Jun 2021 05:59:11 -0700
From: Christopher Wood <>
To: Spencer Dawkins at IETF <>, The IRSG <>
Cc:,,, "Stanislav V. Smyshlyaev" <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hpke-09: (with COMMENT)
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: Tue, 29 Jun 2021 12:59:46 -0000

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


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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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).