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