Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 January 2020 20:06 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE51200CD for <secdispatch@ietfa.amsl.com>; Fri, 17 Jan 2020 12:06:25 -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 J6Z-ujvX8UpT for <secdispatch@ietfa.amsl.com>; Fri, 17 Jan 2020 12:06:19 -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 DA76E1200A4 for <secdispatch@ietf.org>; Fri, 17 Jan 2020 12:06:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78D32BDCF; Fri, 17 Jan 2020 20:06:16 +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 HFbYvBKnRdRl; Fri, 17 Jan 2020 20:06:14 +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 739F1BE20; Fri, 17 Jan 2020 20:06:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579291574; bh=6//nUxCFstxHkPN26GC7ntzdPsRQXVr3cHvs48+VoPc=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=irwvNKn8sVwftvfcOzy4K1Uktn3OeU3KCZzAgHwCZuUfXk9UxoixBMqy7/d+o+Lyh UDe5W4zoxe+bWA76ykO5O+p/gMoxo1osDqxWoiUnaVYj0Ou4Ha5h4rym02/WAfBdfA mcn5o0rMJxZ4JGxtfTe5DwlAwoxnsfvWNwnXMLRc=
To: John Gray <John.Gray@entrustdatacard.com>, "Markku-Juhani O. Saarinen" <mjos@pqshield.com>, IETF SecDispatch <secdispatch@ietf.org>
Cc: Daniel Van Geest <Daniel.VanGeest@isara.com>, Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>
References: <DM6PR11MB388377406A1AAEDCA397749C9B360@DM6PR11MB3883.namprd11.prod.outlook.com> <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <c0f620d7-4e22-18a5-c168-f66b737cae86@cs.tcd.ie> <CAPwdP4PG3i5-_BuVMdH0iMcJCT40xejoM=J3dH=pPO61T-F4Aw@mail.gmail.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <BYAPR11MB3478E8F964A34EDD232CFB03EE310@BYAPR11MB3478.namprd11.prod.outlook.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: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie>
Date: Fri, 17 Jan 2020 20:06:13 +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: <BYAPR11MB3478E8F964A34EDD232CFB03EE310@BYAPR11MB3478.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1cAczJlPQIfn6r0kHf1gXMaVuJCHeV5Dn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/lj9s2kvoMhRdkKXxkyt0cUF16C4>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS?
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 20:06:26 -0000

Replying to a few mails at once, but ISTM this is starting
to get repetitive.

On 17/01/2020 18:15, John Gray wrote:
> Hi Stephen,
> 
> The reason why we are putting together this composite standard is 
> because we believe we are in this position today.   If NIST  decides 
> no Round 3 is needed, then we will know the PQ winners by June of 
> this year.   Even if there is a Round 3, and no final set of PQ 
> algorithms is declared until 2021 or 2022, we want to have a hybrid 
> standard ready for us use.  We will need to implement, test, and 
> interop and all these things take time and have to be done after 
> there is a standard.  If we wait too long, it will be a free for 
> all.

Right now there are too many algorithms to believe that
we'd have other than a free-for-all as those pushing one
or another try get their thing adopted. I'd also note
that NIST has a history or defining new parameterisations
after algorithm selection, so wouldn't be surprised if
that happened here too. I'd prefer we wait and see what
results from the NIST thing rather adopt work now in
the IETF. If people want to do work ahead of NIST then
that's of course fine, but adopting such work in the IETF
is asking us all to do work on this now, and I think that's
both risky and wasteful.

> 
> There are already a small handful of stable PQ algorithms available 
> to use today.   See RFC 8391 (XMSS) and RFC 8554 (LMS), so using a 
> hybrid RSA or EC with XMSS or LMS in a composite form is already 
> viable.  The choices are definitely few at this moment, but there
> are viable use-cases.

Stateful signature schemes such as those are not suited
for use in X.509 IMO, as was already raised on the list.
(And someone earlier claimed they wouldn't work for their
use-cases, so I'm confused as to whether the proponents
here do or don't want to include stateful signature
schemes.)

On 17/01/2020 17:54, Mike Ounsworth wrote:
> Cool. In the meantime, we plan to keep working on the outstanding 
> TODO decision points in the draft as more vendors approach us for 
> interop testing. :-)

I've no objection to people working on stuff. I am opposed
to the IETF prematurely adopting work in this space though.

On 17/01/2020 18:08, Carrick Bartle wrote:
> From what I've gathered from the mailing list discussion on this 
> topic (in particular, the lead time necessary for hardware), it 
> strikes me that there is sufficient reason for this work to advance.

My experience in the IETF is that ill-defined and less well
understood work takes longest. I think this matches that at
the moment. I'd suggest the proponents might be better
spending time on developing their work by implementing it
in open-source generic PKI libraries and applications so
that they can produce some non arm-waving evidence as to
what this does or doesn't break. (IMO, it'll turn out to
break a lot and change many lines of code, but who knows,
I may be wrong.)

On 17/01/2020 18:32, Valery Smyslov wrote:
> Given the usual IETF performance, a year is a term just to launch a 
> real work and realize where to go. So, I think we should start doing 
> it now to have plenty of time and not to be in a hurry later.

See above as to how to speed things up more effectively.
Additionally, the idea that waiting a year or so means
someone would have to "be in a hurry" seems questionable
to me.

Cheers,
S.