On Tue, Jan 7, 2020, 8:18 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > > Due to the structure of DNS records this is hard to pull off, the only RR types that are suspect are the ones that can have 1440 of "garbage" at the end DS has fixed size so I it can not be used unless someone figures out how select blocks that include valid DNS record envelopes. TXT will work if the attacker can encode lengths of the individual strings into a valid record ==> but who cares about TXT abuse DNSKEY is with RSA is good candidate for this attack as any DNSKEY RRset for SHA1 algorithms can be attacked by adding a key that sorts to be last and is larger than 1440 bits. Thus anyone that is using RSA algorithm < 8 should think about key or algorithm rollover Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
