Re: [Curdle] call for adoption for draft-mu-curdle-ssh-xmss-00
Simo Sorce <simo@redhat.com> Fri, 22 November 2019 19:04 UTC
Return-Path: <simo@redhat.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 DA028120926 for <curdle@ietfa.amsl.com>; Fri, 22 Nov 2019 11:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 QGF_IRUvcJ3W for <curdle@ietfa.amsl.com>; Fri, 22 Nov 2019 11:04:07 -0800 (PST)
Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCED1208EE for <curdle@ietf.org>; Fri, 22 Nov 2019 11:04:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574449445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J7Wljtab8vbhdZeJXwWmHUOdr6GjGslyUpVl0b/gKS0=; b=F2HLTOaBgEk9PoauIi1njZ2o09hf0+KqOFXruGA7rgarbLlXeDAbPZ4fFVfp7VK80hnWWz Tj5ViKPa7Zz1+JH14Q9tEoG7O/q7naUolE1K+gX1vmSIG7htMU4Bb9vvGMYXgSORYDwali d4mXJ2SF9sbPqVhbBEBvqBOh0TEMTWU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-10-BGc9BbWOMP66NizhT98L-Q-1; Fri, 22 Nov 2019 14:04:01 -0500
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 12A558018A1; Fri, 22 Nov 2019 19:04:00 +0000 (UTC)
Received: from ovpn-116-139.phx2.redhat.com (ovpn-116-139.phx2.redhat.com [10.3.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2E9C25DA32; Fri, 22 Nov 2019 19:03:58 +0000 (UTC)
Message-ID: <2de53edd5bdba6147d922963f4f8d859bd016bb9.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>, Daniel Van Geest <Daniel.VanGeest@isara.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, curdle <curdle@ietf.org>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, denis bider <denisbider.ietf@gmail.com>
Date: Fri, 22 Nov 2019 14:03:57 -0500
In-Reply-To: <CACsn0cnozhq1-cvQr_ojb8v79+6E4xi04gnV33aUAN-8tWWCzw@mail.gmail.com>
References: <6F37DBC7-172E-44B4-A7E8-C7432BEA3225@isara.com> <CACsn0cnozhq1-cvQr_ojb8v79+6E4xi04gnV33aUAN-8tWWCzw@mail.gmail.com>
Organization: Red Hat, Inc.
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-MC-Unique: BGc9BbWOMP66NizhT98L-Q-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/s8XtNs7a2-M08MM-Ww9r03grRgM>
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 19:04:09 -0000
On Thu, 2019-11-21 at 22:44 -0500, Watson Ladd wrote: > On Thu, Nov 21, 2019 at 9:44 PM Daniel Van Geest <Daniel.VanGeest@isara.com> > wrote: > > > 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. > > > > Any protocol where ordinary sysadmin tasks like restoring from backup or > running salt/Ansible/system de jour can cause a complete and total break of > security is unsuitable for a lot of servers. when used in SSH. Furthermore > PQ signatures aren't needed yet: you cannot retroactively attack > authorization they way you can encryption. I also oppose adoption. I am also very concerned about allowing such a fragile construct for SSH specifically. Among all the issues mentioned above I want to add that in practice ssh keys are used concurrently by multiple binaries in modern software distributions. For example OpenSSH my be used by an interactive user at the same time as another automated process uses libssh. If these processes use the same keys without the coordination of a tightly controlled key management solution (like an HSM, or a special daemon, or some form of mandatory file locking and IPC) we will see an immediate disaster. Moreover, private keys are commonly copied between different systems by users, that behavior is perfectly fine and common nowadays but would be catastrophic with this mechanism. My 2c. simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc
- [Curdle] call for adoption for draft-mu-curdle-ss… Daniel Migault
- Re: [Curdle] call for adoption for draft-mu-curdl… denis bider
- Re: [Curdle] call for adoption for draft-mu-curdl… Panos Kampanakis (pkampana)
- Re: [Curdle] call for adoption for draft-mu-curdl… denis bider
- Re: [Curdle] call for adoption for draft-mu-curdl… Panos Kampanakis (pkampana)
- Re: [Curdle] call for adoption for draft-mu-curdl… Salz, Rich
- Re: [Curdle] call for adoption for draft-mu-curdl… Daniel Van Geest
- Re: [Curdle] call for adoption for draft-mu-curdl… Watson Ladd
- Re: [Curdle] call for adoption for draft-mu-curdl… Simo Sorce
- Re: [Curdle] call for adoption for draft-mu-curdl… denis bider
- Re: [Curdle] call for adoption for draft-mu-curdl… Hubert Kario
- Re: [Curdle] call for adoption for draft-mu-curdl… Simo Sorce
- Re: [Curdle] call for adoption for draft-mu-curdl… Hammell, Jonathan F
- Re: [Curdle] call for adoption for draft-mu-curdl… Stephen Farrell
- Re: [Curdle] call for adoption for draft-mu-curdl… Daniel Migault
- Re: [Curdle] call for adoption for draft-mu-curdl… Stephen Farrell
- Re: [Curdle] call for adoption for draft-mu-curdl… Salz, Rich
- [Curdle] Fwd: call for adoption for draft-mu-curd… Daniel Migault
- Re: [Curdle] call for adoption for draft-mu-curdl… denis bider
- Re: [Curdle] call for adoption for draft-mu-curdl… Daniel Migault