W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Why not DNS records Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

From: Ryan Sleevi <rsleevi@chromium.org>
Date: Sun, 28 Dec 2014 01:05:12 -0800
Message-ID: <CACvaWvZ3a+h_pBiG0wLzSCTQr8zLnXv5sAnKZXxZRkQspD_xPQ@mail.gmail.com>
To: Austin William Wright <aaa@bzfx.net>
Cc: Ryan Sleevi <rsleevi@chromium.org>, security-dev <security-dev@chromium.org>
There's a lot of lists on CC here - I've pruned them to bcc, and left
the discussion for
https://groups.google.com/a/chromium.org/forum/#!forum/security-dev .

This is also no longer related to the proposal at hand - which was
marking HTTP as not secure.

Finally, apologies for the length. You asked for a detailed response,
and here it is. I suppose at some point we need to write a FAQ on why
DNS is often the problem, and not the solution.

1) DNS without DNSSEC is insecure in the face of a network attacker
(which we presume we're dealing with)
2) Using plaintext to negotiate the cryptographic capabilities of your
peer inevitably ends in doom (as it does for SMTP), unless you're
committed to crypto only (e.g. HTTPS scheme)
3) DNSSEC is undeployable in practice. It is a state far worse than
IPv6, and no amount of wishing or application activism is going to
change this - it's a problem of economy, not education.
4) Even if DNSSEC was deployable, it suffers from a wide variety of
operational security failures that are equal-to or worse than the CA

On Sat, Dec 27, 2014 at 11:56 PM, Austin William Wright <aaa@bzfx.net> wrote:
> I would appreciate a rebuttal; this is nonconstructive.

The issues here I'm talking about are somewhat well known in the
community - from a lack of TLDs being signed (making DNSSEC hardly
ubiquitous), the lack of client libraries for _effectively_ and
_efficiently_ querying DNS records and validating their status (and
no, EDNS is not effective), and the plentitude of home networking
devices that absolutely fall over on basic DNS, let alone DNSSEC, all
prevent it from being relevant.

Consider, for simple example, the lack of a validating resolver in
Windows clients. Your security is reliant upon an IPSec (or related)
tunnel to your resolver and that resolver is expected to validate. You
have complete trust in your upstream. Who is that upstream? Your
router? Unlikely - it's most often your ISP. Who has the most to gain
from breaking your security? To be honest, there's incredible
financial incentive from your ISP - and as this thread noted in the
beginning, ISPs are fully aware of that.

Nothing Chrom[e/ium] does here is going to change that status. This is
like saying clients should support IPv6 - indeed, IPv6 support is
actually far easier to deploy (in the real world, not the lab) than

It's a solution that a hard fail is impossible, because the failure
rates are far too high (well into the double digits), even when
everything else is perfect.

>> Again, as with HTTP, an attacker can easily strip out the STARTTLS. There
>> are many who already do. The server cannot reject plaintext queries - the
>> attacker need just SSLStrip them.
>> In short, it provides zero effective security without supplemental out of
>> band policy.
> I'm aware of the specifics, though I'll entertain the discussion below.
> You describe a client issue; clients know that if an active attacker exists,
> and they make ANY sort of plaintext query, it's game over. This is not a
> server problem.

This is entirely unrelated to the problem at discussion. The question
was whether STARTTLS - in which the server advertises it's
cryptographic capability over an insecure connection - is sufficient
to mitigate an active attacker. It isn't. The client _needs_ a priori
knowledge that the server supports secure channels (and not just
secure, but properly configured). And you don't have that.

Now, you could argue that you could use DNS records, but absent
DNSSEC, you're back to using an insecure medium to advertise security
capabilities. It's a doomed failure.

So then you're back to DNSSEC, which has a ton of issues (discussed
both above and below in this thread).

_or_ you use a scheme - whether SMTPS, IMAPS, or in the case of HTTP,
HTTPS, and you explicitly signal that knowledge in-band. Which is why
it's the most effective (read: deployable) solution, even if it has
its limitations.

That is, I don't deny that TLSA exists - and is quite nifty, for
server-to-server deployments (in which, if you're a good server admin,
you control directly or through indirect market pressures your path to
your peers and your capabilities of your server software stack). But
for clients, it's a nogo. As is DANE.

> Cross-protocol? Vs. DNSSEC? Link?

DNSSEC isn't happening, so it's somewhat silly to compare against the
thing which isn't.


>> But more importantly, and to the point in which I was originally
>> responding:
>> 1) SMTP/IMAP do not use DNS to deliver security policy.
> SPF and DKIM records? (Aside, I find it funny protecting cat pictures
> (accessible to anyone!) has become more important than filtering out spam
> and protecting private, confidential email!)
> SSH also uses SSHFP records. This is supposed to be one of the most secure
> methods of communication, period!

The policy in question was being TLS, but sure. Again, absent secured
DNS, it's a non-starter.

