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

[Olafur Gudmundsson <[e-mail]>]

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <[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 <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