Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-06.txt

"A. Huelsing" <ietf@huelsing.net> Mon, 25 July 2016 12:03 UTC

Return-Path: <ietf@huelsing.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A873712D781 for <cfrg@ietfa.amsl.com>; Mon, 25 Jul 2016 05:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_PHISH=2.5] autolearn=no 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 hnaPsgbrwKiW for <cfrg@ietfa.amsl.com>; Mon, 25 Jul 2016 05:03:17 -0700 (PDT)
Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (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 665DB12D739 for <cfrg@irtf.org>; Mon, 25 Jul 2016 05:03:17 -0700 (PDT)
Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from <ietf@huelsing.net>) id 1bRebL-0006T9-G2; Mon, 25 Jul 2016 14:03:15 +0200
Received: from [131.155.68.224] by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <ietf@huelsing.net>) id 1bRebL-0004F2-9v; Mon, 25 Jul 2016 14:03:15 +0200
To: Phillip Hallam-Baker <phill@hallambaker.com>, cfrg@irtf.org, "Paterson, Kenny" <kenny.paterson@rhul.ac.uk>
References: <20160706144508.25995.18605.idtracker@ietfa.amsl.com> <577D1B6E.1020506@huelsing.net> <D3B93AC9.7187E%kenny.paterson@rhul.ac.uk> <994C5976EA09B556.08963792-86E6-4CE4-95FB-23F0F6046EC0@mail.outlook.com>
From: "A. Huelsing" <ietf@huelsing.net>
Message-ID: <a3cde8af-7f1a-d374-73cc-d7f8b5d4e4f7@huelsing.net>
Date: Mon, 25 Jul 2016 14:03:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <994C5976EA09B556.08963792-86E6-4CE4-95FB-23F0F6046EC0@mail.outlook.com>
Content-Type: multipart/alternative; boundary="------------22A23E285738FBECE63D6741"
X-Authenticated-Sender: ietf@huelsing.net
X-Virus-Scanned: Clear (ClamAV 0.99.2/21966/Mon Jul 25 09:05:20 2016)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Uhs_NyLpdkx45Wb7vBSSpN1W64o>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-06.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2016 12:03:20 -0000

I want to emphasize here that we are currently not talking about
hash-based signatures in general, but about a specific scheme (XMSS, as
described in the draft). This scheme is stateful and we point this --
and the issues coming with it -- out at several points in the document.
There exists no "stateless hack" applicable to that scheme. There exist
different (hash-based) schemes that are stateless but that's a totally
different story. 