If you're using SSHFP over DNS w/o DNSSEC, well, you're in for a world of hurt.

>> 2) DNSSEC is a presently-failed technology. That it might improve is a
>> possibility, but not with today's internet
> All I can do is re-assert that on all my machines, on all my clients, on all
> domain names secured with DNSSEC, it works, and I'm not aware of any attacks
> on it, AND it's gaining adoption. (I have some brilliant colleagues working
> on making DNSSEC deployment completely effortless to end-users. This is what
> we need to do to TLS!) If you have a specific attack, by all means,
> enlighten me!

That's great. And you might have IPv6 setup too. But it doesn't scale
- especially not to Internet scale.

It doesn't work when there are hundreds of millions of XP users still
in the world. Or, for that matter, Windows Vista users.

It doesn't work where there are hundreds of millions of users behind
crappy home routers provided by their ISP that fall over at multiple
simultaneous DNS requests - let alone DNSSEC.

It doesn't help the applications that want to use DNSSEC to express
policy, but can't get the records from the resolver library into
application space because no such API exists. And it's not for a lack
of trying either - you can dig up the discussions from over 5 years
ago in the IETF about attempts to come up with something. And the
existing APIs are (from experience) awful and unreliable.

This isn't "adoption isn't big enough so I won't adopt it" - this is
there are real and practical challenges that are entirely
externalities to the things we have influence over, and more
importantly, even if everything known-bad were "fixed" tomorrow, the
world of software and hardware moves slow enough that it will be a
decade before any sensible policies (read: always require DNSSEC, use
DNSSEC to look up security policies such as requiring TLS) become

>> 3) DNSSEC is less secure than the CA system, for many reasons
> I don't think I've heard this before. The CA system allows any one of
> hundreds of CAs to sign a domain name. DNS allows just one. Unless there's a
> technical flaw I'm unaware of, I choose the latter as more trustworthy, and
> thereby more secure.

It'd be a bad choice if you do.

- DNS registrar compromises are a near daily occurrence.
- Domain seizures are a near daily occurrence, yet we lack evidence of
a single CA being compelled. I realize that the absent of evidence
doesn't mean it doesn't happen - but certainly not at the scale at
which it happens on a regular basis for domains.
- There is no transparency system for what your
root/TLD/registry/registrar is signing. A compromise is virtually
undetectable. Compare that with Certificate Transparency.
- Again, a lack of client support and faith-in-the-evil-bit (ala
Windows) means that your actual security at the client is dependent
upon the upstream resolver, which is again a network attacker. Your
Starbucks wifi? Easily MITM'able and strippable for that security.
- The cryptographic policies in deployments are abysmal. The number of
non-rotating RSA-1024 bit keys is a joke in DNSSEC, and yet they're
virtually eliminated in the SSL world.

The single hierarchal system is detrimental, rather than beneficial,
to the security. You can argue that it means there are fewer places to
attack (your registrar, the registry, the root), but the reality is
your registrar is far and away the weakest link for security, and
you're only a transfer away from full MITM.

Certificates certainly rely on DNS for issuance, so you could argue
that all of these (and more!) issues exist for the existing Web PKI.
But to do so would be to ignore the defense in depth measures that
apply from having multiple systems require compromise - even more, now
with Certificate Transparency. For DNSSEC, these simply don't exist -
and, again, based on simple timetables and no tarot reading - won't
for another decade.

Now, to the thread at hand, how does DNS solve us of any of the
issues? It doesn't - in as much as it is still necessary to
communicate to the user that an insecure, unauthenticated transport
was used that anyone may have modified in transit.

If we presumed we had a secure introducer, such as TLSA - it serves
only to supplement HTTP Strict Transport Security - the latter of
which is immediately deployable and without any of the attendant

If we presumed we had a secure means of expressing policy, such as
DANE - it serves only to supplement HTTP Public Key Pinning. DANE has
a number of compelling advantages over HPKP in some respects (and
disadvantages, in others), but using it absent DNSSEC would be a
foolish errand. And not just DNSSEC-some-of-the-time, but
DNSSEC-always, which in the world of mobile clients using cafe wifi,
is just not something we're going to see any time soon.

If we presumed we had a means of actually securing DNSSEC - that is,
if registries had a way of setting cryptographic policies that
registrars would have to enforce, if clients could independently audit
adherence with these policies, if there was a transparency system for
DNSSEC to reveal manipulation (hostile or coerced) - then maybe the
above two would become viable. But, again, that's even more problems
to solve, and even less ability to solve them through the means

This isn't fatalistic nihilism, it's pragmatism - DNSSEC now is the
state IPv6 was in 1997 (that is, when the first drafts on what would
become RFC 2292 begin in full). Even if every single problem were
solved tomorrow, you still have to get updates to the hundreds of
millions of devices and machines that need it to "not be awful", and
that's not going to happen.
Received on Sunday, 28 December 2014 09:05:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC