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

Petr Špaček <> Mon, 15 May 2017 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2B491294C8 for <>; Mon, 15 May 2017 15:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A6gclfOziw9v for <>; Mon, 15 May 2017 15:45:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D57D126D85 for <>; Mon, 15 May 2017 15:42:31 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 4D62060187 for <>; Tue, 16 May 2017 00:42:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1494888149; bh=t7bKVwUVWXqT6fIcTwmoukL3oR8PuYhlSiUZKmSoHx4=; h=To:From:Date; b=oJ/bo2D5kwPrnXcYt+4cxrdwxx+JJ+gVdsUhjEF0UbrVQGOD8BijDB9rADIofYN9U nwOmvaocJ8/HTQ3YUaSFD6pjHK/SCFc71IFI6wtz/SN7//gEj98xlloOlLvp8ldgb5 cl3Qc56Dpz1rMXle1NWngUd6bO5GtXawaJug3DT0=
References: <20170410093847.GA21654@jurassic> <> <20170410150917.GA22210@jurassic> <>
From: Petr Špaček <>
Organization: CZ.NIC
Message-ID: <>
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: <>
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: <>
Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <
>> <>> 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
> 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