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