Re: [Secdispatch] Can Composite sigs move back to LAMPS?
Daniel Van Geest <Daniel.VanGeest@isara.com> Thu, 16 January 2020 21:37 UTC
Return-Path: <Daniel.VanGeest@isara.com>
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 280C1120090 for <secdispatch@ietfa.amsl.com>; Thu, 16 Jan 2020 13:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0GFce2d7_rQ7 for <secdispatch@ietfa.amsl.com>; Thu, 16 Jan 2020 13:37:53 -0800 (PST)
Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFEA12008A for <secdispatch@ietf.org>; Thu, 16 Jan 2020 13:37:53 -0800 (PST)
IronPort-SDR: yp1YqYPju1LqG8Sv8le/Oj92da/6CoLglVrzJqdy5KphtOQPQhwEW1gwlcZ+EKSNmIL56b8SHp +Zyll5eBcWxDLneHdqrMULAijnGFh+NZEWlMGDeKxgsojo25e5qQl/DVjEXY+XzF2bnR+VD1UA hDV+0tqDDEjNoSOt5TmWJsV9KUNRykfT8t1kd7DVAkbF8nAQxem7AH5kEerXsnl4DXw6S+7VBF 9fOczWdAmWPZoNBe9yrhn/PiWMnuVx0kZbOVlTiqEQuxRk7Ph77USJkmQlHRTADfZluNu0FODM 9HM=
Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip2.isaracorp.com with ESMTP; 16 Jan 2020 21:37:50 +0000
Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Thu, 16 Jan 2020 16:38:26 -0500
Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1847.005; Thu, 16 Jan 2020 16:38:26 -0500
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>, IETF SecDispatch <secdispatch@ietf.org>
Thread-Topic: [External]Re: [Secdispatch] Can Composite sigs move back to LAMPS?
Thread-Index: AdXMlh5Ba3U4rdZGTG6zfD9kbyUHDgANtcoAAASJP4A=
Date: Thu, 16 Jan 2020 21:38:26 +0000
Message-ID: <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com>
References: <DM6PR11MB388377406A1AAEDCA397749C9B360@DM6PR11MB3883.namprd11.prod.outlook.com> <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie>
In-Reply-To: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.5.52]
Content-Type: multipart/alternative; boundary="_000_09B0CA53BAAF413981792A70ADE58632isaracom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/BNDrVyGQxWY0er-1g5xGSPDPREI>
Subject: Re: [Secdispatch] 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: Thu, 16 Jan 2020 21:37:55 -0000
Hi Stephen, On 2020-01-16, 7:28 PM, "Secdispatch on behalf of Stephen Farrell" <secdispatch-bounces@ietf.org<mailto:secdispatch-bounces@ietf.org> on behalf of stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote: Hiya, I'm guessing it'll be no surprise that I reckon that we ought not adopt either piece of work at this time (sorry for being so predictablel;-) I continue to think waiting 'till we know more is wiser. [DVG] I think we can appreciate your consistency at least :-) I'd also note that CVE-2020-0601 may (when full details emerge) provide very direct evidence that standardising cryptographic parameter representations ahead of real understanding of the algorithms and their implementations and real uses can be a bad plan with implications that only hit decades later. [DVG] I think you’ve hinted (or stated explicitly) at this before, but it confuses me. draft-ounsworth-pq-composite-sigs does not attempt to standardize the parameter representations of any cryptographic algorithms. It’s just a framework for combining other standardized representations. In the PQ case those are to be standardized separately in the future. This draft could just as well be used to combine RSA and elliptic curve signatures. I don’t want to put words in Max Pala’s mouth, but he’s currently dealing with a newborn so I will provisionally say I think combining classical algorithms using this method is of interest to him. Probably the draft should be renamed to draft-ounsworth-composite-signatures, similarly to what was done in IPSecME for a draft combining key agreement algorithms. There’s nothing PQ-specific about either mechanism, but the efforts are being made now in anticipation of these algorithms arrivals, knowing how long the standardization process can take. Thanks, Daniel Van Geest On 16/01/2020 19:13, Mike Ounsworth wrote: Following up on in-room discussions at 106, and the ensuing list discussions, I'd like to ask for confirmation of the following points: 1. There is enough interest in an obvious-and-straightforward implementation of composite signatures to continue working on it? 1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02 2. SecDispatch is assigning this back to LAMPS? 2a. The current draft might not be the most obvious-and-straightforward implementation; we're willing to simplify until it's in-scope for LAMPS. --- Mike Ounsworth Software Security Architect, Entrust Datacard _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org<mailto:Secdispatch@ietf.org> https://www.ietf.org/mailman/listinfo/secdispatch
- [Secdispatch] Can Composite sigs move back to LAM… Mike Ounsworth
- Re: [Secdispatch] Can Composite sigs move back to… Stephen Farrell
- Re: [Secdispatch] Can Composite sigs move back to… Markku-Juhani O. Saarinen
- Re: [Secdispatch] Can Composite sigs move back to… Daniel Van Geest
- Re: [Secdispatch] Can Composite sigs move back to… Stephen Farrell
- Re: [Secdispatch] Can Composite sigs move back to… Markku-Juhani O. Saarinen
- Re: [Secdispatch] Can Composite sigs move back to… Stephen Farrell
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Mike Ounsworth
- Re: [Secdispatch] Can Composite sigs move back to… Carrick Bartle
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… John Gray
- Re: [Secdispatch] Can Composite sigs move back to… Valery Smyslov
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Stephen Farrell
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Mike Ounsworth
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Stephen Farrell
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Markku-Juhani O. Saarinen
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Michael Richardson
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Eric Rescorla
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Michael Richardson
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Eric Rescorla
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Michael Richardson
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Markku-Juhani O. Saarinen
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Eric Rescorla
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Markku-Juhani O. Saarinen
- Re: [Secdispatch] [EXTERNAL]Re: Can Composite sig… Benjamin Kaduk