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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 01 December 2019 19:56 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 2033F120103 for <cfrg@ietfa.amsl.com>; Sun, 1 Dec 2019 11:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.965
X-Spam-Level:
X-Spam-Status: No, score=-0.965 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, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 EySkBlOgCr0P for <cfrg@ietfa.amsl.com>; Sun, 1 Dec 2019 11:56:51 -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 59EB2120059 for <cfrg@irtf.org>; Sun, 1 Dec 2019 11:56:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3354BE24; Sun, 1 Dec 2019 19:56:47 +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 Q_Qi3eM-Iypx; Sun, 1 Dec 2019 19:56:45 +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 65A4FBDCF; Sun, 1 Dec 2019 19:56:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1575230205; bh=/LOfDmij18lz7VLgM8LPk98KHdUOSucSpVuSKe0QUuI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GgvVPEgqxhfFLU7VSUZQ4D/Aa0pZet4NLdmaFLYWSGzqM2Yw0U2DwSRSf3Wq0lqxI sHhD1rxKc0+ZLJ/Znb/qT1Sb2i5sasaYBuBlg7xXATY2ZYQUdO52NMvLXj7qq+Y6qi L0HWTYelVH0jwbcE3kQ6R55XNLabWHGwv6f1y+cU=
To: Richard Barnes <rlb@ipv.sx>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
References: <F881AD3B-6D69-46F7-BB96-0AADD3E10CA6@ericsson.com> <CAL02cgRyibL=G-b2caRfBhazRrYfbVcbCwbi=-Y8q4WDbdMkGQ@mail.gmail.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: <c04d1999-bdf6-777e-ec4a-04b683b4043a@cs.tcd.ie>
Date: Sun, 1 Dec 2019 19:56:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <CAL02cgRyibL=G-b2caRfBhazRrYfbVcbCwbi=-Y8q4WDbdMkGQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rYHzoWC3TCB4tLs1zsxiw8NdsWkGmI30Y"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4FDsuIFCpr2tux-jfqdi_ZLMtuc>
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: Sun, 01 Dec 2019 19:56:54 -0000

Hiya,

On 27/11/2019 19:46, Richard Barnes wrote:
> Hi John,
> 
> Thanks for the comments.  I've reflected them in this PR:
> 
> https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/23

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.

I'd suggest instead to aim to *remove* options from
the draft. Those that are really needed can be added
later via IANA code point allocations. If you keep all
the myriad options you have now then every IETF WG
will have to spend effort debating which to use and
pointless differences will emerge that may damage
interop.

In case it helps, I've started coding up hpke [1] but
fwiw do not plan to implement every single combination
of everything. I currently have one mode and one suite.
If ESNI/ECHO requires something else, then I'll probably
do that and call it done.

But what might help even more is to not have any new
code points at all but to find a way to re-use TLS
ciphersuite codepoints. I think that could save us
all a lot of bother and make-work related to HPKE.
(And we'd benefit from the "recommended" column in the
TLS registries.)

Cheers,
S.

[1] https://github.com/sftcd/happykey

> 
> Couple of responses inline.
> 
> On Sat, Nov 23, 2019 at 3:22 AM John Mattsson <john.mattsson=
> 40ericsson.com@dmarc.ietf.org> wrote:
> 
>> This is a well-written and useful draft.
>>
>> - ”This scheme provides authenticated public key encryption”
>>
>>    Should mention the unauthenticated mode as well.
>>
> 
> The challenge here is that we have two meanings of "authenticated".  Every
> mode is "authenticated" in the sense of "authenticated encryption".  Some
> modes also authenticate some information about the sender.  I'm inclined to
> leave this as-is, since I don't see an easy way to reword more clearly.
> 
> 
> 
>> - I think it might be useful to add a sentence on ECIES and PSEC in the
>> introduction to help so people searching for “ECIES” will find the draft.
>>
>> - “Encrypted messages convey a single ciphertext and authentication tag
>> alongside a short public key”
>>
>>    This made me think the tag was sent a separate field. I suggest
>> changing it to a sentence saying that the ciphertext includes an
>> authentication tag (but some AEAD would not even have a clearly defined tag
>> such as wide PRP ones like XCB.)
>>
>>    Also, the sentence does not seem to cover the mode that encrypts
>> several plaintexts with the same ephemeral key. I assume the initiator can
>> send several ciphertect with the encapsulation ot ciphertexts without the
>> encapsulation like in the following sequence:
>>
>>    -> enc, ct1, ct2
>>    -> ct3
>>
> 
> Reworded this whole paragraph to be clearer.
> 
> 
>>
>> - “mode_auth”, “mode_psk”, “mode_psk_auth”
>>
>>    The term “auth” is not optimal as psk also provides authentication.
>> Maybe it could it be changes to something related to asymmetric,
>> public-key, or KEM.
>>
> 
> I agree it's suboptimal, but given that this change would touch a lot of
> stuff, I'm inclined to leave it unless there's a
> 
> 
>> - I am missing a Security considerations. I think there are several things
>> that could be mentioned:
>>
>>   -- How does an application supporting several algorithms protect against
>> downgrade?
>>
>>   -- Should the receiver do replay protection?
>>
>>   -- Shortly mention that the construction in the draft protects against
>> attack on earlier ECIES standards such as the Benign malleability and the
>> XOR malleability.
>>
> 
> Sorry, I'm not familiar with these notions.  Maybe you could propose some
> text?
> 
> 
>>   -- Stating that the protocol does not provide PFS and give some
>> consideration on when that would be ok instead of setting up a TLS
>> connection.
>>
>>   -- privacy considerations
>>
> 
> We discuss some privacy considerations in the "Metadata Protection"
> section. Did you have others in mind?
> 
> 
> 
>> - “For the NIST curves P-256 and P-521, the Marshal function of the DH
>>    scheme produces the normal (non-compressed) representation of the
>>    public key, according to [SECG].”
>>
>>    Why suddenly referring to SECG?
>>
> 
> I understood that was the normal reference for point formats.  Do you have
> another preference?
> 
> 
> 
>> - Single-Shot APIs
>>
>>    Should mention that this is stateless.
>>
>> - The document has very detailed descriptions of the parts KEM, KDF, AEAD,
>> but I miss a short overview section describing which fields the initiator
>> is supposed to send to the receiver and what the initiator and receiver
>> need to agree on out of band. Are any information like pskID and sequence
>> number supposed to be sent on the wire?
>>
>> - I would like to see P-384 and SHA-384. The US CNSA suite, TLS, and 3GPP
>> are all using these together with AES-256. I would also like to see KMAC.
>>
> 
> I added P-384 and HKDF-SHA-384.  It's not immediately clear how KMAC maps
> in here, given the shape the document assumes for KDFs.  It would be
> trivial to do HKDF-SHA3, but my guess is that you want something
> different.
> 
> 
> 
>>
>> Cheers,
>> John
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>