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