IETF Logo Mail Archive

Re: [Curdle] call for adoption for draft-mu-curdle-ssh-xmss-00

Daniel Van Geest <Daniel.VanGeest@isara.com> Fri, 22 November 2019 02:44 UTC

Return-Path: <Daniel.VanGeest@isara.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30AC120836 for <curdle@ietfa.amsl.com>; Thu, 21 Nov 2019 18:44:13 -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 rMftdEaWGz1o for <curdle@ietfa.amsl.com>; Thu, 21 Nov 2019 18:44:12 -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 F1ABC12012A for <curdle@ietf.org>; Thu, 21 Nov 2019 18:44:11 -0800 (PST)
IronPort-SDR: CWPgYkSVv2lH9isGULoime6R5Ls+ZSUhrEoq+E2X481CBzyRTD9nOveCZVYnIhn8INKLBNPJV3 TR1WDSJ6mXzHLupqu96bK8/e4bZudMiK7+CdWhbxMvNZR6sO73IMvm6LgkFculekHOoYKNV5sl wMLExCEWT7y0lHWhlAdZCm/uiP9PpiRM53uTKHtVv89xWhpTycZ10e5nG40NC0dJOICXRGm6rQ P/bGoLXNdEjX2/00eybOurGAA0hb802s6dy+VVAguaaA5caboww34dfV8vwsd7lKLncC8Dmkt4 AxY=
Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip2.isaracorp.com with ESMTP; 22 Nov 2019 02:44:11 +0000
Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1779.2; Thu, 21 Nov 2019 21:44:50 -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.1779.002; Thu, 21 Nov 2019 21:44:50 -0500
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: "Salz, Rich" <rsalz@akamai.com>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, denis bider <denisbider.ietf@gmail.com>
CC: curdle <curdle@ietf.org>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Thread-Topic: [External]Re: [Curdle] call for adoption for draft-mu-curdle-ssh-xmss-00
Thread-Index: AQHVoN7PWePopCOyl02nz+6D8T/G8g==
Date: Fri, 22 Nov 2019 02:44:50 +0000
Message-ID: <6F37DBC7-172E-44B4-A7E8-C7432BEA3225@isara.com>
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_6F37DBC7172E44B4A7E8C7432BEA3225isaracom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/jPaufH5fTkgxhzVdOc-GV5X5d94>
Subject: Re: [Curdle] call for adoption for draft-mu-curdle-ssh-xmss-00
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 02:44:14 -0000

NIST will issue a special publication on stateful hash-based signatures before the rest of the PQ process completes.  Based on today’s date I’d hazard a guess that the publication will be next year.

XMSS/HSS is better suited for roots of trust and code signing (and possibly a few other limited cases, the NIST publication may give guidance here) where the environment where the signature is generated is tightly controlled.  I’d possibly support its use for limited end-entity certificates (the only semi-reasonable one I can think of is an EE cert with a private key in an HSM which is used to sign a TLS delegated credential of a different PQ or classical algorithm).

The general SSH use case does not fit any tightly-controlled scenario like above, so I oppose adoption of this draft.

Daniel

On 2019-11-21, 4:39 PM, "Curdle on behalf of Salz, Rich" <curdle-bounces@ietf.org<mailto:curdle-bounces@ietf.org> on behalf of rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:

Speaking as an individual, I am opposed to adoption of this draft.

The IETF has pretty much decided to wait until the NIST post-quantum crypto process is finished.


Ø  SSH is rife with short, ad-hoc sessions in practical usage; as well as long sessions that can last many days.

Yes, and  for this reason, and because NIST explicit said that this will be part of the PQ process, adoption is premature. The NIST link mentioned (https://csrc.nist.gov/Projects/Stateful-Hash-Based-Signatures) explicitly talks about the problems and concerns of managing the state.

                /r$

v2.23.0 | Report a Bug | By Email