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

[Petr Špaček <[e-mail]>]

On 5.5.2017 14:30, Olafur Gudmundsson wrote:
> 
>> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <[e-mail]
>> <mailto:[e-mail]>> 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