Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 18 December 2019 15:55 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 769C7120929 for <cfrg@ietfa.amsl.com>; Wed, 18 Dec 2019 07:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 m6d1zQa_NzaL for <cfrg@ietfa.amsl.com>; Wed, 18 Dec 2019 07:55:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B7612085D for <cfrg@irtf.org>; Wed, 18 Dec 2019 07:55:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2BA7BE39; Wed, 18 Dec 2019 15:54:57 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ihi6emH5cpi; Wed, 18 Dec 2019 15:54:55 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6825EBE2E; Wed, 18 Dec 2019 15:54:55 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1576684495; bh=uQ8/RQdDVK/RD0854K//n4cV549C5+ncwKgQ6fnF/0c=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Wl62e/h3Axl8LRCqJVnaWU+1EcLfLKSdCuLG+BJHiBh6dJTVIA+GBMsdfOwq2M2ec 0UDnpSQ9EsAcxlLOtG3jH+SM5n0vyNSccogR+ylSm2qQVKQcliGMLzUZxzxgz6tnpR ndjZFBmdoBDK+1HTO96CD87JbNeN0ZfyihRZQcbQ=
To: John Mattsson <john.mattsson@ericsson.com>, "rlb@ipv.sx" <rlb@ipv.sx>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
References: <F8BB57F1-4490-4FE4-B935-EF1D3C028D81@ericsson.com> <5689d764-d6b2-ddcb-6214-89b998f56f8e@cs.tcd.ie> <002F8F00-3B95-4CB7-A58A-83C611C35F1D@ericsson.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <9167be88-0e02-1903-d25f-705e0859a119@cs.tcd.ie>
Date: Wed, 18 Dec 2019 15:54:54 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <002F8F00-3B95-4CB7-A58A-83C611C35F1D@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="krUb91vYwdVxC7d2FHV626xLRTBdGHLmL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/91IqeFclw_dzjws0mzqhSCx3hYI>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02
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: Wed, 18 Dec 2019 15:55:07 -0000

Hiya,

On 18/12/2019 14:20, John Mattsson wrote:
> Hi,
> 
> Stephen Farrell wrote:
> 
>> "Urgh. Why do we always need to define every possible option even
>> though there's no real demand?
> 
> While TLS 1.2 definitely have too many cipher suites, I think some
> recent specifications like RFC 8032 have hardcoded too much. 

Disagree. RFC8032 lead to pointless debate in IETF WGs
about pure vs. hash. I think 8032 is another example of
providing too many options.

> Having
> an IANA registry with specification required  and some well-chosen
> initial values is a good approach.

Sure.

>> We (CFRG) could punt on this by using existing IETF IANA registries
>> instead of creating new ones.
> 
> I also like the idea to reuse IANA registries more. I made a similar
> comment regarding draft-ietf-emu-aka-pfs a month ago. There are for
> example many IANA registries for groups/curves. I really like the new
> TLS IANA registry with specification requires and a Recommended
> column that requires Standards Action.

I had a look and there are IANA registries that'd do just
what we need. (16 bit values, specification required, and
with existing experts in place).

Doing that however does mean that some folks will dislike
it, as the semantics for use of the same code-point in
different protocols could potentially differ.

E.g. for the current interesting KDFs we could use any registry of hash
functions as we only really care about
HKDF-<hash>. In principle, some new KDF might not be
HKDF-based, which is a teeny bit naff - HPKE would need
to say something like "For HKDF based KDFs, use values
from <this> IANA registry to specify KDF. If a non HKDF
KDF is needed in future, a new registry may be needed
that is guaranteed to not overlap with <this>." That
does require holding one's nose a bit but also does
work:-)

> 
>> result in the hpke RFC having only one MUST implement kem, kdf and
>> aead.
> 
> Does HPKE currently have any MUST implement kem, kdf and aead? And
> should it have? My picture of the future HPKE RFC is that is a
> framework where nothing is mandatory to implement and where the IETF
> protocol using HPKE defines a mode and algorithms that are
> mandatory-to-implement. A RECOMMENDED mode and set of algorithms
> would however be good, and maybe text stating that implementations
> are not expected to support them all.

I'd be fine with exactly one RECOMMENDED set of things to
implement or a MUST-implement. What I'd most like to avoid
is IETF WGs each debating which things to pick from HPKE.
As to MUST vs. RECOMMENDED, HPKE is a spec that could be
implemented as a standalone library (which is kinda what
I've done;-) and adopted by people outside the IETF so
having a MUST-implement seems like a good plan for this
one.

S.

> 
> Cheers, John
> 
> -----Original Message----- From: Cfrg <cfrg-bounces@irtf.org> on
> behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie> Date:
> Wednesday, 18 December 2019 at 14:40 To: John Mattsson
> <john.mattsson=40ericsson.com@dmarc.ietf.org>rg>, "rlb@ipv.sx"
> <rlb@ipv.sx> Cc: "cfrg@irtf.org" <cfrg@irtf.org> Subject: Re: [Cfrg]
> Review of draft-irtf-cfrg-hpke-02
> 
> 
> Hiya,
> 
> On 18/12/2019 13:24, John Mattsson wrote:
>> The PR looks good.
> 
> Assuming you mean [1]...
> 
> Since I didn't get a substantive response on the list, I'll repeat:
> 
> "Urgh. Why do we always need to define every possible option even
> though there's no real demand? There are already far too many
> combinations of modes and suites in hpke."
> 
> Having more or less finished my implementation now, I feel more
> strongly that additional combinatoric mess is a bad plan. Removing
> options/simplifying would be far better.
> 
> We (CFRG) could punt on this by using existing IETF IANA registries
> instead of creating new ones. There is an almost fine match between
> what we need and some existing registries (if one squints just a
> little;-) that'd remove all this wrangling from our plate and that
> could result in the hpke RFC having only one MUST implement kem, kdf
> and aead. Additional options could then be haggled over in the IETF
> each time someone claims a need before subsequently being ignored by 
> almost all implementers and an even higher proportion of
> deployments;-)
> 
> Cheers, S.
> 
> [1]
> https://protect2.fireeye.com/v1/url?k=2314e233-7f86ef6f-2314a2a8-0cc47ad93d46-945b5a8e9e504e6c&q=1&e=9ab353d6-767e-4b85-b0e9-ae1735c5d076&u=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-hpke%2Fpull%2F23%2F
>
> 
> 
>