On 5.5.2017 14:30, Olafur Gudmundsson wrote: > >> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <m...@isc.org >> <mailto:m...@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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
