Re: [dns-operations] SHA-1 chosen-prefix collisions
Viktor Dukhovni wrote: > > A chosen-prefix attack is a powerful tool, a message with metadata P and > payload S can now have the same digest as a message with completely > different, chosen by the attacker metadata P' and payload S' (though > ultimately the combined message lengths need to be the same). There are some really nice diagrams of the overall shape of these attacks on the page about the MD5 rogue CA chosen prefix collision https://www.win.tue.nl/hashclash/rogue-ca/ especially the second diagram in section 3.5 https://www.win.tue.nl/hashclash/rogue-ca/images/diffIV.png > So the present attack requires a suffix of ~640 rather than ~200 bytes. Oh, that might make it a bit harder. This is shown in figure 7 in the SHAmbles paper? > Perhaps it is possible to split the suffix over multiple RRs, Very tricky. I get the impression from table 1 in the SHAttered paper http://shattered.io/static/shattered.pdf and figure 6 in the SHAmbles paper https://eprint.iacr.org/2020/014.pdf that the constraints on the collision blocks are too dense to overlay on parts of a message with significant syntax. (Unless maybe you are Ange Albertini.) > or at least over multiple (sub)strings in a single TXT RR. More plausible, if the length bytes in the TXT RDATA of the two colliding messages can be made to add up to the same total. (They don't have to coincide...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: Northwest 4 to 6, backing south 6 to gale 8, perhaps severe gale 9 later. Slight or moderate, becoming rough or very rough. Occasional rain later. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: help with a resolution
Warren Kumari wrote: > Ok, I see the concern now, and *do* feel foolish for not getting it sooner... I have learned a lot this week :-) I have been using DNSSEC for about 10 years and only this week have I had to care about the details of how an RRSIG is constructed. I saw the MD5 chosen-prefix collision certificate in 2008 and I thought, wow that's cool, but I didn't sweat the details. I saw the commentary from X.509 and TLS people about how shaky SHA-1 was in 2015, and I didn't examine the implications for DNSSEC. Same again after the SHA-1 collision in 2017. I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't think about the consequences. As soon as I saw the SHAmbles announcement I realised what it actually meant and that DNSSEC was in serious trouble. It took me a couple of afternoons to write the blog article. The second half and the more tricky cases owe a lot to discussions with Viktor. I, too, feel foolish for not getting it sooner - I can't complain there weren't enough clues! https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Mainly northwesterly 3 to 5, backing southerly 4 to 6, increasing 7 to severe gale 9 later. Smooth or slight at first in Firth of Clyde, otherwise moderate or rough. Showers, rain later. Good, occasionally poor later. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] SHA-1 chosen-prefix collisions
On Thu, Jan 09, 2020 at 06:02:43PM -0500, Warren Kumari wrote: > Somehow, even though I read (and re-read) the "chosen-prefix" part of > "chosen-prefix collision", for some reason when it came to DNSSEC I > felt that the *attacker* needed to be the one choosing the prefix > (because of the concatenation of the RRSIG RDATA and the RRSET) > > I started reading Tony Finch's excellent blog post ( > https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html ), all the > while shaking my head in disagreement... and then read the "sort > after the innocuous prefix" phrase and the penny finally dropped. Apologies for failing repeatedly to explain the issue clearly enough. For a chosen-prefix collision against hash a function H, the attacker's task is: given two *arbitrary* message prefixes P and P' to find two message suffixes S and S' such that: H(P || S) == H( P' || S') (where '||' means concatenation). A chosen-prefix attack is a powerful tool, a message with metadata P and payload S can now have the same digest as a message with completely different, chosen by the attacker metadata P' and payload S' (though ultimately the combined message lengths need to be the same). I should also admit, that I did make a mistake in reporting 20 bytes as the length of the "blocks" they used to construct the collision suffixes. I should have remembered that "compression functions" such as SHA-1 have a larger internal block size (64 bytes in the case of SHA-1). So the present attack requires a suffix of ~640 rather than ~200 bytes. The implications of the longer suffix requirement are not yet clear, waiting to hear back from the authors of the paper. Perhaps it is possible to split the suffix over multiple RRs, or at least over multiple (sub)strings in a single TXT RR. The longer suffix could for now rule out misuse of TXT records since each chunk of a TXT record is at most 255 bytes. Regardless, various other RR types do make it possible to "smuggle" longer payloads into DNS zones. And indeed if rdata validation is missing or sloppy and the attack is authorised to publish any data of his choice for "his" node (say "kittens.example.net"), he can always ask the zone operator to publish: kittens.example.net. IN TYPE12345 \# 640 ( <1280 hex nibbles> ) This is especially true in the case when the attacker is the registrant for the entire zone, but the DNS operator uses the same ZSK for multiple unrelated domains (which is the case for ~220k domains that share their keys with other customers of the same provider). If we're not yet all sick of this topic, I'll post any relevant updates from the authors of the paper. It seems they were not familiar with SHA-1 in the context of DNSSEC, but may now take a closer look. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: help with a resolution
[ Top-post ] ... and once again I understand the "Do not disagree with the Dukhovni, for you will end up feeling foolish..." truism... Somehow, even though I read (and re-read) the "chosen-prefix" part of "chosen-prefix collision", for some reason when it came to DNSSEC I felt that the *attacker* needed to be the one choosing the prefix (because of the concatenation of the RRSIG RDATA and the RRSET) I started reading Tony Finch's excellent blog post ( https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html ), all the while shaking my head in disagreement... and then read the "sort after the innocuous prefix" phrase and the penny finally dropped. Ok, I see the concern now, and *do* feel foolish for not getting it sooner... Shame cube, W On Wed, Jan 8, 2020 at 7:12 PM Warren Kumari wrote: > > On Wed, Jan 8, 2020 at 6:47 PM Viktor Dukhovni wrote: > > > > On Wed, Jan 08, 2020 at 06:00:06PM -0500, Viktor Dukhovni wrote: > > > > > Well, there are various services where indeed the zone administrator signs > > > records from authenticated, but otherwise untrusted customers, provided > > > the RR owner is associated with the customer. > > > > > > For example, the .DE zone (which uses algorithm 8, so not subject to > > > any SHA-1 issues) allows registrants that only need a handful of > > > DNS records to have those records published directly in the .DE > > > zone, without delegation. > > > > > > Other zones may make similar arrangements. > > > > Or more simply, when Let's Encrypt, or some cloud provider asks you to > > publish a TXT RR in your zone to prove zone control, how sure are you > > that's not a hash collision in disguise? > > It **could** be, but I'm still failing to see how they could use this > -- LE asks me to publish: > > _acme-challenge.example.com 600 IN TXT "I_like_Cheese" in my zone, and > I sign it. > > LE asks Bob to publish: > _acme-challenge.example.net 600 IN TXT "I_like_Natchos" in his zone, > and Bob signs it. > > I_like_Cheese and I_like_Natchos hash to the same output - 0x12345, > and both Bob and I have signed it (actually, what get signed is the > concatenation of the RRSIG RDATA and the RRSET, and so the LE doesn't > really get to choose the prefix, but lets ignore that). > > Now the attacker (LE) has gotten both Bob and I to sign this, and when > someone queries for _acme-challenge.example.com LE could inject > "I_like_Natchos" instead of "I_like_Cheese" -- but both of these > strings were messages under the attackers control anyway. Yes, I feel > that there *might* be a way that this can be pivoted into something > useful to the attacker, but I'm still not seeing it... > > W > > > > -- > > Viktor. > > ___ > > dns-operations mailing list > > dns-operations@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 -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google DNS Admin
Hi Daniel - You may want to check out Steve Gibbard’s very handy wrapper around the RIPE Atlas toolkit which allows for traceroute and DNS lookups from thousands of points around the world: https://www.globaltraceroute.com/ JT On 8 Jan 2020, at 16:54, Daniel Corbe wrote: Thank you for this. Is there any chance at all I can get you to do a traceroute to 185.203.205.10 and 2a0c:d2c4::53:5:7335 And if you have access to a bgp speaking peer, show ip bgp 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32 (or whatever the equivalent commands are for your NOS). Best, Daniel On Wed, Jan 8, 2020 at 9:57 AM Tony Finch wrote: Daniel Corbe wrote: Every well-known recursor is returning valid results for as57335.net except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting down to the root of the issue. Maybe connectivity problems? I can't get to any of the nameservers from 131.111.0.0/16 or 2a05:b400::/32. DNSviz can see the domain OK but zonemaster cannot. https://dnsviz.net/d/as57335.net/dnssec/ https://zonemaster.net/result/0e70c5e9893a0ce8 Tony. -- f.anthony.n.finchhttp://dotat.at/ people involved in running their communities ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- John Todd - jt...@quad9.net - +1-415-831-3123 Executive Director - Quad9 Recursive Resolver ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
