[dns-operations] help with a resolution

[Viktor Dukhovni]

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.

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