RE: A Deep Dive on the Recent Widespread DNS Hijacking
You might have missed reading the very article you cite. "Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. .... Aside from that, DNSSEC saved us from being really, thoroughly owned.” Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-11.2 "It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.” I am not sure how many of the domains listed as being hijacked are DNSSEC signed, but it seems if they were, and had a reasonable long TTL on a DS record at their parent, many if not most of these could have been prevented/detected. ICANN seems to think that is the case: ICANN Calls for Full DNSSEC Deployment https://www.icann.org/news/announcement-2019-02-22-en Of course, DNSSEC is often blamed for not protecting those who did not deploy/use it. Not sure what can be said about that line of reasoning. Dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST ============ Date: Sat, 23 Feb 2019 12:13:41 -0700 From: "Keith Medcalf" <kmedcalf@dessus.com> To: "nanog@nanog.org" <nanog@nanog.org> Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> Content-Type: text/plain; charset="us-ascii" On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: >Very good article, very detailed, with a lot of technical precisions, >about the recent domain name hijackings (not using the DNS, just good >old hijackings at registrar or hoster). >https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns... So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. (Sounds like an NSA operation to me -- and the targets perfectly match those that the NSA would choose -- plus some good old misdirection just for the jollies of it) The second takeaway being that DNSSEC is useless in preventing such an occurrence because the script kiddies can merely turn it off at the same time as they redirect DNS. However, having DNSSEC can protect you from incompetent script-kiddies. It can also give you a false sense of security. Did I miss anything? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Obviously none of y'all read the report. Here is the relevant quote: """" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-----Original Message----- From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] Sent: Sunday, 24 February, 2019 15:38 To: nanog@nanog.org Cc: kmedcalf@dessus.com Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
You might have missed reading the very article you cite.
"Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. .... Aside from that, DNSSEC saved us from being really, thoroughly owned.”
Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme- 12#section-11.2
"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.”
I am not sure how many of the domains listed as being hijacked are DNSSEC signed, but it seems if they were, and had a reasonable long TTL on a DS record at their parent, many if not most of these could have been prevented/detected.
ICANN seems to think that is the case: ICANN Calls for Full DNSSEC Deployment https://www.icann.org/news/announcement-2019-02-22-en
Of course, DNSSEC is often blamed for not protecting those who did not deploy/use it. Not sure what can be said about that line of reasoning.
Dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST
============ Date: Sat, 23 Feb 2019 12:13:41 -0700 From: "Keith Medcalf" <kmedcalf@dessus.com> To: "nanog@nanog.org" <nanog@nanog.org> Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> Content-Type: text/plain; charset="us-ascii"
On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote:
Very good article, very detailed, with a lot of technical precisions, about the recent domain name hijackings (not using the DNS, just good old hijackings at registrar or hoster).
https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent- widespread-dns-hijacking-attacks/
So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. (Sounds like an NSA operation to me -- and the targets perfectly match those that the NSA would choose -- plus some good old misdirection just for the jollies of it)
The second takeaway being that DNSSEC is useless in preventing such an occurrence because the script kiddies can merely turn it off at the same time as they redirect DNS. However, having DNSSEC can protect you from incompetent script-kiddies. It can also give you a false sense of security.
Did I miss anything?
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Keith, You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS. If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative. In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges. Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea. The paper below mentioned in a NANOG talk last week gives food for thought. Bamboozling Certificate Authorities with BGP https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee dougm -- DougM at NIST On 2/24/19, 8:52 PM, "Keith Medcalf" <kmedcalf@dessus.com> wrote: Obviously none of y'all read the report. Here is the relevant quote: """" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog@nanog.org >Cc: kmedcalf@dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked >that attack, but that it managed to snare email credentials for two >employees who were traveling at the time. >.... >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.... >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.o... > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > >============ > Date: Sat, 23 Feb 2019 12:13:41 -0700 > From: "Keith Medcalf" <kmedcalf@dessus.com> > To: "nanog@nanog.org" <nanog@nanog.org> > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > >Very good article, very detailed, with a lot of technical >precisions, > >about the recent domain name hijackings (not using the DNS, just >good > >old hijackings at registrar or hoster). > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecu... >widespread-dns-hijacking-attacks/ > > So in other words this was just an old school script kiddie >taking advantage of DNS registrars, the only difference being this >was a whole whack of script kiddies acting in concert directed by a >not-quite-so-stupid script kiddie, with some "modernz" thrown in for >good measure. (Sounds like an NSA operation to me -- and the targets >perfectly match those that the NSA would choose -- plus some good old >misdirection just for the jollies of it) > > The second takeaway being that DNSSEC is useless in preventing >such an occurrence because the script kiddies can merely turn it off >at the same time as they redirect DNS. However, having DNSSEC can >protect you from incompetent script-kiddies. It can also give you a >false sense of security. > > Did I miss anything? > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > >
I just checked Bing.com Google.com Amazon.com Facebook.com Netflix.com Twitter.com Chase.com Coinbase.com None of them have dnssec signed domains. They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with. Those FANG companies have the resources to lead the way, but if they are balkiing .... it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool. But, icann is rationally raising the “never waste a good outage” to advance your tired agenda. CB On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) <dougm@nist.gov> wrote:
Keith,
You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.
If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative.
In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries?
Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges.
Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea.
The paper below mentioned in a NANOG talk last week gives food for thought.
Bamboozling Certificate Authorities with BGP https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
dougm -- DougM at NIST
On 2/24/19, 8:52 PM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
Obviously none of y'all read the report. Here is the relevant quote:
"""" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address.
While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region.
Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC.
However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers.
Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic.
“Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """
If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ...
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
>-----Original Message----- >From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog@nanog.org >Cc: kmedcalf@dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked >that attack, but that it managed to snare email credentials for two >employees who were traveling at the time. >.... >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.... >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.o... > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > >============ > Date: Sat, 23 Feb 2019 12:13:41 -0700 > From: "Keith Medcalf" <kmedcalf@dessus.com> > To: "nanog@nanog.org" <nanog@nanog.org> > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > >Very good article, very detailed, with a lot of technical >precisions, > >about the recent domain name hijackings (not using the DNS, just >good > >old hijackings at registrar or hoster). > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecu... >widespread-dns-hijacking-attacks/ > > So in other words this was just an old school script kiddie >taking advantage of DNS registrars, the only difference being this >was a whole whack of script kiddies acting in concert directed by a >not-quite-so-stupid script kiddie, with some "modernz" thrown in for >good measure. (Sounds like an NSA operation to me -- and the targets >perfectly match those that the NSA would choose -- plus some good old >misdirection just for the jollies of it) > > The second takeaway being that DNSSEC is useless in preventing >such an occurrence because the script kiddies can merely turn it off >at the same time as they redirect DNS. However, having DNSSEC can >protect you from incompetent script-kiddies. It can also give you a >false sense of security. > > Did I miss anything? > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > >
Google has been validating on 8.8.8.8 for years now though they only properly enabled EDNS for Google.com on Jan 10, 2019. Prior to that you needed to include a EDNS ECS option to get a EDNS response. They also DNSSEC sign some of their zones. https://developers.google.com/speed/public-dns/faq
On 25 Feb 2019, at 3:06 pm, Ca By <cb.list6@gmail.com> wrote:
I just checked
Bing.com Google.com Amazon.com Facebook.com Netflix.com Twitter.com Chase.com Coinbase.com
None of them have dnssec signed domains.
They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with.
Those FANG companies have the resources to lead the way, but if they are balkiing .... it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool.
But, icann is rationally raising the “never waste a good outage” to advance your tired agenda.
CB
On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) <dougm@nist.gov> wrote: Keith,
You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.
If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative.
In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries?
Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges.
Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea.
The paper below mentioned in a NANOG talk last week gives food for thought.
Bamboozling Certificate Authorities with BGP https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
dougm -- DougM at NIST
On 2/24/19, 8:52 PM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
Obviously none of y'all read the report. Here is the relevant quote:
"""" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address.
While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region.
Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC.
However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers.
Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic.
“Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """
If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ...
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
>-----Original Message----- >From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog@nanog.org >Cc: kmedcalf@dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked >that attack, but that it managed to snare email credentials for two >employees who were traveling at the time. >.... >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.... >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.o... > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > >============ > Date: Sat, 23 Feb 2019 12:13:41 -0700 > From: "Keith Medcalf" <kmedcalf@dessus.com> > To: "nanog@nanog.org" <nanog@nanog.org> > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > >Very good article, very detailed, with a lot of technical >precisions, > >about the recent domain name hijackings (not using the DNS, just >good > >old hijackings at registrar or hoster). > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecu... >widespread-dns-hijacking-attacks/ > > So in other words this was just an old school script kiddie >taking advantage of DNS registrars, the only difference being this >was a whole whack of script kiddies acting in concert directed by a >not-quite-so-stupid script kiddie, with some "modernz" thrown in for >good measure. (Sounds like an NSA operation to me -- and the targets >perfectly match those that the NSA would choose -- plus some good old >misdirection just for the jollies of it) > > The second takeaway being that DNSSEC is useless in preventing >such an occurrence because the script kiddies can merely turn it off >at the same time as they redirect DNS. However, having DNSSEC can >protect you from incompetent script-kiddies. It can also give you a >false sense of security. > > Did I miss anything? > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > >
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In article <B7DF0851-C5A3-4366-8ADF-501D1418F9E1@nist.gov> you write:
You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.
As far as I can tell, that's roughly all of them. If you have the credentials to log in and change the NS, you can change or remove the DS, too. As someone else noted, the only reason DNSSEC made any difference was that the script kiddies sometimes forgot to turn it off or install their own DS. If you are actually interested in preventing this stuff, 2FA will be orders of magnitude more effective than messing with DNSSEC. There are certainly threats that DNSSEC addresses, but getting your registrar account pwned isn't one of them. R's, John
On Mon, Feb 25, 2019, 1:30 PM John Levine <johnl@iecc.com> wrote:
You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS.
As far as I can tell, that's roughly all of them. If you have the credentials to log in and change the NS, you can change or remove the DS, too.
And, that wouldn't change in the nearest future, because the concept of "hostile pinning" as it was present with HTTPS Public Key Pinning could also be ported to DNSSEC this way. "Hostile signing"... doesn't that sound scary. -- Töma
dougm> You are right, if you can compromise a registrar that permits dougm> DNSSEC to be disabled (without notification/confirmation to POCs dougm> etc), then you only have a limited period (max of DS TTL) of dougm> protection for those resolvers that have already cached the DS. johnl> As far as I can tell, that's roughly all of them. If you have johnl> the credentials to log in and change the NS, you can change or johnl> remove the DS, too. Yes, though with the 1 day TTL most registries put on DS records, you at least have the chance to notice your DS has changed or been deleted and attempt to recover your registry account. That is somewhat a "locking the barn door" approach, and 2FA and other account security is the best solution. However, we are in a world now where every layer of security we can add is probably a good idea and having a day to notice could be handy. DNSSEC isn't useless but it solves one specific problem, end to end data integrity. It also requires operational cleanliness and attention to detail. We shouldn't make claims about what it can't do; we're much better off getting everyone to understand what it does and doesn't do. And underline what other security best practices they should be following. If someone owns your registry account, you're screwed. And right now, it tends to be the most neglected part of the entire zone ownership world. Let's use this opportunity to help folks lock down their accounts, not muddying the waters with dubious claims.
ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims. Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation.
Hi Paul,
Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation.
Security is only as strong as its weakest link. No single link can be expected to protect the whole chain on its own. Cheers, Sander
On Feb 25, 2019, at 09:25 , Paul Ebersman <list-nanog2@dragon.net> wrote:
ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims.
Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation.
@Paul — I think you meant “registrar account” rather than “registry account” since most domain holders don’t have registry accounts. Registry accounts are primarily held by registrars. If someone owns a registrar’s registry account, then all of their customers (and potentially many many others) are screwed. Owen
One thing to consider with authentication for domain registrar accounts: DO NOT USE 2FA VIA SMS. This is a known attack vector that's been used by SS7 hijacking techniques for several well documented thefts of cryptocurrency, from people who were known to be holding large amounts of (bitcoin, ethereum, whatever) on exchanges which supported 2FA authentication. In some cases there was no SS7 hijacking going on, but rather social engineering of (t-mobile, sprint, verizon, at&t) customer service representatives to get a new SIM card issued for the attack target's phone. tl;dr: ss7 considered harmful On Mon, Feb 25, 2019 at 10:48 AM Owen DeLong <owen@delong.com> wrote:
On Feb 25, 2019, at 09:25 , Paul Ebersman <list-nanog2@dragon.net> wrote:
ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims.
Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation.
@Paul — I think you meant “registrar account” rather than “registry account” since most domain holders don’t have registry accounts. Registry accounts are primarily held by registrars. If someone owns a registrar’s registry account, then all of their customers (and potentially many many others) are screwed.
Owen
ekuhnke> One thing to consider with authentication for domain registrar ekuhnke> accounts: ekuhnke> DO NOT USE 2FA VIA SMS. Yup. This is a good example of what I'm advocating. Just saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make informed decisions of risk/effort/reward tradeoffs. Simplistic suggestions without details or context isn't doing anyone any favors. That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing lousy passwords is better than no password but still not a best practice.
On Mon, 25 Feb 2019 12:14:59 -0700, Paul Ebersman said:
ekuhnke> One thing to consider with authentication for domain registrar ekuhnke> accounts:
ekuhnke> DO NOT USE 2FA VIA SMS.
Yup. This is a good example of what I'm advocating. Just saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make informed decisions of risk/effort/reward tradeoffs. Simplistic suggestions without details or context isn't doing anyone any favors.
That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing lousy passwords is better than no password but still not a best practice.
Feel free to suggest a workable 2FA. Personally, I use a Yubikey where I can. Oath seems to be a reasonable approach for technically minded people, but I'm not sure that it scales well to the people who own the long tail domains in the 40 million .coms. I can get oathtool to behave the way I want, but I'm not sure the owner of joes-bait-tackle-and-gunshop.com will be able to deal with it. Unless you get it down to the SMS "wait for a msg, type in the 6 digit number" level, it's going to be a tough start...
ebersman> Yup. This is a good example of what I'm advocating. Just ebersman> saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't ebersman> sufficient detail to make informed decisions of ebersman> risk/effort/reward tradeoffs. Simplistic suggestions without ebersman> details or context isn't doing anyone any favors. ebersman> That said, even SMS 2FA is better than no 2FA. Barely. Just ebersman> like forcing lousy passwords is better than no password but ebersman> still not a best practice. valdis> Feel free to suggest a workable 2FA. Personally, I use a valdis> Yubikey where I can. Oath seems to be a reasonable approach for valdis> technically minded people, but I'm not sure that it scales well valdis> to the people who own the long tail domains in the 40 million valdis> .coms. I can get oathtool to behave the way I want, but I'm not valdis> sure the owner of joes-bait-tackle-and-gunshop.com will be able valdis> to deal with it. Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's Bait & Tackle Shop probably isn't getting attacked by nation states who can hack SS7, so SMS text might be good enough. And certainly better than just an 8 char plain text password. Risk/attack surface is part of that context I mention. Folks in sensitive jobs will need better protection and hopefully be more capable of using less "user friendly" tech. Folks protecting less and with less geek background should still have some protection but it doesn't need to be nearly as fancy.
On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said:
Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's Bait & Tackle Shop probably isn't getting attacked by nation states who can hack SS7, so SMS text might be good enough. And certainly better than just an 8 char plain text password.
So what registries/registrars are supporting 2FA that's better than SMS? Or since 98% of domain names are Bait&Tackle type, is nobody bothering to support something for the 2% that could use it? Or is there a business opportunity lurking here? :)
Markmonitor runs a registrar popular with fortune 500s that implements additional security steps, and talking to a clued in live human in the loop to modify anything in your domain record. On Mon, Feb 25, 2019, 6:03 PM <valdis.kletnieks@vt.edu> wrote:
On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said:
Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's Bait & Tackle Shop probably isn't getting attacked by nation states who can hack SS7, so SMS text might be good enough. And certainly better than just an 8 char plain text password.
So what registries/registrars are supporting 2FA that's better than SMS? Or since 98% of domain names are Bait&Tackle type, is nobody bothering to support something for the 2% that could use it?
Or is there a business opportunity lurking here? :)
On Mon, Feb 25, 2019 at 8:02 PM <valdis.kletnieks@vt.edu> wrote:
So what registries/registrars are supporting 2FA that's better than SMS? Or since 98% of domain names are Bait&Tackle type, is nobody bothering to support something for the 2% that could use it?
If Joe's Bait and Tackle buys from Namecheap, they can utilize TOTP for their second factor. https://www.namecheap.com/support/knowledgebase/article.aspx/10073/45/how-ca...
In article <24679.1551146531@turing-police.cc.vt.edu> you write:
So what registries/registrars are supporting 2FA that's better than SMS?
Opensrs does TOTP. It's certainly not bulletproof, but it's tied to your actual phone rather than the phone number. (We careful folk put our TOTP keys on a couple of our devices in case the phone dies or gets lost.) It's very easy to implement, it's an IETF open specification, and there are lots of clients that support it. FIDO keys (like Yubikey) also seem OK but I haven't looked at how hard they are to implement.
On Tue, Feb 26, 2019 at 12:14 AM John Levine <johnl@iecc.com> wrote:
In article <24679.1551146531@turing-police.cc.vt.edu> you write:
So what registries/registrars are supporting 2FA that's better than SMS?
Opensrs does TOTP. It's certainly not bulletproof, but it's tied to your actual phone rather than the phone number. (We careful folk put our TOTP keys on a couple of our devices in case the phone dies or gets lost.) It's very easy to implement, it's an IETF open specification, and there are lots of clients that support it.
FIDO keys (like Yubikey) also seem OK but I haven't looked at how hard they are to implement.
https://twofactorauth.org/#domains gives a good view of the domain management landscape regarding 2FA. Rubens
https://twofactorauth.org/#domains gives a good view of the domain management landscape regarding 2FA.
Seems to require the unfettered execution of third-party code ... Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Keith, On Tue, Feb 26, 2019 at 6:00 AM Keith Medcalf <kmedcalf@dessus.com> wrote:
https://twofactorauth.org/#domains gives a good view of the domain management landscape regarding 2FA.
Seems to require the unfettered execution of third-party code ...
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
What are you talking about?! Are you ... trolling? If you don't trust the various (excellent) closed & open-source implementations of TOTP - you can write one yourself. The algorithm & specification are entirely open and free to use: https://tools.ietf.org/html/rfc6238 Using TOTP as 2FA is an excellent and recommended practice, and I am happy to see so many domain registrars support it. Regards, Job
On 2/25/19 9:59 PM, Keith Medcalf wrote:
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code.
On Tue, 26 Feb 2019 08:36:11 -0800, Seth Mattinen said:
On 2/25/19 9:59 PM, Keith Medcalf wrote:
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code.
I seem to recall that the 1983 Turing Award lecture referenced a 1974 pen test of Multics that proved conclusively that level of paranoia isn't sufficient....
On Tue, Feb 26, 2019 at 9:51 AM <valdis.kletnieks@vt.edu> wrote:
On Tue, 26 Feb 2019 08:36:11 -0800, Seth Mattinen said:
On 2/25/19 9:59 PM, Keith Medcalf wrote:
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code.
I seem to recall that the 1983 Turing Award lecture referenced a 1974 pen test of Multics that proved conclusively that level of paranoia isn't sufficient....
Well, the OP was probably just speaking in shorthand. What I'm sure they really meant was after developing your own silicon on your own hardware, and hand assembling your own compiler and linker, and then writing your own drivers for your hardware and building your own operating system, you could easily write your own TOTP implementation on your hardware running on your silicon with your operating system with your compiler and your linker...and then you could be sure. Right? Matt
I did write my own TOTP client. However, why do you assume that I am talking about a TOTP client and not the referred webpage which requires the unfettered execution of third-party (likely malicious) javascript in order to view? Not to mention requiring the use of (also quite possibly malicious) downloaded fonts? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-----Original Message----- From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com@nanog.org] On Behalf Of Seth Mattinen Sent: Tuesday, 26 February, 2019 09:36 To: nanog@nanog.org Subject: Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking
On 2/25/19 9:59 PM, Keith Medcalf wrote:
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code.
On Tue, Feb 26, 2019 at 9:56 PM Keith Medcalf <kmedcalf@dessus.com> wrote:
I did write my own TOTP client. However, why do you assume that I am talking about a TOTP client and not the referred webpage which requires the unfettered execution of third-party (likely malicious) javascript in order to view? Not to mention requiring the use of (also quite possibly malicious) downloaded fonts?
Well, because: 1. the page's <noscript> tag points to the github repo which contains the raw data in a fairly readable form; and 2. the page works fine in Lynx despite the warning.
Okay that was *clearly* a troll. On Tue, Feb 26, 2019 at 10:58 PM Keith Medcalf <kmedcalf@dessus.com> wrote:
I did write my own TOTP client. However, why do you assume that I am talking about a TOTP client and not the referred webpage which requires the unfettered execution of third-party (likely malicious) javascript in order to view? Not to mention requiring the use of (also quite possibly malicious) downloaded fonts?
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-----Original Message----- From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com@nanog.org] On Behalf Of Seth Mattinen Sent: Tuesday, 26 February, 2019 09:36 To: nanog@nanog.org Subject: Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking
On 2/25/19 9:59 PM, Keith Medcalf wrote:
Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity?
Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code.
On Tue, Feb 26, 2019 at 4:05 AM <valdis.kletnieks@vt.edu> wrote:
So what registries/registrars are supporting 2FA that's better than SMS? Or since 98% of domain names are Bait&Tackle type, is nobody bothering to support something for the 2% that could use it?
Gandi does TOTP and CIDR filtering, that is, you can give them list of CIDRs from which login is permissible at all. -- ++ytti
valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> wrote:
Unless you get it down to the SMS "wait for a msg, type in the 6 digit number" level, it's going to be a tough start...
Isn't this what Duo's business is based on? Usable TOTP? See also Google Authenticator, Authy, 1Password, etc. usw. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Southeast Iceland: Southwesterly gale 8 to storm 10, veering westerly 5 to 7 later. High or very high, becoming rough or very rough later. Squally showers. Moderate or poor.
ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims. owen> Paul, I think you meant "registrar account" rather than "registry owen> account" since most domain holders don't have registry accounts. Yes. I please ICANN jargon dyslexia brought on by excess blood in my caffeine stream. ;)
Speaking of registrars vs registries - I've noticed some companies have become their own registrar to improve their domain security (Cloudflare, Google, etc.). Is that a feasible path for smaller organizations? How much risk does that mitigate? It seems like it gives the organization control over more of the domain registration, which allows them to manage things better than a typical registrar might. But credentials can be compromised in either case. Does anyone have any experience with that setup? On Mon, Feb 25, 2019, 1:49 PM Owen DeLong <owen@delong.com> wrote:
On Feb 25, 2019, at 09:25 , Paul Ebersman <list-nanog2@dragon.net> wrote:
ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims.
Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation.
@Paul — I think you meant “registrar account” rather than “registry account” since most domain holders don’t have registry accounts. Registry accounts are primarily held by registrars. If someone owns a registrar’s registry account, then all of their customers (and potentially many many others) are screwed.
Owen
On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) <dougm@nist.gov> wrote: In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries?
We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. -Bill
On 25/02/2019 07:20, Bill Woodcock wrote:
On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) <dougm@nist.gov> wrote: In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo.
-Bill
Bill, Did you have a CAA record defined and if not, why not? -Hank
On Feb 24, 2019, at 22:03, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Did you have a CAA record defined and if not, why not?
If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC). Ask
On 25/02/2019 11:37, Ask Bjørn Hansen wrote:
On Feb 24, 2019, at 22:03, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Did you have a CAA record defined and if not, why not? If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC).
Yes if an attacker pwned the DNS then game over no matter what. I go under the assumption that the attacker was not able to take over the DNS system but rather other things along the way, in which case CAA should be of some assistance. -Hank
Ask
On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote: Did you have a CAA record defined and if not, why not?
It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped. I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system. We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. -Bill
Op 26 feb. 2019, om 10:56 heeft Bill Woodcock <woody@pch.net> het volgende geschreven:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
+1 Sander
Le 2019-02-26 11:04, Sander Steffann a écrit :
Op 26 feb. 2019, om 10:56 heeft Bill Woodcock <woody@pch.net> het volgende geschreven:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
+1 Sander +1 mh
Bill Woodcock <woody@pch.net> writes:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
Sure. Just won't happen as long as there is money left in the CA business. Bjørn
On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock <woody@pch.net> wrote:
On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote: Did you have a CAA record defined and if not, why not?
It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped.
I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system.
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
-Bill
DNS guy says the solution for insecure DNS is... wait for it.... more DNS ...
On Feb 26, 2019, at 2:35 PM, Ca By <cb.list6@gmail.com> wrote:
On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock <woody@pch.net <mailto:woody@pch.net>> wrote:
On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank@efes.iucc.ac.il <mailto:hank@efes.iucc.ac.il>> wrote: Did you have a CAA record defined and if not, why not?
It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped.
I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system.
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
-Bill
DNS guy says the solution for insecure DNS is... wait for it.... more DNS ...
Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the solution for a fundamentally broken trust model is a different system to derive trust. Or do you think Let’s Encrypt/Comodo increase trust? Regards, -drc
On Tue, Feb 26, 2019 at 6:25 AM David Conrad <drc@virtualized.org> wrote:
On Feb 26, 2019, at 2:35 PM, Ca By <cb.list6@gmail.com> wrote:
On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock <woody@pch.net> wrote:
On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote: Did you have a CAA record defined and if not, why not?
It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped.
I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system.
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
-Bill
DNS guy says the solution for insecure DNS is... wait for it.... more DNS ...
Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the solution for a fundamentally broken trust model is a different system to derive trust.
Or do you think Let’s Encrypt/Comodo increase trust?
The trust issue has not yet been solved on the internet. Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers. Using DANE to verify multiple layers is interesting, but the web folks aren’t playing so it won’t go anywhere. Right? Google, Wechat, FB, msft, and Apple aren’t coming along. Since you mentioned Let’s Encrypt, they have reduced plaint text, which is great. But trust is a harder issue. For example, Symantec has lost trust. But only after repeated bad actions.
Regards, -drc
In article <CAD6AjGTBNZ8wTv6Y1KgTvNaW6Zi87RLprQK2Lg=d0evK8ot7=g@mail.gmail.com> you write:
Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers.
The models are different. If I want to compromise your DNS I need to attack your specific registrar. If I want a bogus cert, any of the thousand CAs in my browser will do.
On Feb 26, 2019, at 8:12 AM, John Levine <johnl@iecc.com> wrote:
In article <CAD6AjGTBNZ8wTv6Y1KgTvNaW6Zi87RLprQK2Lg=d0evK8ot7=g@mail.gmail.com> you write:
Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers.
The models are different. If I want to compromise your DNS I need to attack your specific registrar. If I want a bogus cert, any of the thousand CAs in my browser will do.
Exactly. And if you’re an organization that has money and pays attention to DNS and security, you can get yourself a TLD, and be your own registry, at which point you only need to worry about the security of the root zone. -Bill
On 26 Feb 2019, at 21:58, Bill Woodcock <woody@pch.net> wrote:
On Feb 26, 2019, at 8:12 AM, John Levine <johnl@iecc.com> wrote:
In article <CAD6AjGTBNZ8wTv6Y1KgTvNaW6Zi87RLprQK2Lg=d0evK8ot7=g@mail.gmail.com> you write:
Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers.
The models are different. If I want to compromise your DNS I need to attack your specific registrar. If I want a bogus cert, any of the thousand CAs in my browser will do.
Exactly. And if you’re an organization that has money and pays attention to DNS and security, you can get yourself a TLD, and be your own registry, at which point you only need to worry about the security of the root zone.
Interesting. Never thought of new TLD from this angle :) -- Nico
On Feb 26, 2019, at 1:25 PM, Nico Cartron <nicolas@ncartron.org> wrote:
On 26 Feb 2019, at 21:58, Bill Woodcock <woody@pch.net> wrote:
On Feb 26, 2019, at 8:12 AM, John Levine <johnl@iecc.com> wrote:
In article <CAD6AjGTBNZ8wTv6Y1KgTvNaW6Zi87RLprQK2Lg=d0evK8ot7=g@mail.gmail.com> you write:
Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers.
The models are different. If I want to compromise your DNS I need to attack your specific registrar. If I want a bogus cert, any of the thousand CAs in my browser will do.
Exactly. And if you’re an organization that has money and pays attention to DNS and security, you can get yourself a TLD, and be your own registry, at which point you only need to worry about the security of the root zone.
Interesting. Never thought of new TLD from this angle :)
That’s the main reason for having a brand TLD at this point, from my point of view. It’s the reason I’d get one in a heartbeat, if I could afford the fees. -Bill
In article <3FD86D54-7FE4-4E1D-8C8D-A4D79F030DAD@pch.net> you write:
That’s the main reason for having a brand TLD at this point, from my point of view. It’s the reason I’d get one in a heartbeat, if I could afford the fees.
Well, actually, you can't get one. The 2013 round is still working out some issues, e.g. two companies both named Merck who hate each other want .MERCK and neither will budge. There may be another round but given the stupendous non-success of the current round, I wouldn't hold my breath. Also, with only one exception, all of the brand TLDs are in fact run by a handful of of familiar back end services. (The exception is a phone company in the Philippines that rolled their own, pretty marginally.) PCH presumably has the infrastructure to run one, but you're really just as well off becoming a registrar and managing your 2LDs in well run TLDs. You can do that now, it's a lot cheaper.
On February 26, 2019 at 20:45 johnl@iecc.com (John Levine) wrote:
In article <3FD86D54-7FE4-4E1D-8C8D-A4D79F030DAD@pch.net> you write:
That’s the main reason for having a brand TLD at this point, from my point of view. It’s the reason I’d get one in a heartbeat, if I could afford the fees.
Well, actually, you can't get one. The 2013 round is still working out some issues, e.g. two companies both named Merck who hate each other want .MERCK and neither will budge. There may be another round but given the stupendous non-success of the current round, I wouldn't hold my breath.
Yeah well ICANN might've done something about string collisions and trademarks, a 200+ year old problem the rest of the world has worked out some rules on like the 40+ product categories WIPO uses (tho those two Merck companies are an unusual problem due to historical reasons.) But noooo, they made it worse, or not any better, and instead turned TLDs into something resembling "Pro Wrestling" with all the chair throwing and phony chokeholds that implies. (remarks certainly not aimed at John, just venting.)
Also, with only one exception, all of the brand TLDs are in fact run by a handful of of familiar back end services. (The exception is a phone company in the Philippines that rolled their own, pretty marginally.) PCH presumably has the infrastructure to run one, but you're really just as well off becoming a registrar and managing your 2LDs in well run TLDs. You can do that now, it's a lot cheaper.
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On Feb 26, 2019, at 5:35 AM, Ca By <cb.list6@gmail.com> wrote: DNS guy says the solution for insecure DNS…
I am not a DNS guy. I’m a routing guy who became a routing-economics guy as my hair got pointier. Stephane and Allison and Bert and Olafur are DNS people, to pick a few examples. And I believe that, yes, DNS people believe that the solution to insecurity in the DNS is to replace insecure portions of the DNS with more secure improvements to the DNS. -Bill
In article <B68C84D4-9D1A-4303-94CA-59CEBFB6B934@pch.net> you write:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
What's the DANE version of a green-bar cert?
On 27/2/19 3:10 am, John Levine wrote:
In article <B68C84D4-9D1A-4303-94CA-59CEBFB6B934@pch.net> you write:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
What's the DANE version of a green-bar cert?
You mean the EV certificates that most browsers are removing the distinction of, removing their only real justification for existing? https://www.troyhunt.com/extended-validation-certificates-are-dead/ Not that they were ever actually widely used. https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing-lets-e...
On 2/26/2019 11:10 AM, John Levine wrote:
In article <B68C84D4-9D1A-4303-94CA-59CEBFB6B934@pch.net> you write:
We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids.
What's the DANE version of a green-bar cert?
At one point, there was the DNSSEC/TLSA validator plug-in for browsers. I had used it and it worked quite well, displaying a green key for valid DANE. https://www.dnssec-validator.cz/ Unfortunately, Firefox's API change, circa version 57, was the start of browser changes that halted the project. I'd really like to see similar functionality return, not as a plug-in, but as a part of the base browser. === End of Support Tue 16 October 2018 After struggling and failing to implement the DNSSEC/TLSA Validator extension for Firefox Quantum (57+) we've decided to stop the development and support of the extension. Firefox 56 was the last version which provided necessary APIs that enabled the DNSSEC/TLSA Validator to check DNS records and certificates … ===
On Wed, Feb 27, 2019, 11:45 PM Mike via NANOG <nanog@nanog.org> wrote:
On 2/26/2019 11:10 AM, John Levine wrote: At one point, there was the DNSSEC/TLSA validator plug-in for browsers.
I'd really like to see similar functionality return, not as a plug-in, but as a part of the base browser.
Nah, you know, that won't happen any time soon. Mozilla is busy doing other, more important things, like streaming all of the users' DNS queries to Cloudflare, etc. The plain old security doesn't count anymore. -- Töma
Nah, you know, that won't happen any time soon. Mozilla is busy doing other, more important things, like streaming all of the users' DNS queries to Cloudflare, etc. The plain old security doesn't count anymore.
-- Töma
This was sort of discussed awhile ago: Adam Langley: https://www.imperialviolet.org/2015/01/17/notdane.html Dan York: https://www.internetsociety.org/blog/2012/01/what-is-the-correct-user-experi... I don't totally agree with it all, but at least it's been tested.
Subject: RE: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: Wed, Feb 27, 2019 at 10:17:22AM -0500 Quoting Eric Tykwinski (eric-list@truenet.com):
Nah, you know, that won't happen any time soon. Mozilla is busy doing other, more important things, like streaming all of the users' DNS queries to Cloudflare, etc. The plain old security doesn't count anymore.
-- Töma
This was sort of discussed awhile ago: Adam Langley: https://www.imperialviolet.org/2015/01/17/notdane.html
Calling TXT or DANE non-standard is a remarkable statement. Smells of the deeply flawed reasoning that brought us the festering pile of defaitism that is RFC 7208.[0] As I wrote a few messages upthread, the user can not expect the network to be trustworthy, and still, we who run the network would very much like their business. So, what we must constantly strive for is maximum transparency, carrying as much of the Internet experienc, good or bad, to the end user. Or, more terse: "Middleboxes are bad for you." -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I demand IMPUNITY! [0] This document tries to deprecate RRTYPE 99 for SPF. By stating that only TXT records can be trusted. Apparently, it is possible to decide on the fly which RRtypes are possible to query for, depending on the argument.
In article <20190227161327.GA27527@besserwisser.org> you write:
that is RFC 7208.[0]
[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that only TXT records can be trusted. ...
This must be a very different RFC 7208 from the one that the IETF published. The IETF one says that nobody used type 99, and some of the few implementations we saw were broken, so we deprecated it.
Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: Wed, Feb 27, 2019 at 01:07:09PM -0500 Quoting John Levine (johnl@iecc.com):
In article <20190227161327.GA27527@besserwisser.org> you write:
that is RFC 7208.[0]
[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that only TXT records can be trusted. ...
This must be a very different RFC 7208 from the one that the IETF published.
The IETF one says that nobody used type 99, and some of the few implementations we saw were broken, so we deprecated it.
We will never agree on that. Because I think you were, and are, wrong. Mostly out of eagerness and lack of patience. I'm fairly certain you think I have no idea what I'm talking about. But, to rehash, a little less subtle: My point was that the general state of criminal ignorance about the finer nuances of DNS is so wide spread that around 2038 we'll have an abstraction layer entirely built out of mile-long CNAME chains, because nobody remembers any other record type. CNAMEs we tried to forget too, replacing them with something out of the olde annals of Compuserve, but since the golden standard of resiliency and load balancing is a chain of them pointing into a bookstore's spare servers, we really can't do without them. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ... FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK STUDIES, SOCIOBIOLOGY! ... Are there any QUESTIONS??
On 28 Feb 2019, at 7:28 am, Måns Nilsson <mansaxel@besserwisser.org> wrote:
Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: Wed, Feb 27, 2019 at 01:07:09PM -0500 Quoting John Levine (johnl@iecc.com):
In article <20190227161327.GA27527@besserwisser.org> you write:
that is RFC 7208.[0]
[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that only TXT records can be trusted. ...
This must be a very different RFC 7208 from the one that the IETF published.
The IETF one says that nobody used type 99, and some of the few implementations we saw were broken, so we deprecated it.
We will never agree on that. Because I think you were, and are, wrong. Mostly out of eagerness and lack of patience.
Agreed. Additionally it suddenly went from something being done along with a experiment to being “a experiment on can you transition to a new type”. The transition to type99 was well underway. The libraries that supported it where being deployed. New MTAs where using using them. Type99 was being published. There was BS about not interoperating with old libraries that only looked for TXT records. The only response to that should have been “doh, go update the code” and maybe set a date for stopping falling back to TXT.
I'm fairly certain you think I have no idea what I'm talking about. But, to rehash, a little less subtle:
My point was that the general state of criminal ignorance about the finer nuances of DNS is so wide spread that around 2038 we'll have an abstraction layer entirely built out of mile-long CNAME chains, because nobody remembers any other record type. CNAMEs we tried to forget too, replacing them with something out of the olde annals of Compuserve, but since the golden standard of resiliency and load balancing is a chain of them pointing into a bookstore's spare servers, we really can't do without them.
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ... FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK STUDIES, SOCIOBIOLOGY! ... Are there any QUESTIONS??
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 28 Feb 2019, Mark Andrews wrote:
Agreed. Additionally it suddenly went from something being done along with a experiment to being “a experiment on can you transition to a new type”. The transition to type99 was well underway. ...
No, really, we had numbers. Approximately nobody was using it, and of the few that were, they were querying just one or just the other and getting wrong results thereby. In general I completely agree that new applications should have new rrtypes. That's why I wrote my extension language, to help add new types to the provisioning crudware that is the actual blocking factor on new types. (The actual servers are all updated pretty quickly.) But trying to retrofit a new type to an application that was already (albeit unwisely) using TXT was a losing battle. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 28 Feb 2019, at 9:03 am, John R. Levine <johnl@iecc.com> wrote:
On Thu, 28 Feb 2019, Mark Andrews wrote:
Agreed. Additionally it suddenly went from something being done along with a experiment to being “a experiment on can you transition to a new type”. The transition to type99 was well underway. ...
No, really, we had numbers. Approximately nobody was using it, and of the few that were, they were querying just one or just the other and getting wrong results thereby.
In general I completely agree that new applications should have new rrtypes. That's why I wrote my extension language, to help add new types to the provisioning crudware that is the actual blocking factor on new types. (The actual servers are all updated pretty quickly.) But trying to retrofit a new type to an application that was already (albeit unwisely) using TXT was a losing battle.
Actually it was a battle that could have easily been won. People just gave up way too soon. Doing stuff like synthesising SPF records from spf style TXT records in the primary server and setting a end date for transition would have worked. We didn’t do that because we didn’t think of it as a battle. We were also blindsided by the decision to treat the change as a experiment in how to migrate types when it was never intended to be. If one was after a fast transition there was lots more that could have been done. DLV transitioned types (we started out with a user assigned type). DNS COOKIE transitioned EDNS code points (started out with a user assigned code point). It’s perfectly do able. SMTP transitioned from A to MX. We no longer publish A records just in case some MTA doesn’t support MX anymore. I can remember having to do that. SPF could have been the same except people were impatient and had unrealistic expectations of how long it would take.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
FYI:
SMTP transitioned from A to MX.
No, it didn't. A surprising number of real mail hosts only publish an A, and I lost the battle to say that MX shouldn't fall back to AAAA. It does.
SPF could have been the same except people were impatient and had unrealistic expectations of how long it would take.
Perhaps it's a generational thing. I'm not very interested in transitions that won't happen until after I'm dead. R's, John
On 28 Feb 2019, at 1:13 pm, John R. Levine <johnl@iecc.com> wrote:
FYI:
SMTP transitioned from A to MX.
No, it didn't. A surprising number of real mail hosts only publish an A, and I lost the battle to say that MX shouldn't fall back to AAAA. It does.
You have missed the point. No one publishes A’s (or AAAA’s) because they think MX is not supported by other MTAs. If one wanted to stop all fallback to A (and AAAA) then there needed to be a RFC that said so and set a date for fallback to no longer be performed.
SPF could have been the same except people were impatient and had unrealistic expectations of how long it would take.
Perhaps it's a generational thing. I'm not very interested in transitions that won't happen until after I'm dead.
It required libraries to be written and for MTAs to use those new libraries. That had started to happen. We had name servers at the end that were synthesising SPF records from TXT records. One just had to wait for the OS refreshes to occur which would got the new MTA’s deployed. That would have mostly been done by now and I’m happy that you are not dead. Unfortunately I can’t prove that this would have been the course of events because it got aborted.
R's, John
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I have proposed many times to just move domain WHOIS data into a new RRTYPE and let whoever owns the domain put in that whatever they want, including (and perhaps most usefully for many) just a URL for further detail. Obviously registries/registrars/ICANN can require and maintain more specific and validatable information from domain owners. I only mean the publicly accessible WHOIS info. It was a reaction to the whole GDPR foofraw: Let each domain owner control their own publicly visible data with some default (like we see now) initialized by registrars on purchase via a new RRTYPE perhaps call it WHOIS tho there are some which might be reused for this purpose, TBD. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 2/27/19 7:02 PM, bzs@theworld.com wrote:
I have proposed many times to just move domain WHOIS data into a new RRTYPE and let whoever owns the domain put in that whatever they want, including (and perhaps most usefully for many) just a URL for further detail.
We kind of have that with RP records. But does anyone do it?
On Wed, 27 Feb 2019 19:59:49 -0800, Seth Mattinen <sethm@rollernet.us> may have written:
We kind of have that with RP records. But does anyone do it?
I used to before various IPAM vendors claimed it was deprecated; I've still got legacy code that queries for it (and the TXT equivalent) as well as the new gooey IPAM thing. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord!
Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: Wed, Feb 27, 2019 at 07:59:49PM -0800 Quoting Seth Mattinen (sethm@rollernet.us):
On 2/27/19 7:02 PM, bzs@theworld.com wrote:
I have proposed many times to just move domain WHOIS data into a new RRTYPE and let whoever owns the domain put in that whatever they want, including (and perhaps most usefully for many) just a URL for further detail.
We kind of have that with RP records. But does anyone do it?
I do, as preserver of strange RRtypes people try to deprecate. dig @primary.se besserwisser.org AXFR | awk '\ /^;/ { next; }; /besserwisser.org/ { types[$4]++; }; END { for ( RRTYPE in types ) { count++; printf "%s\t%d\n", RRTYPE, types[RRTYPE]; }; printf "Total:\t%d rrtypes in zone\n", count; };' NS 5 AAAA 21 DNSKEY 3 SPF 1 A 28 NSEC 62 AFSDB 3 RP 1 MX 2 CNAME 9 SOA 2 RRSIG 147 TXT 6 SSHFP 14 SRV 20 DS 4 Total: 16 rrtypes in zone (Yes, there's a bug there, but the end figure is correct.) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 TONY RANDALL! Is YOUR life a PATIO of FUN??
Måns Nilsson <mansaxel@besserwisser.org> writes:
NS 5 AAAA 21 DNSKEY 3 SPF 1 A 28 NSEC 62 AFSDB 3 RP 1 MX 2 CNAME 9 SOA 2 RRSIG 147 TXT 6 SSHFP 14 SRV 20 DS 4 Total: 16 rrtypes in zone
No TLSA records? Bjørn
On 27 Feb 2019 13:07:09 -0500, "John Levine" <johnl@iecc.com> may have written:
The IETF one says that nobody used type 99, and some of the few implementations we saw were broken, so we deprecated it.
And just after I'd finished adding in all the SPF records too, so I had to turn around and take all them out again immediately after. -- Mike Meredith, University of Portsmouth Hostmaster, Security, and Chief Systems Engineer
Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: Thu, Feb 28, 2019 at 08:47:19AM +0000 Quoting Mike Meredith (mike.meredith@port.ac.uk):
On 27 Feb 2019 13:07:09 -0500, "John Levine" <johnl@iecc.com> may have written:
The IETF one says that nobody used type 99, and some of the few implementations we saw were broken, so we deprecated it.
And just after I'd finished adding in all the SPF records too, so I had to turn around and take all them out again immediately after.
You did not have to. I still have them in. (As well as TXT records that almost look like them, but mostly are there to tickle parser bugs. ) I still get queries for SPF. Obviously "TXT as RRtype for SPF data" is a failure and needs to be re-deprecated. (No, I'm joking, but I wish I wasn't.) Type-squatting is bad for the Internet, and should be discouraged. And, Carthago should be destroyed. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Yow! Now I get to think about all the BAD THINGS I did to a BOWLING BALL when I was in JUNIOR HIGH SCHOOL!
On Thu, Feb 28, 2019, 1:14 AM Måns Nilsson <mansaxel@besserwisser.org> wrote:
Calling TXT or DANE non-standard is a remarkable statement.
Wow. There's a whole lot of people who confuse "standard" with "typical". That's fairly the flaw that brought us all sorts of ossification along the way. And that's exactly fun seeing a Googler doing that mistake! -- Töma
DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom. From: NANOG <nanog-bounces@nanog.org> On Behalf Of Bill Woodcock Sent: February 26, 2019 4:57 AM To: Hank Nussbacher <hank@efes.iucc.ac.il> Cc: nanog@nanog.org Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking
On Feb 24, 2019, at 10:03 PM, Hank Nussbacher <hank@efes.iucc.ac.il<mailto:hank@efes.iucc.ac.il>> wrote: Did you have a CAA record defined and if not, why not?
It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped. I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system. We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. -Bill
On Feb 26, 2019, at 9:15 AM, Jacques Latour <Jacques.Latour@cira.ca> wrote: DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom.
Agreed. There’s absolutely no reason for registrars to be involved with DS records of zones they’re not signing. And, for the same reason, there’s no reason for them to be involved with NS records, either, after an initial bootstrap. -Bill
On 27 Feb 2019, at 6:46 am, Bill Woodcock <woody@pch.net> wrote:
On Feb 26, 2019, at 9:15 AM, Jacques Latour <Jacques.Latour@cira.ca> wrote: DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom.
Agreed. There’s absolutely no reason for registrars to be involved with DS records of zones they’re not signing. And, for the same reason, there’s no reason for them to be involved with NS records, either, after an initial bootstrap.
-Bill
Using https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ with TSIG or SIG(0) would have prevented this with TFA for updating the credentials required to authenticate the updates. The method works with either TSIG or SIG(0) and you can have specific keys to update DS records or NS records and glue records. You can’t MITM TSIG or SIG(0). TSIG and SIG(0) have time limited replay windows. This is just bolting together tried and proven technology with database lookups to determine which registrar authenticates the update. Nameservers already forward UPDATE messages to the primary server for processing using TSIG and SIG(0) between the UPDATE client and the primary server. The key name is in the clear so it is easy to use that to select how to redirect the update. This also works with existing DNS servers when EPP is not thrown into the mix. It also doesn’t require DNSSEC to be deployed. Tools to do this have been shipped with nameservers since UPDATE, TSIG and SIG(0) were invented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Feb 24, 2019, at 9:20 PM, Bill Woodcock <woody@pch.net> wrote:
On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) <dougm@nist.gov> wrote: In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries?
We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo.
Sorry, a correction: Apparently Let’s Encrypt _does_ do a DNSSEC validation check, and presumably that’s why a Comodo cert was used to attack us. It was my prior understanding that Let’s Encrypt certs had been used against DNSSEC-signed zones, but apparently that was not the case. My apologies for my confusion. Nonetheless, even with the DNSSEC validation, there’s a problem here that needs to be solved, on both the parts of the CAs involved and the registry/registrar chain. -Bill
On Feb 24, 2019, at 5:51 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector).
For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.” I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it. -Bill
On 25 Feb 2019, at 4:34 pm, Bill Woodcock <woody@pch.net> wrote:
On Feb 24, 2019, at 5:51 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector).
For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.”
I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it.
-Bill
I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices. I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure. An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking Date: Mon, Feb 25, 2019 at 05:04:39PM +1100 Quoting Mark Andrews (marka@isc.org):
I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices.
I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure.
One thing that immediately struck me upon reading the Krebs post was that people got owned by having to downgrade the end-to-end model of the Internet into Proxy-land. A hotel wifi. Probably only challenged by "Free Wifi" in other spaces in its ability to demolish the Internet as thought out and envisioned. We can conclude in two different directions here; * We need to work on making the Internet more transparent to applications, and thus increasing security. * We're all doomed anyway. DNSSEC is useless. Pick whichever you like. Our children will judge us. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 My EARS are GONE!!
Mark Andrews <marka@isc.org> wrote:
An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors.
Yes (as Mark knows) I would like to be able to use DLV in this enterprisey way. It should also help validators to continue working for local domains when external connectivity is funted. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5. Rough or very rough, but slight or moderate in Irish Sea. Mainly fair. Good, occasionally poor.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, 2019-02-25 at 17:04 +1100, Mark Andrews wrote:
I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation's equipment from the parent zone's management practices.
I want a registrar that can use TOTP 2fa for updates, but that interferes with automated KSK key rollovers. Are there any registrars that use rfc5011 to allow automated KSK key rollovers, combined with TOTP 2fa for web based updates like the initial transition to a secure zone, NS record changes, etc.? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlx1aWgACgkQL6j7milTFsF9mACfVIXUZNLTOEyzbjneuZDeIBEg 2GUAnjoWsNZXtu0PgTuTvPwK0Je9DpCG =nZy7 -----END PGP SIGNATURE-----
participants (35)
-
Ask Bjørn Hansen
-
Bill Woodcock
-
Bjørn Mork
-
bzs@theworld.com
-
Ca By
-
Carl Byington
-
David Conrad
-
Eric Kuhnke
-
Eric Tykwinski
-
Hank Nussbacher
-
Hunter Fuller
-
Jacques Latour
-
Job Snijders
-
John Levine
-
John R. Levine
-
Julien Goodwin
-
Keith Medcalf
-
Mark Andrews
-
Matthew Petach
-
Michael Hallgren
-
Mike
-
Mike Meredith
-
Montgomery, Douglas (Fed)
-
Måns Nilsson
-
Nico Cartron
-
Owen DeLong
-
Paul Ebersman
-
Ross Tajvar
-
Rubens Kuhl
-
Saku Ytti
-
Sander Steffann
-
Seth Mattinen
-
Tony Finch
-
Töma Gavrichenkov
-
valdis.kletnieks@vt.edu