On 07/23/16 21:03, Phillip Hallam-Baker wrote:
> I think the text gets the position wrong.
>
> We are in fact very confident that Hash signatures are secure against
> QC. We have no current attack on symmetric crypto that gives us
> concern on that score.
>
> BUT, where we have a big question mark is on the 'use once' aspect of
> hash signatures. The systems depend either on absolutely on not
> screwing up and signing more than once or on the security of some
> 'stateless' hack which may or may not be secure. So there is a big big
> question as far as systems integration goes and on robustness of the
> system as a whole.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
>
>
>
>
> On Sat, Jul 23, 2016 at 10:35 AM -0400, "Paterson, Kenny"
> <Kenny.Paterson@rhul.ac.uk <mailto:Kenny.Paterson@rhul.ac.uk>> wrote:
>
>     Dear Andreas,
>
>     Thanks for pushing the new version.
>
>     Stephen and I had a chat at IETF 96 this week. His original suggestion for
>     text to be added was this [1]:
>
>     "All quantum-resistant algorithms documented by CFRG are today
>     considered ready for experimentation and further engineering
>     development (e.g. to establish the impact of performance and sizes
>     on IETF protocols) but CFRG has consensus that we are not yet
>     sufficiently confident to the point where we would want the security
>     or privacy of a significant part of the Internet to be dependent on
>     any set of those algorithms. In future, as things mature, CFRG
>     intends to publish updated guidance on this topic."
>
>     Personally, I think this is too strong for hash-based signatures: although
>     we have no deployment experience (that I know of), we do have fairly
>     strong confidence in the security of hash-based signatures against quantum
>     computers, given the current state of the art of research in quantum
>     algorithms. I'd suggest instead that some text like this should be
>     included:
>
>
>     "All quantum-resistant algorithms documented by CFRG are today
>     considered ready for experimentation and further engineering
>     development (e.g. to establish the impact of performance and sizes
>     on IETF protocols). However, at the time of writing, we do not have
>     significant deployment experience with such algorithms.
>     CFRG consensus is that we are confident in the security of the
>     signature schemes described in this document against
>
>     quantum computers, given the current state of the research
>     community's knowledge about quantum algorithms. Indeed, we are
>     confident that the security of a significant part of the Internet
>     could be made dependent on the signature schemes defined in this
>     document."
>      
>     I realise that's a pretty strong statement that is the opposite of what
>     Stephen suggested *for these signature schemes*.
>
>     So let's discuss a bit more, and see if there is consensus from CFRG for
>     the statement I've made here. Happy also to receive suggestions for
>     alternative, better-worded statements.
>
>     Cheers,
>
>
>     Kenny
>
>     [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg08315.html
>
>     On 06/07/2016 15:53, "Cfrg on behalf of A. Huelsing"
>     wrote: >Hi, > >we pushed a new version that further simplifies the
>     addresses due to a >comment we received off-list. It is a minor
>     change that simplifies >implementation of addresses as u_int32
>     array. We did not take any action >regarding Stephens comment,
>     yet. For this we want to get more feedback >on what we should do.
>     > >Andreas > > > >On 07/06/16 16:45, internet-drafts@ietf.org
>     wrote: >> A New Internet-Draft is available from the on-line
>     Internet-Drafts >>directories. >> This draft is a work item of the
>     Crypto Forum of the IETF. >> >> Title : XMSS: Extended Hash-Based
>     Signatures >> Authors : Andreas Huelsing >> Denis Butin >>
>     Stefan-Lukas Gazdag >> Aziz Mohaisen >> Filename :
>     draft-irtf-cfrg-xmss-hash-based-signatures-06.txt >> Pages : 66 >>
>     Date : 2016-07-06 >> >> Abstract: >> This note describes the
>     eXtended Merkle Signature Scheme (XMSS), a >> hash-based digital
>     signature system. It follows existing >> descriptions in
>     scientific literature. The note specifies the WOTS+ >> one-time
>     signature scheme, a single-tree (XMSS) and a multi-tree >> variant
>     (XMSS^MT) of XMSS. Both variants use WOTS+ as a main >> building
>     block. XMSS provides cryptographic digital signatures >> without
>     relying on the conjectured hardness of mathematical problems. >>
>     Instead, it is proven that it only relies on the properties of >>
>     cryptographic hash functions. XMSS provides strong security >>
>     guarantees and is even secure when the collision resistance of the
>     >> underlying hash function is broken. It is suitable for compact
>     >> implementations, relatively simple to implement, and naturally
>     >> resists side-channel attacks. Unlike most other signature
>     systems, >> hash-based signatures withstand attacks using quantum
>     computers. >> >> >> The IETF datatracker status page for this
>     draft is: >>
>     >>https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatur
>     >>es/ >> >> There's also a htmlized version available at: >>
>     >>https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-06
>     >> >> A diff from the previous version is available at: >>
>     >>https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatu
>     >>res-06 >> >> >> Please note that it may take a couple of minutes
>     from the time of >>submission >> until the htmlized version and
>     diff are available at tools.ietf.org. >> >> Internet-Drafts are
>     also available by anonymous FTP at: >>
>     ftp://ftp.ietf.org/internet-drafts/ >> >>
>     _______________________________________________ >> Cfrg mailing
>     list >> Cfrg@irtf.org >>
>     https://www.irtf.org/mailman/listinfo/cfrg >
>     >_______________________________________________ >Cfrg mailing
>     list >Cfrg@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg
>     _______________________________________________ Cfrg mailing list
>     Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg
>