Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01
Petr Špaček <petr.spacek@nic.cz> Mon, 15 May 2017 22:45 UTC
Return-Path: <petr.spacek@nic.cz>
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 E2B491294C8 for <dnsop@ietfa.amsl.com>; Mon, 15 May 2017 15:45:09 -0700 (PDT)
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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 A6gclfOziw9v for <dnsop@ietfa.amsl.com>; Mon, 15 May 2017 15:45:07 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 8D57D126D85 for <dnsop@ietf.org>; Mon, 15 May 2017 15:42:31 -0700 (PDT)
Received: from [10.20.67.175] (104.red-83-48-50.staticip.rima-tde.net [83.48.50.104]) by mail.nic.cz (Postfix) with ESMTPSA id 4D62060187 for <dnsop@ietf.org>; Tue, 16 May 2017 00:42:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1494888149; bh=t7bKVwUVWXqT6fIcTwmoukL3oR8PuYhlSiUZKmSoHx4=; h=To:From:Date; b=oJ/bo2D5kwPrnXcYt+4cxrdwxx+JJ+gVdsUhjEF0UbrVQGOD8BijDB9rADIofYN9U nwOmvaocJ8/HTQ3YUaSFD6pjHK/SCFc71IFI6wtz/SN7//gEj98xlloOlLvp8ldgb5 cl3Qc56Dpz1rMXle1NWngUd6bO5GtXawaJug3DT0=
To: dnsop@ietf.org
References: <20170410093847.GA21654@jurassic> <CA+nkc8AebVmM46FQ3hzcz9OkNEMvBu6EcSHF-L=hp9qobS8UHQ@mail.gmail.com> <20170410150917.GA22210@jurassic> <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <904cda8d-50eb-b49d-30af-a33cb7155893@nic.cz>
Date: Tue, 16 May 2017 00:42:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/meig3l7d8VrMx9SgZUxoqwNoZso>
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: Mon, 15 May 2017 22:45:10 -0000
On 5.5.2017 14:30, Olafur Gudmundsson wrote: > >> 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. >> > > Ok I will bite and be the grumpy old man. > > I strongly advocate against the adoption of this document in current from. > It violates basic interoperability guidelines by defining way to many > algorithms with no justification why any of them are better or worse > than others. > There is no useful guidance on why these new algorithms are better even > among themselves. > > One of the biggest hurdles to deployment is not in the 5-20 DNS software > packages in wide use; but in all the 1000’s of Provision systems around > the world, > and the crypto libraries found on various Enterprise systems that have > life time of 4-8 years with security-only updates. > Lets learn the lessons documented > in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 > > I’m not convinced that SHA3 vs SHA2 matter at all given the constraint > small data with strict constraints on order and contents is being signed. > > Thus why define > - 5 new RSA algorithms proposed, why why ? ? > - 2 new ECDSA algorithms proposed why why ? ? > In another document there 2 other algorithms being proposed at the same > time, that I support as they represent new and > faster technology. > All this will do is to cause confusion! > > The RSA KEY size allowed for these new supposed stronger Digest > algorithms is still left at 1024 or 1280 bytes, even though number of > other parts of the the Internet community will not consider signatures > by keys with less than 2048 bits. > > If there is any reason to go down the path of this document it should > pick ONE RSA and ONE ECDSA algorithm. > RSA should be defined sensible guidelines on key sizes; i.e. no keys > below some stronger value in the 1536-2048 byte range. > > The document is proposing two new DS algorithms WHY? > The basic reason for new a DIS digest algorithm is “much better” so > pick one and live with it. > > There was an interesting discussion on a resolver software mailing list > few weeks back about what the RFC’s mean when there are DS records with > different digest > algorithm numbers: A domain had 2 DS records one with digest 1 one with > digest 2; > They both referred to the same key, but there was a typo/error in the > digest with algorithm 2; > Question what should the validator do ? > a) only trust the highest digest number? > b) trust any DS record ? > I.e. a higher number was interpreted by the implementor to mean better > thus only the highest supported number was the only one tried. > > Additionally this document in its current form contains proposed > algorithm values which IMHO is a NoNo and I hope is removed from future > versions. > If there are interoperability tests you can define the numbers you want > to use on web page; not in an internet draft that someone may go ahead and > implement not realizing that the final RFC will have a different number(s). > > Olafur Very well said, Olafur. I'm also against adoption of this document in its current form. -- Petr Špaček @ CZ.NIC
- [DNSOP] Fwd: New Version Notification for draft-m… Mukund Sivaraman
- Re: [DNSOP] Fwd: New Version Notification for dra… Bob Harold
- Re: [DNSOP] Fwd: New Version Notification for dra… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Olafur Gudmundsson
- Re: [DNSOP] New Version Notification for draft-mu… Russ Housley
- Re: [DNSOP] New Version Notification for draft-mu… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Russ Housley
- Re: [DNSOP] New Version Notification for draft-mu… Petr Špaček