[dns-operations] help with a resolution

Wed Jan 8 19:53:42 UTC 2020

On Wed, Jan 8, 2020 at 1:54 PM Viktor Dukhovni <ietf-dane at dukhovni.org> 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.
>

Can someone please explain to me in baby words how the SHA-1 issue
affects DNSSEC? Yes, I'm all for banging the "Move to a newer hash"
drum, but I'm still failing to see how this can be used against DNSSEC
-- from what I understand, an attacker can generate a hash collision
(2 inputs which hash to the same output), but SHA-1 is still
2nd-preimage resistant - given the hash
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find
another message which hashes to this.

So, I *could* see an attacker being able to make 2 records or keys
which have the same hash -- but, meh, that's not actually useful to
them.

eg: The DS for dns-oarc.net is: 20899 8 1
6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a
new key which hashes to this. They could in theory make 2 DNSKEYs
which have the same hash (although, because of the format of DNSKEYs I
don't think they can do this in practice), but that just allows them
to replace a zone *which they control* with another zone *which they
also control*.

I'm feeling like I'm missing something obvious here...

W

> > 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.
>
>     - 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.
>
> > > 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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf