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

Hubert Kario <hkario@redhat.com> Mon, 25 November 2019 12:25 UTC

Return-Path: <hkario@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 4264E12092E for <curdle@ietfa.amsl.com>; Mon, 25 Nov 2019 04:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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] 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 AXUpld66uf4O for <curdle@ietfa.amsl.com>; Mon, 25 Nov 2019 04:25:28 -0800 (PST)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD702120115 for <curdle@ietf.org>; Mon, 25 Nov 2019 04:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574684726; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rC2CrTaoGjOR+ABq6N28knkWc6y9LmfFRmEQMcIQm10=; b=eJ1qasq9+VWs8sVinx6FtM2R4cgDQNSuMy2byWKXpm2LdfGeyL1bvgKGGdT71wH089ZgBz Ivb+sDjtKj8kRIs+5Hrx3OtUIAZKgNhgHYeyNEwtzV1XiwwaXjV1niWnIpqACLezoS7Obk +Ur+kWQH8gFnWVlq9Y/2RyFIfH2v0IE=
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-398-Ij-GxJ0yOWeYx8bvIt0vSQ-1; Mon, 25 Nov 2019 07:25:24 -0500
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A96AB593A1 for <curdle@ietf.org>; Mon, 25 Nov 2019 12:25:21 +0000 (UTC)
Received: from localhost (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 453B45D6A0 for <curdle@ietf.org>; Mon, 25 Nov 2019 12:25:20 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: curdle@ietf.org
Date: Mon, 25 Nov 2019 13:25:18 +0100
MIME-Version: 1.0
Message-ID: <62a1b85f-f26f-458d-bc61-0be8c92c8626@redhat.com>
In-Reply-To: <CADPMZDBrGqbkMtct2EPsLqGOt3=QMHZ_568x_YbEeftwZS=+6Q@mail.gmail.com>
References: <6F37DBC7-172E-44B4-A7E8-C7432BEA3225@isara.com> <CACsn0cnozhq1-cvQr_ojb8v79+6E4xi04gnV33aUAN-8tWWCzw@mail.gmail.com> <2de53edd5bdba6147d922963f4f8d859bd016bb9.camel@redhat.com> <CADPMZDBrGqbkMtct2EPsLqGOt3=QMHZ_568x_YbEeftwZS=+6Q@mail.gmail.com>
Organization: Red Hat
User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-MC-Unique: Ij-GxJ0yOWeYx8bvIt0vSQ-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/3OkDBiHa5ZmftYn8RCl2yFwaK0U>
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: Mon, 25 Nov 2019 12:25:30 -0000

On Saturday, 23 November 2019 03:38:56 CET, denis bider wrote:
> Those are all valid concerns, however the XMSS key could conceivably be
> located on a smart card which contains the key and solves all these
> concerns.
>
> An RFC could spell out in all caps that use on a dedicated device is the
> only usage case recommended.

That's very fragile still, as the client has no way of knowing if the 
signature
was made by a HSM or not.

The biggest problem now for PQ is encryption that can be broken after big
quantum computers become available (either directly or because the key 
exchange
is not quantum-secure). Making quantum-safe authentication methods
does not help with that.

So I am opposed to adoption of it.

We can reconsider after NIST publishes its findings, but even then it looks
way too fragile for use in SSH.

> On Fri, Nov 22, 2019 at 1:04 PM Simo Sorce <simo@redhat.com> wrote:
>
>> 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:
>>>  ...
>> 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). ...
>> like
>>>> ...
>>> 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
>> 
>> 
>> 
>> 
>> 
>
>

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic