Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 1:34 PM, James Renken via NANOG  wrote:
> 
> On Feb 25, 2019, at 5:20 AM, Bill Woodcock  wrote:
>> We know that neither Comodo nor Let's Encrypt were DNSSEC validating before 
>> issuing certs.
> 
> I’d like to clarify that Let’s Encrypt has always validated DNSSEC, dating to 
> before we issued our first publicly trusted certificate in September 2015.

Yes, my apologies…  Comodo may well have been used in the attack against us 
_because_ Let’s Encrypt was DNSSEC validating.  I’m sorry for tarring both 
Let’s Encrypt and Comodo with the same brush.

The fact remains, however, that both Let’s Encrypt and Comodo are facilitating 
these hijacks by issuing illegitimate certificates to attackers.  So, ipso 
facto, both organizations’ security practices are insufficient.

We had what I thought to be a productive call with Jacob Hoffman-Andrews, of 
Let’s Encrypt, late last week, and arrived at a couple of possibilities for 
improving the situation a bit, but I don’t imagine that PCH has the expertise 
to contribute substantively to CA business process improvements, as that’s well 
outside our field.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[James Renken via NANOG]

On Feb 25, 2019, at 1:16 PM, Hank Nussbacher  wrote:
> 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.

I’m excited about a proposed CAA extension 
(https://tools.ietf.org/html/draft-ietf-acme-caa-06) that would allow domain 
owners to restrict issuance to a particular ACME account and a particular 
validation method. This could provide stronger protection against most attacks 
short of a registry or registrar hijack. It’s implemented in Let’s Encrypt's 
staging environment, and I hope it’s able to move forward.

-- 
James Renken (pronouns: he/him)
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[James Renken via NANOG]

On Feb 25, 2019, at 5:20 AM, Bill Woodcock  wrote:
> We know that neither Comodo nor Let's Encrypt were DNSSEC validating before 
> issuing certs.

I’d like to clarify that Let’s Encrypt has always validated DNSSEC, dating to 
before we issued our first publicly trusted certificate in September 2015.

-- 
James Renken (pronouns: he/him)
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Nico Cartron]

> On 26 Feb 2019, at 21:58, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
>> 
>> In article 
>>  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  

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 9:20 PM, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed)  
>> 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



signature.asc
Description: Message signed with OpenPGP

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Bjørn Mork]

Måns Nilsson  writes:

> NS5
>   21
> DNSKEY3
> SPF   1
> A 28
> NSEC  62
> AFSDB 3
> RP1
> MX2
> CNAME 9
> SOA   2
> RRSIG 147
> TXT   6
> SSHFP 14
> SRV   20
> DS4
> Total:16 rrtypes in zone

No TLSA records? 


Bjørn

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS 
Hijacking Date: Thu, Feb 28, 2019 at 08:47:19AM + Quoting Mike Meredith 
(mike.mered...@port.ac.uk):
> On 27 Feb 2019 13:07:09 -0500, "John Levine"  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!


signature.asc
Description: PGP signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

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 
(se...@rollernet.us):
> On 2/27/19 7:02 PM, b...@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
21
DNSKEY  3
SPF 1
A   28
NSEC62
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??


signature.asc
Description: PGP signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mike Meredith]

On Wed, 27 Feb 2019 19:59:49 -0800, Seth Mattinen  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!
 


pgpLPwWeNBTLF.pgp
Description: OpenPGP digital signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mike Meredith]

On 27 Feb 2019 13:07:09 -0500, "John Levine"  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
 


pgpCzfMA47BMs.pgp
Description: OpenPGP digital signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Seth Mattinen]

On 2/27/19 7:02 PM, b...@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?

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 1:13 pm, John R. Levine  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 .  It does.

You have missed the point.  No one publishes A’s (or ’s) because they think 
MX is not supported by other MTAs.

If one wanted to stop all fallback to A (and ) 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: ma...@isc.org

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[bzs]

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| b...@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*

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John R. Levine]

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 .  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

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 9:03 am, John R. Levine  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, jo...@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: ma...@isc.org

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

On Thu, Feb 28, 2019, 1:14 AM Måns Nilsson 
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

>

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John R. Levine]

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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 7:28 am, Måns Nilsson  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 
> (jo...@iecc.com):
>> In article <20190227161327.ga27...@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: ma...@isc.org

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

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 
(jo...@iecc.com):
> In article <20190227161327.ga27...@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??


signature.asc
Description: PGP signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article <20190227161327.ga27...@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.

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

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-l...@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.


signature.asc
Description: PGP signature

RE: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Tykwinski]

> 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-experience-for-dnssec-in-a-web-browser/

I don't totally agree with it all, but at least it's been tested.

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

On Wed, Feb 27, 2019, 11:45 PM Mike via NANOG  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

>

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mike via NANOG]

On 2/26/2019 11:10 AM, John Levine wrote:
> In article  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  …

===

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[bzs]

On February 26, 2019 at 20:45 jo...@iecc.com (John Levine) wrote:
 > In article <3fd86d54-7fe4-4e1d-8c8d-a4d79f030...@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 n, 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| b...@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*

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Julien Goodwin]

On 27/2/19 3:10 am, John Levine wrote:
> In article  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-encrypt/

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Ross Tajvar]

Okay that was *clearly* a troll.

On Tue, Feb 26, 2019 at 10:58 PM Keith Medcalf  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@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.
>
>
>
>

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Hunter Fuller]

On Tue, Feb 26, 2019 at 9:56 PM Keith Medcalf  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  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.

RE: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Keith Medcalf]

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@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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article <3fd86d54-7fe4-4e1d-8c8d-a4d79f030...@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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 1:25 PM, Nico Cartron  wrote:
> 
> 
> 
>> On 26 Feb 2019, at 21:58, Bill Woodcock  wrote:
>> 
>> 
>> 
>>> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
>>> 
>>> In article 
>>>  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
> 
> In article 
>  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 27 Feb 2019, at 6:46 am, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 26, 2019, at 9:15 AM, Jacques Latour  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: ma...@isc.org

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 5:35 AM, Ca By  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



signature.asc
Description: Message signed with OpenPGP

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Matthew Petach]

On Tue, Feb 26, 2019 at 9:51 AM  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 9:15 AM, Jacques Latour  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



signature.asc
Description: Message signed with OpenPGP

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

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

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Jacques Latour]

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  On Behalf Of Bill Woodcock
Sent: February 26, 2019 4:57 AM
To: Hank Nussbacher 
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 
> mailto:h...@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

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Seth Mattinen]

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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Carl Byington via NANOG]

-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-

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article 
 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.

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article  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?

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

valdis.kletni...@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.finchhttp://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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By]

On Tue, Feb 26, 2019 at 6:25 AM David Conrad  wrote:

> On Feb 26, 2019, at 2:35 PM, Ca By  wrote:
>
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  wrote:
>
>> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
>> 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
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[David Conrad]

On Feb 26, 2019, at 2:35 PM, Ca By  wrote:
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  > wrote:
> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher  > > 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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By]

On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  wrote:

>
>
> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
> 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
...



>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bjørn Mork]

Bill Woodcock  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Michael Hallgren]

Le 2019-02-26 11:04, Sander Steffann a écrit :
Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

> Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 10:03 PM, Hank Nussbacher  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Saku Ytti]

On Tue, Feb 26, 2019 at 4:05 AM  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

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Job Snijders]

Keith,

On Tue, Feb 26, 2019 at 6:00 AM Keith Medcalf  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

RE: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Keith Medcalf]

>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.

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[Rubens Kuhl]

On Tue, Feb 26, 2019 at 12:14 AM John Levine  wrote:

> In article <24679.1551146...@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

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article <24679.1551146...@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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Hunter Fuller]

On Mon, Feb 25, 2019 at 8:02 PM  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-can-i-use-the-totp-method-for-twofactor-authentication

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Kuhnke]

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  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? :)
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

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? :)

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ross Tajvar]

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  wrote:

>
>
> > On Feb 25, 2019, at 09:25 , Paul Ebersman 
> 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
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

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...

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

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. ;)

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Kuhnke]

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  wrote:

>
>
> > On Feb 25, 2019, at 09:25 , Paul Ebersman 
> 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
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Owen DeLong]

> On Feb 25, 2019, at 09:25 , Paul Ebersman  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Hank Nussbacher]

On 25/02/2019 11:37, Ask Bjørn Hansen wrote:



On Feb 24, 2019, at 22:03, Hank Nussbacher  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

Mark Andrews  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.finchhttp://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.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ask Bjørn Hansen]

> On Feb 24, 2019, at 22:03, Hank Nussbacher  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking Date: Mon, Feb 
25, 2019 at 05:04:39PM +1100 Quoting Mark Andrews (ma...@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!!


signature.asc
Description: PGP signature

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 25 Feb 2019, at 4:34 pm, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 24, 2019, at 5:51 PM, Keith Medcalf  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: ma...@isc.org

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Hank Nussbacher]

On 25/02/2019 07:20, Bill Woodcock wrote:

On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed)  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 5:51 PM, Keith Medcalf  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed)  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



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

e 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:do...@nist.gov]
> >Sent: Sunday, 24 February, 2019 15:38
> >To: nanog@nanog.org
> >Cc: kmedc...@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.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0
> >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.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0
> >
> >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" 
> >To: "nanog@nanog.org" 
> >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
> >   Attacks
> >Message-ID: <6e31d305aee69c4d85116e6a81d0c...@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%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0
> >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 w

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

On Mon, Feb 25, 2019, 1:30 PM John Levine  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

>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article  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

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By]

se
> 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:do...@nist.gov]
> >Sent: Sunday, 24 February, 2019 15:38
> >To: nanog@nanog.org
> >Cc: kmedc...@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.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0
> >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.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0
> >
> >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" 
> >To: "nanog@nanog.org" 
> >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
> >   Attacks
> >Message-ID: <6e31d305aee69c4d85116e6a81d0c...@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%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0
> >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.
> >
> >
>
>
>
>
>
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Montgomery, Douglas (Fed)]

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"  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:do...@nist.gov]
>Sent: Sunday, 24 February, 2019 15:38
    >To: nanog@nanog.org
>Cc: kmedc...@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

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Keith Medcalf]

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:do...@nist.gov]
>Sent: Sunday, 24 February, 2019 15:38
>To: nanog@nanog.org
>Cc: kmedc...@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" 
>To: "nanog@nanog.org" 
>Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
>   Attacks
>Message-ID: <6e31d305aee69c4d85116e6a81d0c...@mail.dessus.com>
>Content-Type: text/plain; charset="us-as

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Montgomery, Douglas (Fed) via NANOG]

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" 
To: "nanog@nanog.org" 
    Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
Attacks
Message-ID: <6e31d305aee69c4d85116e6a81d0c...@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.

 

Re: A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[Bill Woodcock]

> On Feb 23, 2019, at 11:13 AM, Keith Medcalf  wrote:
> 
> 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.

It’s Iranian military.  If you want to call them script kiddies, that’s up to 
you, but people familiar with the campaign characterize it as an APT, and have 
been for the several years that it’s been going on.

> the targets perfectly match those that the NSA would choose

Amusing bedfellows, if they weren’t so annoying.

> The second takeaway being that DNSSEC is useless

You seem to have gotten that one backwards, by over-straining yourself in an 
effort to seem clever.

> Did I miss anything?

Apparently, yes.

-Bill



signature.asc
Description: Message signed with OpenPGP

RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[Keith Medcalf]

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.

A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[Stephane Bortzmeyer]

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/