Re: [Cfrg] review of draft-irtf-cfrg-hpke-05

Christopher Wood <caw@heapingbits.net> Sat, 15 August 2020 14:01 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 DACF13A0EC3 for <cfrg@ietfa.amsl.com>; Sat, 15 Aug 2020 07:01: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=3MNJEwJX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CaW0cMBo
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 H-lK2PIrf-Zv for <cfrg@ietfa.amsl.com>; Sat, 15 Aug 2020 07:01:43 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C433A0EBE for <cfrg@irtf.org>; Sat, 15 Aug 2020 07:01:43 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A81835C00BA for <cfrg@irtf.org>; Sat, 15 Aug 2020 10:01:42 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Sat, 15 Aug 2020 10:01:42 -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=v58dMY3b4+rPpoWWqrfeT6zk+il4Dod G1zLel3XA4vw=; b=3MNJEwJXBRBARhMzXyp0amKVWeGw8jDwkIPzxrm+BooVbKF /0I6ZNYEptnbBbfB4R0Cfpz5efk4gxIsAMq6btALfqxqtLnrSnI9GvhvC1wq7jG5 ludno1wXbhGN4ua2CWC0gh5pKkt5RtDA0qwh3oJPUYhMQwTdc4SQxip7gNDkIMlT MwDxrEvSnDJGHo+KvMmj76lrBRLdN3ANUloRXo60UY0tQD5kvrfhdVn0GhTB+b7B qMo2jPD9SUqnatPevr4Oh0bHNVQjZtip5I8x862UTzkt15RDwfLOyRuGj1IYI+cO wTvin0PASJI0vGEZza+SE29t0xd9TRuwGHBR/lA==
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=v58dMY 3b4+rPpoWWqrfeT6zk+il4DodG1zLel3XA4vw=; b=CaW0cMBo6RC8Jftf6nRqxe emEyM9JQUOc+xExaew1h7E7sVLFfpuE7rAEv3ZTj/gLSRKFqhKzGogIrxqgnXKNI aG9nptf7STEXHlSd1aJNaQW5NhLll6eP2VDhqc+euliU+MuXcs3W/nvz1nMK+Rf3 GJB42rzDTx33Z1SAUNhujluiu2q4Y2NXXvdju1jBBDa9ZUgDj5SZ2o1a7MlFKhD5 QZiYER21gWJmAe9KskoeY1T/SDCwGZv8PDOF0EDkeTBTQGeYUA54NgEExsM9sye4 O1TIKKKRphmDlk4FcPQt70MO0QHIMtkHR9AB2ZXCYxTXOcvh7GevqjBzYexPhbSw ==
X-ME-Sender: <xms:xuo3X7d2YzE2daqAXYrz9poEWnUte-oPlxwM7kNklU5OIUQblm4Jeg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleelgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepveekgedtgfdtje fhteeifeejhfdtgfdufedufeeljeeuvdejtdfhvefgvefgvedtnecuffhomhgrihhnpehg ihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:xuo3XxMSrM65TOp0cQCDtRvoXBUnCQtfMWtVcU-Yzcr0FfQLF6cwyw> <xmx:xuo3X0gcZbKRwVpDFqcg2G96viCkdjAfmZeyIrR4fv_wip9rwPjnFA> <xmx:xuo3X88muZPtYRZXAhN2pnvsb88I3uRzNqdvnE-zABZrklKuJQGYxg> <xmx:xuo3X4MPc3QjnG9XcxehLL6NUyG1J0tBfAlvJuNO7MIGnsFiLtSydg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 52F253C00A1; Sat, 15 Aug 2020 10:01:42 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-185-g038a4a3-fm-20200813.001-g038a4a3b
Mime-Version: 1.0
Message-Id: <4675a341-c465-4ee3-8215-3b2317a9d132@www.fastmail.com>
In-Reply-To: <4025d64f-9d7d-5474-b3ce-d2829d3a0df1@cs.tcd.ie>
References: <4025d64f-9d7d-5474-b3ce-d2829d3a0df1@cs.tcd.ie>
Date: Sat, 15 Aug 2020 07:00:59 -0700
From: Christopher Wood <caw@heapingbits.net>
To: cfrg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/AI7pv8HIi0izwyQvxvkRFG-9qfY>
Subject: Re: [Cfrg] review of draft-irtf-cfrg-hpke-05
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: Sat, 15 Aug 2020 14:01:45 -0000

Thanks for the feedback, Stephen! Please see inline below.

On Mon, Aug 10, 2020, at 10:22 AM, Stephen Farrell wrote:
> 
> I implemented draft -02 and will be doing -05 shortly.  I
> didn't yet do that so haven't verified the test vectors.
> Will follow up if any issues arise.

Excellent. Suggestions for improving the test vector format are also welcome, should you find it problematic when testing. 

> The thing to ponder relates to the IANA considerations.
> Why not add a "recommended" column a la TLS.  The RG can
> hand over responsibility to some DEs appointed by the IESG
> and call for the same setup as TLS.  (I.e. other than
> the initial values recommended == yes requires IETF
> standards track, otherwise spec required.) If we don't
> do that then applications using HPKE will always each
> need to say which suites are MUSTs, leading to IMO mostly
> pointless variation and possibly worsening interop if
> libraries implement disjoint sets of suites.

Interesting suggestion. I filed this issue to track it:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/145

> Minor comments:
> 
> - Is random() needed? it only seems to be used in the
> context of "DeriveKeyPair(random(Nsk))"

It's just a utility function, so it seems appropriate to define along with the others.

> - Do we really need to s/HPKE-05/RFCXXXX/ later? Why not
> just change to "HPKE-first-rfc" once the RG are done with
> the document? (There can be delays @ IRSG and subsequently
> that I'd prefer not have to affect interop.)

This was done to ensure each draft version (going forward) is incompatible. We probably should have done this from the start.

> - p7 & elsewhere: refers to "HPKE-05 " - that space seems
> like a bad idea.  I missed it until I got to p27.  And
> it's not consistently present and the text is ambiguous as
> to whether the replacement ought be "RFCXXXX"
> or "RFCXXXX "

Hmm, the replacement text says, 'replace "HPKE-05" with "RFCXXXX"', which should yield the correct result when piped through sed. That said, the extra space probably isn't needed. We can remove it:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/143

> - It strikes me as odd to not have any identifier for the
> public key being used but to have one for the PSK being
> used. If allowing the application to handle that for
> public keys works, why won't that work for PSKs?

Well, the identifier for the public key is typically the public key. This doesn't work for PSKs.

> - DeriveKeyPair() for NIST curves requires the HPKE code
> to know the order of the various NIST curves. That seems
> like the kind of thing where bugs might arise that
> wouldn't be noticed much. I also don't think many crypto
> APIs would provide a ``get_order_as_integer(curve_id)``
> function, so using the wrong value would seem not
> unlikely. I'd say maybe add the values to use here
> somewhere for each curve. If not in 7.1.2 then put in a
> forward reference. Perhaps also say what can happen if the
> wrong value for "order" is used.

That's a good suggestion. We can just list the orders for each of these curves:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/141

> - p29: I'm not sure why section 8.8 is useful here. I think
> it'd be better deleted TBH - it might muddy the definition
> of "signature" for some people and doesn't seem to add much
> as-is.

That's reasonable. I filed an issue to discuss removing it:

   https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/142

> nits:

<snip>

I filed this issue to track the nits:

  https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/144

Thanks again!

Best,
Chris