[dns-operations] help with a resolution

[Mukund Sivaraman]

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 at 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>

			Mukund