[conspire] phish ... DNS ... DNSSEC!, ...

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Ah, forgot to also point out ... DNSSEC.  That certainly can quite
> help with DNS.

But not with phishing, contrary to what your Subject header would seem
to imply.

You and I have had this conversation before, where you push DNSSEC as
the solution to a lot of security problems, and I demur, saying,
certainly, making the chain of attestation down from the DNS root more
reliable is A Good Thing in itself, but that you are (as usual) vastly
overselling it.

Any time I'm doing something security-sensitive over the Internet, I 
carefully avoid merely trusting (anyone's) DNS and authenticate what and
whom I'm talking to using authentication protocols higher up in the
software stack.  And so, when I hear people say everyone needs DNSSEC
for reason that include, say, phishing, I think 'Somebody is failing to 
understand security.'

Let's take ssh, for example.  I travel the world, and, from wherever I
happen to be, including in the middle of the Pacific Ocean on a cruise
ship, I find it useful to ssh home, in order to get to my mail
(instances of mutt running in GNU screen sessions) and other substantive
computing on my server.  To get there, I _scrupulously_ avoid trusting
the DNS (anyone's DNS) and scrupulously avoid trusting all networks
between me and home.

How?  By carefully noting whether the far end's SSH host key hash is
unchanged, when I attempt 'ssh 198.144.195.186'.  My local ssh client 
on my laptop knows what the host key hash is _supposed_ to be, and gives
me a warning.

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that a host key has just been changed.
  The fingerprint for the RSA key sent by the remote host is
  ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab.
  Please contact your system administrator.

(That obviously is not my real RSA key hash.)

If I see that, then I know that the far end is _not_ my server, and I 
carefully do not enter a login credential or trust it in any way.

In the rare and regrettable case of my needing to ssh _from_ a local
computer that doesn't have my host key hash in the local known_hosts 
file, I consult the printout stored into my wallet, where I've stashed
the values of both my ssh host key hash (fingerprint) and my Web cert
hash for reference.

So, DNSSEC, sure, A Good Thing in the abstract and in general -- though
a monumental pain in the ass for DNS administrators -- but hardly even 
a tiny bit relevant to _most_ security problems including remote host
authentication.

It also bothers me that DNSSEC involves a significant degree of central
control.  As one critic put it, 'DNSSEC is a Government-Controlled PKI.'
Reliance on poor centrally controlled PKIs is a bad idea.  So, my
support for DNSSEC would be tepid, even if it weren't a colossal pain in
the ass, which it also is.  As the aforementioned critic put it, if
DNSSEC had been deployed five years earlier, the TLS keys for bit.ly
would have been under the control of Muammar Gaddafi.  Sorry, but how is
this security?

In general, big, overblown crypto infrastructures with a role for
squirrely governments do not give me the warm fuzzies, whereas something
simple like checking a host key fingerprint against my own records does.
Sorry, but how is this security?

In general, big, overblown crypto infrastructures with a role for
squirrely governments do not give me the warm fuzzies, whereas something
simple like checking a host key fingerprint against my own records does.

Today, if someone asks, 'How can I verify as authentic the cert hash of
your linuxmafia.com cert?', I'll say first 'Are you visiting my house
soon?  If you are, I'll give you a slip of paper with my cert hash
written on it, with my signature and a cheery greeting.  If not, can you
verify the authenticity of my gpg key using the public keyservers?  If
you can, then I would be glad to send you gpg-signed mail attesting to
my cert hash value.

A bit quaint and manual, but the above has the virtue of using only
simple, well-tested software and not requiring trust of hideously
overengineered government PKI schemes.


> And ... CAs and SSL/TLS, yes, many CAs have had their problems(!).

Again, we've talked about this repeatedly.  I've presented examples
showing that the CA model used for (e.g.) Web certs is horribly broken,
really should not be trusted, and basically needs to die.  I'm hardly 
the only person who feels this way, e.g., Bruce Schneier does, too.


> Well, DNS can also help - at least in part - with that.
> There's DNS CAA records:
> https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization

CAA continues to rely on, and put some degree of trust in, the
Certificate Authorities.  I consider this a fatal flaw, as large numbers
of the CAs have repeatedly shown that they cannot be trusted and are a
menace to everyone's security.  One of the most recent of many examples:
https://www.schneier.com/blog/archives/2018/03/e-mailing_priva.html
(Please note my comment in the reader thread at the bottom.)

> Also of note DANE:
> https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
> but alas, DANE seems to not been implemented much, so seems to have not
> gained much traction...

DANE is much more reasonable than CAA, in my view -- but still a
colossal pain in the ass.