Re: [DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1

[Viktor Dukhovni <[e-mail]>]

On Tue, Jan 07, 2020 at 02:54:43PM +0000, Tony Finch wrote:

> The third paragraph of the abstract suggests this is relevant to DNSSEC RSASHA1:
> 
> https://eprint.iacr.org/2020/014

[ I've Bcc'd the authors, perhaps they'll follow up with a comment, or
  reply to me off-list with permission to quote or repost. ]

> > Therefore, the same attacks that have been practical on MD5 since 2009
> > are now practical on SHA-1. In particular, chosen-prefix collisions can
> > break signature schemes and handshake security in secure channel
> > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those type
> > of applications as soon as possible. We exemplify our cryptanalysis by
> > creating a pair of PGP/GnuPG keys with different identities, but
> > colliding SHA-1 certificates. A SHA-1 certification of the first key can
> > therefore be transferred to the second key, leading to a forgery. This
> > proves that SHA-1 signatures now offers virtually no security in
> > practice. The legacy branch of GnuPG still uses SHA-1 by default for
> > identity certifications, but after notifying the authors, the modern
> > branch now rejects SHA-1 signatures (the issue is tracked as
> > CVE-2019-14855).

Reading the paper more closely, one finds:

- Section 1.1
  - Record Computation
    - 2nd paragraph:
      ... Our attack uses one partial block for the birthday stage,and 9
      near-collision blocks.

If I'm reading this correctly, the attack requires > 9*160 = 1440 bits
of complete freedom in the tail of the data to be signed.  But with
RSASHA1, when a parent domain signs the DS RRset of a child zone, the

    https://tools.ietf.org/html/rfc4034#section-3.1.8.1

    RR(i) = owner | type | class | TTL | RDATA length | RDATA

elements at the end of the data to be signed have repeating structure in
the owner, type, class and TTL, which likely mean that just the digest
of each "DS" RDATA is fully attacker controlled.  This digest must then
be ~1440 bits long, but that would only be the case if the signer paid
no attention to the (plausible) validity of the DS RRs, since IIRC none
of the registered DS digest types produce hashes this long.

    https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

If a parent zone does accept arbitrary DS RR payloads in which the hash
value length is not consistent with the purported digest type, then it
may well be exposed to the chosen-prefix attack.  Otherwise, it may be
that checking the hash value to be of the expected length for the digest
type (160, 256 or 384 bits depending on the digest type) is enough to
thwart this specific attack.

This does not mean that staying with algorithm 7 (RSASHA1) is a good
idea, but may buy more time to migrate in an orderly manner.

-- 
    Viktor.