Return-Path: 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 471F8130E07; Wed, 5 Sep 2018 04:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 7bnBEpp0_jKh; Wed, 5 Sep 2018 04:16:55 -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 7C0DD130DFB; Wed, 5 Sep 2018 04:16:55 -0700 (PDT) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fxVno-0002Uu-Ap; Wed, 05 Sep 2018 13:16:52 +0200 Received: from [131.155.68.130] by sslproxy01.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fxVno-00069W-57; Wed, 05 Sep 2018 13:16:52 +0200 To: Martin Thomson , Stephen Farrell Cc: "irsg@irtf.org" , IRTF CFRG , "Scott Fluhrer (sfluhrer)" References: <59d9a102-8ba8-3469-8277-3facb0dd6a11@cs.tcd.ie> <2ec3c347-47c9-79e2-22c0-bc8d257e4f90@cs.tcd.ie> From: "A. Huelsing" Message-ID: Date: Wed, 5 Sep 2018 13:16:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------42BCD9DF017C534251D00E41" Content-Language: en-GB X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.100.1/24904/Wed Sep 5 10:45:05 2018) Archived-At: Subject: Re: [Cfrg] irsg review of draft-mcgrew-hash-sigs-12 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 11:16:59 -0000 This is a multi-part message in MIME format. --------------42BCD9DF017C534251D00E41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit May I refer to the XMSS RFC. We were facing the exact same comment by Stephen (and the schemes are sufficiently similar to compare). Our solution was to ask every implementation to implement verification for all SHA2-256 parameters. For signature generation, we only propose three "standard parameter sets" for specific settings as a default option but do not ask to support any specific parameter set. Cheers, Andreas Am 05-09-18 um 10:33 schrieb Martin Thomson: > > > On Wed, 5 Sep. 2018, 18:03 Stephen Farrell, > wrote: > > > I disagree. We have seen cases (e.g. [1]) where CFRG RFCs > leaving in options has lead to IETF WGs debating what to do, > over and over. That seems to me to be CFRG's "fault" as it's > predictable and could affect interop. > > > I agree with Stephen here. Though that part of the work might be more > difficult, it is also the most valuable. Getting a tool with multiple knobs is > not a net improvement over having no tool at all, and it can lead to interop > failures. > > Too many primitives we get are effectively unusable as a result of having > options. The debate around ed25519 use for DKIM is a great example of that. > RSA-PSS is another great example of a tool with too many independent inputs. > > Those who find the one option too constraining can take on the extra costs of > breaking new ground. Most should not have to. > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --------------42BCD9DF017C534251D00E41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit May I refer to the XMSS RFC. We were facing the exact same comment by Stephen (and the schemes are sufficiently similar to compare). Our solution was to ask every implementation to implement verification for all SHA2-256 parameters. For signature generation, we only propose three "standard parameter sets" for specific settings as a default option but do not ask to support any specific parameter set.

Cheers,

Andreas

Am 05-09-18 um 10:33 schrieb Martin Thomson:


On Wed, 5 Sep. 2018, 18:03 Stephen Farrell, <stephen.farrell@cs.tcd.ie> wrote:

I disagree. We have seen cases (e.g. [1]) where CFRG RFCs
leaving in options has lead to IETF WGs debating what to do,
over and over. That seems to me to be CFRG's "fault" as it's
predictable and could affect interop.

I agree with Stephen here. Though that part of the work might be more difficult, it is also the most valuable. Getting a tool with multiple knobs is not a net improvement over having no tool at all, and it can lead to interop failures.

Too many primitives we get are effectively unusable as a result of having options. The debate around ed25519 use for DKIM is a great example of that. RSA-PSS is another great example of a tool with too many independent inputs.

Those who find the one option too constraining can take on the extra costs of breaking new ground. Most should not have to.


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--------------42BCD9DF017C534251D00E41--