Re: [dns-operations] [Ext] Re: help with a resolution
On Fri, Jan 10, 2020 at 08:08:51AM -0500, Matthew Pounsett wrote: > > 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. > > What are the implications for NSEC3, given that both (current) algorithm > numbers rely on SHA-1? None whatsoever. The use of SHA-1 in NSEC3 is not security relevant. It is used to deter casual zone walking and nothing else. Any digest algorithm that requires some computational effort to perform dictionary attacks to recover the guessable input domain names is pretty much as good as any other. SHA-1 has many advantages: 1. It is already implemented and deployed (this basically ends the discussion) 2. It is compact enough to fit in a base32 encoded label. There is no need to replace SHA-1 in NSEC3, and doing so would do more harm than good (another decade of deployment uncertainty). -- 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
Matthew Pounsett wrote: > > What are the implications for NSEC3, given that both (current) algorithm > numbers rely on SHA-1? In NSEC3, SHA-1 is used for hashing domain names, which do not have enough space to fit a collision attack. Even so, RFC 5155 has a lot of contingency options for dealing with collisions; for instance, if a zone update adds a name that collides, the NSEC3 chain can be re-generated using a different salt. Tony. -- f.anthony.n.finchhttp://dotat.at/ oppose all forms of entrenched privilege and inequality ___ 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
On Fri, 10 Jan 2020 at 08:08, Matthew Pounsett wrote: > > > On Thu, 9 Jan 2020 at 20:47, Tony Finch wrote: > >> 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. >> >> > What are the implications for NSEC3, given that both (current) algorithm > numbers rely on SHA-1? > Nevermind.. a split thread meant the answer to my question was further down in my inbox. So an attack against a TLD using NSEC3 is logistically difficult, but it's not impossible.. so I guess we'd better get on with standardizing RSASHA256-NSEC3-SHA256. There are a LOT of TLDs—particularly CC's—using algo 7. ___ 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
On Thu, 9 Jan 2020 at 20:47, Tony Finch wrote: > 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. > > What are the implications for NSEC3, given that both (current) algorithm numbers rely on SHA-1? ___ 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
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] [Ext] Re: help with a resolution
On Wed, Jan 08, 2020 at 07:12:09PM -0500, Warren Kumari wrote: > > 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. But secretly, "I_like_Cheese" (FWIW, much too short for the current attack) the signature of that RRset is the same as the signature of a mutated DNSKEY RRset for "example.com". > LE asks Bob to publish: > _acme-challenge.example.net 600 IN TXT "I_like_Natchos" in his zone, > and Bob signs it. No, we can stop there that's not the attack, because that would not be signed under the same key, BUT this raises a related issue I had not considered, there are many hosting operators that sign multiple customer domains under the same key. If any one of those domains publishes a hostile TXT RR, that RR can be used to forge records in other zones that re-use the key! For example, the same *.net operated algo 7 ZSK signs ~148k customer domains (I am a bit hesitant to publish the operator name just at the moment). [ I sent you an invite on Hangouts, feel free to ping off-list. ] -- 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
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 ___ 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
On Jan 8, 2020, at 3:36 PM, Viktor Dukhovni wrote: > > 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? > OK, that's an excellent example of a common situation where such a signature might be caused to occur. Thanks! --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ 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
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? -- 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
On Wed, Jan 08, 2020 at 10:45:54PM +, Paul Hoffman wrote: > However, in DNSSEC, what is the scenario where "I" can get "you" to sign an > RRset? Aren't RRsets all signed by their owner, the creator of the RRset? If > I'm a signer and I'm willing to sign something that I didn't create, I > already have a lot of problems already. 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. -- 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
On Jan 8, 2020, at 2:10 PM, Viktor Dukhovni wrote: > If I can get you to sign A, you may > be inadvertently also signing B. This is the crux of your argument, and the crux of every attack that leverages hash collisions. If "I" can get "you" to sign something without adding any randomness to the beginning of the signature, then you could be signing something unintended because there are multiple items with the same hash value. (To be clear: RFC 3110 doesn't add any signer randomness to the signatures, which it could have.) However, in DNSSEC, what is the scenario where "I" can get "you" to sign an RRset? Aren't RRsets all signed by their owner, the creator of the RRset? If I'm a signer and I'm willing to sign something that I didn't create, I already have a lot of problems already. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ 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
On Wed, Jan 08, 2020 at 09:00:26PM +, Paul Hoffman wrote: > I'm with Warren: I don't see how the chosen-prefix collision affects DNSSEC. And yet it does, because signatures over a benign RRset A, may also be valid signatures for a malicious RRset B, where A and B don't share the same (owner, type, class) triple. If I can get you to sign A, you may be inadvertently also signing B. > > Well, there's your mistake, because with "chosen-prefix" attacks, the second > > RRset being signed need not have the same owner or type, thus a weird TXT > > RRset for a benign owner may SHA-1 hash to the same value as an attacker > > selected DNSKEY RRset for the zone (that includes a KSK matching the DS > > RR, but also keys controlled by the attacker). > > True, but irrelevant. An attacker can create a DNSKEY RRset for something > they don't control already today. Not as a signed RRset with a key they created for my zone, where I was only willing to sign a TXT record for a node they they are authorized to control (authenticted admin control over a subtree of a zone, without there being a delegation cut). For now, it looks like DS RRsets are safe, but that could change as attacks improve to the point of making it possible to create an attack with a 256-bit suffix (rather than 9 to 10 SHA-1 blocks or 1440--1600 bits). > > No, they could do much worse, they could make a TXT RRset, that > > secretly matches a DNSKEY RRset (at least for a given signature > > period, the collision will break once the RRset is resigned with > > a different inception/expiration interval). > > A DNSKEY RR is only useful if there is a matching DS in the parent > zone that matches the DNSKEY. In your scenario, that would require a > preimage attack. No, that's false. The DNSKEY RRset in question would be for the zone apex, and match one of the zone's KSKs, but carry other keys of the attacker's choice. -- 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
I'm with Warren: I don't see how the chosen-prefix collision affects DNSSEC. On Jan 8, 2020, at 12:18 PM, Viktor Dukhovni wrote: > > On Wed, Jan 08, 2020 at 02:53:42PM -0500, Warren Kumari wrote: > >> Can someone please explain to me in baby words how the SHA-1 issue affects >> DNSSEC? [...] but SHA-1 is still 2nd-preimage resistant - given the hash >> a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find another >> message which hashes to this. > > That's still true, but the attack leverages chosen-prefix collisions against > signatures, in which the tail of the data signed is controlled by an attacker. > Not 2nd pre-image attacks on a hash of a trusted message. > >> So, I *could* see an attacker being able to make 2 records or keys >> which have the same hash -- but, meh, that's not actually useful to >> them. > > Well, there's your mistake, because with "chosen-prefix" attacks, the second > RRset being signed need not have the same owner or type, thus a weird TXT > RRset for a benign owner may SHA-1 hash to the same value as an attacker > selected DNSKEY RRset for the zone (that includes a KSK matching the DS > RR, but also keys controlled by the attacker). True, but irrelevant. An attacker can create a DNSKEY RRset for something they don't control already today. > >> eg: The DS for dns-oarc.net is: 20899 8 1 >> 6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a >> new key which hashes to this. > > Yes, that's why I decided to follow up on Mukun'd post. Digest type > 1 (SHA-1) in DS RRs is mostly harmless, though again not recommended. > >> They could in theory make 2 DNSKEYs >> which have the same hash (although, because of the format of DNSKEYs I >> don't think they can do this in practice), > > No, they could do much worse, they could make a TXT RRset, that > secretly matches a DNSKEY RRset (at least for a given signature > period, the collision will break once the RRset is resigned with > a different inception/expiration interval). A DNSKEY RR is only useful if there is a matching DS in the parent zone that matches the DNSKEY. In your scenario, that would require a preimage attack. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
