Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01

Russ Housley <housley@vigilsec.com> Fri, 05 May 2017 17:21 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F67124D37 for <dnsop@ietfa.amsl.com>; Fri, 5 May 2017 10:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 U5gjIT4YHBiQ for <dnsop@ietfa.amsl.com>; Fri, 5 May 2017 10:21:08 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC43129453 for <dnsop@ietf.org>; Fri, 5 May 2017 10:21:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 943643004EE for <dnsop@ietf.org>; Fri, 5 May 2017 13:21:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id koBrVceWCQJH for <dnsop@ietf.org>; Fri, 5 May 2017 13:21:06 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8849F30041F; Fri, 5 May 2017 13:21:06 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <26802308-28D0-4BC1-BEC4-E5A8C52B7A35@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E861D4F-88B6-41D6-A894-1F919BF286BA"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 5 May 2017 13:21:06 -0400
In-Reply-To: <20170410150917.GA22210@jurassic>
Cc: IETF DNSOP WG <dnsop@ietf.org>
To: Mukund Sivaraman <muks@isc.org>
References: <20170410093847.GA21654@jurassic> <CA+nkc8AebVmM46FQ3hzcz9OkNEMvBu6EcSHF-L=hp9qobS8UHQ@mail.gmail.com> <20170410150917.GA22210@jurassic>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OE5xaHzN0fBeN7MZW1C00kNuRJM>
Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 17:21:10 -0000

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <muks@isc.org <mailto:muks@isc.org>> wrote:
> 
> We kind of restarted the draft adopting RSASSA-PSS, so please can you
> review it this time from scratch without looking at the diff?
> 
> Many of the examples will need updating once algorithm numbers are
> assigned for them (as for some calculations, the algorithm number is an
> input), so we didn't spend time on wrapping the long lines in this
> revision.

I suggest that many of the options be dropped from this document before the working group accepts it.

I strongly support the move toward RSASSA-PSS or ECDSA.  Both of these offer an improvement over RSA PKCS#1 v1.5.  That said, we have a lot of experience that shows algorithm transitions are slow, so I think the working group should pick one of these signature algorithms, not both.

Why does this document support both SHA2 and SHA3?  We know that theses families of hash algorithms offer the same security.  That is, SHA2-256 and SHA3-256 offer exactly the same security.  One could argue that the reason to support both is because a flaw might be found in one and the other is there for safety.  Instead, I suggest that picking one family of hash algorithms already provides that safety.  One can use SHA2-384 or SHA2-512 if a flaw is discovered in SHA2-256.  So, again, pick one, not both.

Russ