On Wed, Jan 08, 2020 at 01:45:44PM -0500, Viktor Dukhovni wrote: > On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote: > > > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222 > > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2 > > > > example.org. IN DS 4222 5 2 > > > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831 > > > > > > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new > > > deployments. The current best-practice choices are algorithm 8 (RSA > > > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and > > > SHA2-256). > > > > You are absolutely right and algorithm 13 is best suited. > > And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now > really needs to be avoided. > > > It was really not an example to pick an algorithm, but to demonstrate > > how to verify a zone which the poster asked. No algorithm arguments were > > passed. > > Sure, but you were also advising against the SHA-1 DS digest type (still > reasonably safe) in an example that used algorithm 5 with its now rather > weakened RSASHA1 signature. I think that warranted a comment, just in > case anyway walked away with the wrong impression.
You're right of course that algorithm 13 ought to be used in preference. > > - Algorithms 5 and 7 are now seriously wounded, though perhaps not > yet in all use-cases dead. > > - DS algorithm 1 is tarnished and not recommended, but there are > no known attacks. > > > Loop's toolchain has had the default algorithms so, which it inherited. > > There > > is a branch that changes the defaults, but it won't be merged in the first > > quarter of this year. > > If there is a default, it should promptly change to 8 or 13. I will prioritize it. > > > Instead, the attacks are against SHA-1 based *signature* algorithms, where > > > the key-holder (typically parent zone) signs data that is partly under the > > > control of potentially hostile others. So the important thing is avoiding > > > algorithms 5 and 7, NOT avoiding digest type 1. > > > > The mail only said SHA-1 is weakening in security day by day. A better > > choice > > is available and widely supported which is digest 2, which was printed by > > the > > default run of dnssec-dsfromkey in the example and explained as preferrable. > > See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the > reason, there are no known attacks there, the real issue is DNSKEY algorithms > 5 and 7. > > > With the chosen-prefix collision attack, a rogue actor who is in charge of > > creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest > > field. > > If you have a rogue actor controlling your KSKs, all bets are off. > > > He may then submit and deploy the 1st key at his workplace and then sell the > > 2nd key that would lead a different paper trail than the first > > I don't see the point, why not just sell the real key, what difference does it > make. Indeed if the second key gets discovered, then it is clear the keys > were cooked, and who the guilty party is. But with a leak of the single > legitimate key, it is far less clear a-priori who leaked the key. > > > MD5 also doesn't have a practical second pre-image attack, but it was not > > added as a DS digest. > > Indeed, we avoid new uses of tarnished algorithms. > > > Having read many of your posts, I greatly respect your opinion. It seems > > unnatural to me that you would use SHA-1 as a DS digest type today, or not > > advise a friend to switch from it if you saw it being used. > > I would not introduce new uses of SHA-1 in DS RRs. Below is my complete > DS RRset: > > dukhovni.org. IN DS 34314 13 2 > 1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2 > > my point is that if you do have a SHA-1 DS RR, that's not an immediate > problem, but algorithms 5 and 7, especially in zones that sign other > people's data, are a much more immediate probem, and because it is > difficult to explain which use-case of 5 and 7 are still safe, and which > are not, the priority is to deprecate these DNSKEY algorithms. > > We can also discourage SHA-1 as a DS digest type, but only out of an > abundance of caution, we now have better algorithms in which we have > more confidence. There's no known practical threat, the algorithm still > offers around 160 bits of 2nd pre-image resistance and is well out of > reach of any known attacks. > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > Mukund _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
