[dns-operations] help with a resolution

[Mukund Sivaraman]

Hi Viktor

On Wed, Jan 08, 2020 at 10:05:53AM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote:
> 
> > [muks at jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
> > Generating key pair..................+++++ .............+++++ 
> > Kexample.org.+005+04222
> >
> > [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).
> 
> Of these two, I'd recommend algorithm 13, because it produces signatures
> that are more secure and substantially more compact.  Indeed algorithm
> 13 is now the most popular algorithm among signed domains, having
> recently surpassed 8:
> 
>     https://stats.dnssec-tools.org/#parameter
> 
> Algorithm 5 is a very distant 4th.

You are absolutely right and algorithm 13 is best suited.

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.

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.

I think BIND's dnssec-keygen requires you to specify the algorithm now,
so the poster will likely need to provide it.

> > Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
> > for SHA-1 hash which is weakening in security day by day, so you would
> > probably want to add only the "5 2" RR from above, where 2 stands for
> > SHA-256. A complete list of these is here:
> > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
> 
> This is wrong.  The attacks are not against the digest algorithm that's
> hashing the key.  With the DS RR digest types there are no collision
> issues, and only SHA-1 2nd-preimage resistance matters, which remains
> unbroken.
> 
> 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.

----

On the topic of the recent "SHA-1 is a Shambles" ePrint paper and the
dnsop thread about how it affects DNSSEC, perhaps I may have understood
what you have pictured by DS needing second pre-image resistance, but
there are different sorts of situations and once a digest's security has
weakened so much, it is basically to be avoided. 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. 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 - a leak of the
first KSK may not be possible by other safeguards, or be discovered from
observed rogue signatures, but the existence of the second KSK may not
be known or suspected. It may not matter to a particular use case or
line of thinking, but cryptography security is about preventing every
circumstance.

MD5 also doesn't have a practical second pre-image attack, but it was
not added as a DS digest.

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.