[Curdle] On SSH-XMSS

Marian Sigler <sigler@inf.fu-berlin.de> Tue, 31 March 2020 17:00 UTC

Return-Path: <sigler@zedat.fu-berlin.de>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D19E73A2456 for <curdle@ietfa.amsl.com>; Tue, 31 Mar 2020 10:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rZX7aqJsV5yL for <curdle@ietfa.amsl.com>; Tue, 31 Mar 2020 10:00:34 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de []) (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 8C1AF3A2457 for <curdle@ietf.org>; Tue, 31 Mar 2020 10:00:34 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([]) by outpost.zedat.fu-berlin.de (Exim 4.93) for curdle@ietf.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from <sigler@zedat.fu-berlin.de>) id 1jJKFc-002Ie0-U9; Tue, 31 Mar 2020 19:00:32 +0200
Received: from port-92-195-65-238.dynamic.as20676.net ([] helo=[]) by inpost2.zedat.fu-berlin.de (Exim 4.93) for curdle@ietf.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from <sigler@inf.fu-berlin.de>) id 1jJKFc-000XJR-Ix; Tue, 31 Mar 2020 19:00:32 +0200
From: Marian Sigler <sigler@inf.fu-berlin.de>
To: curdle@ietf.org
Message-ID: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de>
Date: Tue, 31 Mar 2020 19:00:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
X-Original-Sender: sigler@inf.fu-berlin.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/uKs2omzszssbFZZ_5jv-Hmwo_NQ>
X-Mailman-Approved-At: Wed, 01 Apr 2020 04:10:56 -0700
Subject: [Curdle] On SSH-XMSS
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: Wed, 01 Apr 2020 11:06:33 -0000

Hi everyone.

I've stumbled upon the SSH-XMSS draft [1], and, after being very
astonished about it not mentioning the problems arising from XMSS's
statefulness, I found your discussion and I am glad that you decided not
to proceed on it.
I was wondering if it was possible to add a note to the draft that it
has been rejected?

Also, NIST has now published the Recommendations about stateful schemes
you've been talking about as a draft (already in December, actually) :


Since it hasn't been mentioned here, I thought some of you might
appreciate the hint.

To summarize: The recommendation explicitly forbids any use of XMSS
outside of hardware security modules. Further, it demands that the keys
be generated inside the hardware module, and that it never exports
private keying material.


[1] https://tools.ietf.org/id/draft-mu-curdle-ssh-xmss-00.html