I don't think the goal would be getting everyone to pay attention, because if it is, you're absolutely correct.
But if you look at it as a way to spread awareness to web admins, to be confronted with the question "how come we don't have the bestest type of icon", it's not so bad.
A related example: I have recently been wondering how widespread DNSSEC is.
I installed the DNSSEC validator chrome plugin, and now (almost) every website on the planet shows me a sad "no DNSSEC" icon. I can't help but feel that part of the low deployment of DNSSEC is because almost nobody, including web admins, gets any feedback about DNSSEC. (I am aware that there are other costs and risks to deployment.)
Also, despite my earlier google queries about DNSSEC, everything I was reading was pretty dry. The magic phrase to google for is "DNSSEC sucks"--that gets you the interesting stuff.
I don't understand why your criticism of DNSSEC focuses on TLS vs. DNSSEC.
DNS is a scalable global key-value store, and DNSSEC allows owners of namespaces to sign their own key pairs and delegate to sub-namespaces. If you can make the case that _that_ is not valuable, or how that is accomplished by other means, I am curious. But TLS vs. DNSSEC doesn't cut it.
Yes, DNSSEC/DANE can make TLS work better. It provides a straightforward way to pin an entire zone tree while allowing site owner modifications. Your example of Ghadaffi and Bit.ly is silly, because the status quo is that governments already have access to CA keys able to issue for any server. Restricting to a single zone can only improve that.
I don't know how you can claim NSEC3 is a grotesque hack without noting that it is equally grotesque to pretend that your DNS records are private. If I wanted to collect the BoA zone, I would setup recursive nameservers on the coffee shops' wifi within a quarter mile of their headquarters and grep the logs. Incidentally, this would work even with DNSCurve deployed.
Anyone who would advocate for DANE in 2013 is looking at a situation where users assume that governments have compromised the PKI that drives the most important encryption on the Internet, and saying to themselves, "let's bake that problem into the network architecturally; let's make it so that the NSA doesn't even need to compromise a CA, because they'll own the global root of all CAs".
Regarding NSEC3: most people reading this thread don't know what it is, so I'll explain it really quickly and let them decide, because it it so obviously a stupid hack that I don't think I need to argue against it too much:
Just a couple years ago --- more than a decade after work on DNSSEC was started --- somebody realized that Bank of America would not in fact be OK with a DNS design where every single one of their hostnames, for both public and internal systems, was public. But that's a problem, because DNSSEC wants to authenticate negative responses; if there's no JABBERWOCKY.BANKOFAMERICA.COM, DNSSEC wants that cryptographically proven. But their design to do that breaks if there are nonpublic names, because DNSSEC chains the names together as a way to authenticate denial.
So here's what they came up with: domain names are hashed (crappily) as if for a 1997 Unix password file, and the authenticated denial messages refer to hash ranges instead of literal hostnames. Meaning you can only discover all of Bank of America's hostnames if you are as technologically sophisticated as a circa-1997 password cracker.
I don't know why you're talking about the NSA. And if you are, anyway, do you really think they can't ask Verisign for an arbitrary cert already? And won't the same tools that modern network programs use to protect against these attacks (certificate pinning, convergence, etc.) work equally well when applied to DNSSEC KSKs?
NSEC3 is good enough. I gave you a trivial way of acquiring jabberwocky.bankofamerica.com, even with DNSCurve deployed. If BOA wants network accessible services on a network accessible namespace to be private, they should make a zone cut at internal.bankofamerica.com and restrict access to the delegated NS (which can be the same machine). The easiest way to do this is to run a VPN, which they already do.
I am asserting that having a global key-value store, where namespace owners can sign their own entries and make delegations, is a valuable system to have in place. That is what DNSSEC is. Unless you can argue against that, you are simply beating on a straw man.
Why spend the money adopting DNSSEC if it's at best a marginal setback to Internet security?
The "trivial way of acquiring jabberwocky.bankofamerica.com" relies on somehow being in the same coffee shop as an employee who accesses the site using public DNS. Whereas DNSSEC just goes right ahead and publishes the information.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
It's not a setback at all. You can still use the existing CA system. In fact, you can just not set the secure bit and ignore its existence.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
Very few networks have ridiculous PHB requirements for public servers defined on public namespaces that are somehow slightly more difficult to find than normal (and once the cat / jabberwocky is out of the bag and published to a mailing list somewhere, gives no advantage whatsoever).
Those that do have reasonable options for satisfying said PHBs, first with NSEC3 and then with zone cuts and private networks (which actually does solve the problem, instead of just pretending to solve it).
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
What alternatives? To my knowledge, there is no credible alternative system to DNS. Why put up with a DNS system that is not end to end verified when you don't have to?
I think you are painting an exagerated picture of DNSSEC deployment. Off the top of my head every gov/mil domain is signed, debian, archlinux, fedora, paypal, freebsd, icann, ietf, isc...
I don't know--it really seems pretty rare in the sites I use day-to-day. Going over a list of popular websites (plus a few of interest to hackernews users), I don't think any of hackernews, google, reddit, github, wikipedia, facebook, yahoo, amazon, twitter, tumblr, bing, or ebay are using DNSSEC. My bank is not, nor are any of the other banks I thought of off the top of my head.
Of the sites you mention, paypal is the only one that I use on any sort of a recurring basis. But it's a little weird to a DNSSEC newbie like me, so maybe you can explain. The verisign tool shows that paypal.com is using DNSSEC, but it doesn't appear that www.paypal.com itself is secured. Is the chrome plugin giving me misleading information? Is this how things are supposed to be?
And a lot of US government sites have DNSSEC waivers. The first two examples I tried:
I am certainly not a DNSSEC expert so take my explanation with a grain of
salt.
Short answer www.paypal.com is a cname for an akamai box. That cname record is
secure:
$ unbound-host -v -t cname www.paypal.com www.paypal.com has CNAME record
www.paypal.com.akadns.net. (secure)
Everything falls apart when your resolver finishes the rest of the required
lookups to get an IP address from akadns/akamaiedge.
As I have been experimenting/researching dnssec I have often found it
is useful to use verisign's tool AND sandia's dnsviz[1] tool. For the
moment forget what I said about paypal's cname and compare sandia's[2] and
verisign's[3] results for www.paypal.com and see if you can spot the issue.
You are correct that it is a relief that verisign uses DNSSEC but if I may be
so bold I think you may be wrong about why it is a relief. (I am trying to be
helpful, i apologize if that sounds dickish it is not my intent) With DNSSEC
(just like DNS) everything flows from the root. Verisign manages the .com
tld so if they did not sign the .com you could not verify anyhost.com. The
same thing can be said for DISA, GSA and PIR for .mil, .gov and .org zones
respectively.
As far as NIST goes they are the second least surprising DNSSEC adopter as
far as the federal government goes. Because of NIST's standards function
within the government they are normally at the forefront for things like
this. Moreover DNSSEC is heavily reliant on accurate time and NIST is the home
of the government's truechimer. However if you go down this rabbit hole you
start to have some serious chicken and egg problems.
Since you mentioned banks, I just need to chime in:
I recently (May, June) surveyed 100 european banks (in Germany, Switzerland, France, Italy, Austria), roughly selected for the 20 specimens with the greatest total assets per country.
None of them have deployed DNSSEC. Most use SSL, many use EV certificates, a few go so far as to include HSTS. DNSSEC? Zero.
In terms of traffic no doubt. But that seems like the most ridiculous metric to use. But more importantly these are off the top of my head and my interests are not your average internet users interests (eg debian). Comcast is using DNSSEC. Google's dns (8.8.8.8) will do dnssec if requested in the query.
Part of the problem is that the lock icon is just grey. The lock icon should be pulsing red, solid yellow or green. This would work the same way Google's anti-black-hat-SEO advisories work. Force people into security by calling attention to bad practices and reducing the prominence in search of any site that violates this.
Clicking on the pulsing red icon, would pop up a window that tells people exactly what they should be careful about.
Clicking on the certificate, should present a much clearer dialog for the layman.
That's what the people selling EV certs said. But EV certs have been a failure too, and they had a much louder UI.
And at least EV certs were backed by a concept that people could understand. It's unreasonable to expect people outside of tech to understand "forward secrecy".
It is at least possible that EV certs have seen limited uptake because people understand too much about them. After all, they are the same CA "sure you can trust us" scam that we've always had, except with more rent-seeking. Some users and/or site operators might have been influenced e.g. by EV certs' unsavory association with Comodo.
So strike my last sentence. EV certs are still more onerous for site operators in terms of price and process than "normal" certs. They don't offer a credible increase in security or decrease in liability for anyone. Those facts suffice to explain the paucity of their mass-market adoption.
In retrospect, the timing of Google introducing PFS is interesting. It's possible they introduced it because they either knew about or suspected the surveillance but either had no proof or were unable to talk about it. Of course, maybe they're just security conscious but it's interesting that Adam Langley so explicitly referred to the recording for later decryption scenario.
The USA has one of the least intrusive, least overbroad surveillance regimes in the world. Google introduced PFS because governments in places like India and Russia openly desire to intercept all communications.
The average customer does not, but security professionals do.
I know that in many government scenarios, (think local governments) for example, policy guidance drives purchasing and other behavior. So if compliance with some security standard requires a "green lock" that lock matters.
That will drive behavior -- banks, insurance companies, and other businesses will be disqualified for all sorts of RFPs.
Comments
People barely pay attention to the lock icon. Why would color-coding the lock make a difference?
I don't think the goal would be getting everyone to pay attention, because if it is, you're absolutely correct.
But if you look at it as a way to spread awareness to web admins, to be confronted with the question "how come we don't have the bestest type of icon", it's not so bad.
A related example: I have recently been wondering how widespread DNSSEC is.
I installed the DNSSEC validator chrome plugin, and now (almost) every website on the planet shows me a sad "no DNSSEC" icon. I can't help but feel that part of the low deployment of DNSSEC is because almost nobody, including web admins, gets any feedback about DNSSEC. (I am aware that there are other costs and risks to deployment.)
DNSSEC provides minimal value and adds significant overhead. We're better off the less it's deployed.
If you're like me, and wishing tptacek would elaborate, it turns out he has in the past. For example, this entertaining thread from three years ago:
https://news.ycombinator.com/item?id=1234567
Also, despite my earlier google queries about DNSSEC, everything I was reading was pretty dry. The magic phrase to google for is "DNSSEC sucks"--that gets you the interesting stuff.
I haven't digested it yet, but in those results, this looks pretty interesting from D. J. Bernstein: http://cr.yp.to/talks/2010.12.28/slides.pdf
More:
https://news.ycombinator.com/item?id=5571937
https://news.ycombinator.com/item?id=4071178
https://news.ycombinator.com/item?id=2932378
I really don't like DNSSEC. I think it's a bad design that will harm the Internet.
The a video of the talk those slides are from is online http://vimeo.com/18417770
Worth watching even if you don't care much about DNSSEC, Bernstein is a good speaker.
I don't understand why your criticism of DNSSEC focuses on TLS vs. DNSSEC.
DNS is a scalable global key-value store, and DNSSEC allows owners of namespaces to sign their own key pairs and delegate to sub-namespaces. If you can make the case that _that_ is not valuable, or how that is accomplished by other means, I am curious. But TLS vs. DNSSEC doesn't cut it.
Yes, DNSSEC/DANE can make TLS work better. It provides a straightforward way to pin an entire zone tree while allowing site owner modifications. Your example of Ghadaffi and Bit.ly is silly, because the status quo is that governments already have access to CA keys able to issue for any server. Restricting to a single zone can only improve that.
I don't know how you can claim NSEC3 is a grotesque hack without noting that it is equally grotesque to pretend that your DNS records are private. If I wanted to collect the BoA zone, I would setup recursive nameservers on the coffee shops' wifi within a quarter mile of their headquarters and grep the logs. Incidentally, this would work even with DNSCurve deployed.
Anyone who would advocate for DANE in 2013 is looking at a situation where users assume that governments have compromised the PKI that drives the most important encryption on the Internet, and saying to themselves, "let's bake that problem into the network architecturally; let's make it so that the NSA doesn't even need to compromise a CA, because they'll own the global root of all CAs".
Regarding NSEC3: most people reading this thread don't know what it is, so I'll explain it really quickly and let them decide, because it it so obviously a stupid hack that I don't think I need to argue against it too much:
Just a couple years ago --- more than a decade after work on DNSSEC was started --- somebody realized that Bank of America would not in fact be OK with a DNS design where every single one of their hostnames, for both public and internal systems, was public. But that's a problem, because DNSSEC wants to authenticate negative responses; if there's no JABBERWOCKY.BANKOFAMERICA.COM, DNSSEC wants that cryptographically proven. But their design to do that breaks if there are nonpublic names, because DNSSEC chains the names together as a way to authenticate denial.
So here's what they came up with: domain names are hashed (crappily) as if for a 1997 Unix password file, and the authenticated denial messages refer to hash ranges instead of literal hostnames. Meaning you can only discover all of Bank of America's hostnames if you are as technologically sophisticated as a circa-1997 password cracker.
You didn't actually respond to what I said.
I don't know why you're talking about the NSA. And if you are, anyway, do you really think they can't ask Verisign for an arbitrary cert already? And won't the same tools that modern network programs use to protect against these attacks (certificate pinning, convergence, etc.) work equally well when applied to DNSSEC KSKs?
NSEC3 is good enough. I gave you a trivial way of acquiring jabberwocky.bankofamerica.com, even with DNSCurve deployed. If BOA wants network accessible services on a network accessible namespace to be private, they should make a zone cut at internal.bankofamerica.com and restrict access to the delegated NS (which can be the same machine). The easiest way to do this is to run a VPN, which they already do.
I am asserting that having a global key-value store, where namespace owners can sign their own entries and make delegations, is a valuable system to have in place. That is what DNSSEC is. Unless you can argue against that, you are simply beating on a straw man.
Why spend the money adopting DNSSEC if it's at best a marginal setback to Internet security?
The "trivial way of acquiring jabberwocky.bankofamerica.com" relies on somehow being in the same coffee shop as an employee who accesses the site using public DNS. Whereas DNSSEC just goes right ahead and publishes the information.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
It's not a setback at all. You can still use the existing CA system. In fact, you can just not set the secure bit and ignore its existence.
Very few networks have ridiculous PHB requirements for public servers defined on public namespaces that are somehow slightly more difficult to find than normal (and once the cat / jabberwocky is out of the bag and published to a mailing list somewhere, gives no advantage whatsoever).
Those that do have reasonable options for satisfying said PHBs, first with NSEC3 and then with zone cuts and private networks (which actually does solve the problem, instead of just pretending to solve it).
What alternatives? To my knowledge, there is no credible alternative system to DNS. Why put up with a DNS system that is not end to end verified when you don't have to?
I think you are painting an exagerated picture of DNSSEC deployment. Off the top of my head every gov/mil domain is signed, debian, archlinux, fedora, paypal, freebsd, icann, ietf, isc...
I don't know--it really seems pretty rare in the sites I use day-to-day. Going over a list of popular websites (plus a few of interest to hackernews users), I don't think any of hackernews, google, reddit, github, wikipedia, facebook, yahoo, amazon, twitter, tumblr, bing, or ebay are using DNSSEC. My bank is not, nor are any of the other banks I thought of off the top of my head.
Of the sites you mention, paypal is the only one that I use on any sort of a recurring basis. But it's a little weird to a DNSSEC newbie like me, so maybe you can explain. The verisign tool shows that paypal.com is using DNSSEC, but it doesn't appear that www.paypal.com itself is secured. Is the chrome plugin giving me misleading information? Is this how things are supposed to be?
And a lot of US government sites have DNSSEC waivers. The first two examples I tried:
cia.gov appears to not use DNSSEC: http://dnssec-debugger.verisignlabs.com/www.cia.gov nsa.gov appears to not use DNSSEC: http://dnssec-debugger.verisignlabs.com/www.nsa.gov
(Thank goodness the verisign tool itself IS using DNSSEC.)
A long list of US .gov sites with and without working DNSSEC: http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov
(Also: nist.gov is using DNSSEC)
I am certainly not a DNSSEC expert so take my explanation with a grain of salt.
Short answer www.paypal.com is a cname for an akamai box. That cname record is secure:
Everything falls apart when your resolver finishes the rest of the required lookups to get an IP address from akadns/akamaiedge.As I have been experimenting/researching dnssec I have often found it is useful to use verisign's tool AND sandia's dnsviz[1] tool. For the moment forget what I said about paypal's cname and compare sandia's[2] and verisign's[3] results for www.paypal.com and see if you can spot the issue.
You are correct that it is a relief that verisign uses DNSSEC but if I may be so bold I think you may be wrong about why it is a relief. (I am trying to be helpful, i apologize if that sounds dickish it is not my intent) With DNSSEC (just like DNS) everything flows from the root. Verisign manages the .com tld so if they did not sign the .com you could not verify anyhost.com. The same thing can be said for DISA, GSA and PIR for .mil, .gov and .org zones respectively.
As far as NIST goes they are the second least surprising DNSSEC adopter as far as the federal government goes. Because of NIST's standards function within the government they are normally at the forefront for things like this. Moreover DNSSEC is heavily reliant on accurate time and NIST is the home of the government's truechimer. However if you go down this rabbit hole you start to have some serious chicken and egg problems.
[1] http://dnsviz.net/ (NB: sandia's is so slow that its painful)
[2] http://dnsviz.net/d/www.paypal.com/dnssec/
[3] http://dnssec-debugger.verisignlabs.com/www.paypal.com
Since you mentioned banks, I just need to chime in:
I recently (May, June) surveyed 100 european banks (in Germany, Switzerland, France, Italy, Austria), roughly selected for the 20 specimens with the greatest total assets per country.
None of them have deployed DNSSEC. Most use SSL, many use EV certificates, a few go so far as to include HSTS. DNSSEC? Zero.
Do you have the dataset anywhere?
The data will be part of my bachelor's thesis, to be published in July. Well, pseudo-published, as such theses tend to end up.
Ping me at ycombinator at y dot ly for your choice of either raw (collected using Qualys' SSL Server Test[1] and plain old DiG) or aggregate data.
[1] http://ssllabs.com/ssltest/analyze.html
So in terms of traffic, basically 0% of the internet.
In terms of traffic no doubt. But that seems like the most ridiculous metric to use. But more importantly these are off the top of my head and my interests are not your average internet users interests (eg debian). Comcast is using DNSSEC. Google's dns (8.8.8.8) will do dnssec if requested in the query.
Part of the problem is that the lock icon is just grey. The lock icon should be pulsing red, solid yellow or green. This would work the same way Google's anti-black-hat-SEO advisories work. Force people into security by calling attention to bad practices and reducing the prominence in search of any site that violates this.
Clicking on the pulsing red icon, would pop up a window that tells people exactly what they should be careful about.
Clicking on the certificate, should present a much clearer dialog for the layman.
Yeah that's great when I'm trying to focus on an article I'm reading. This is why security people aren't allowed to touch UI.
All joking aside, I agree that this issue should be surfaced, and I think people would notice the security icon if it was in constant flux.
Because they can learn.
That's what the people selling EV certs said. But EV certs have been a failure too, and they had a much louder UI.
And at least EV certs were backed by a concept that people could understand. It's unreasonable to expect people outside of tech to understand "forward secrecy".
It is at least possible that EV certs have seen limited uptake because people understand too much about them. After all, they are the same CA "sure you can trust us" scam that we've always had, except with more rent-seeking. Some users and/or site operators might have been influenced e.g. by EV certs' unsavory association with Comodo.
It is extremely unlikely that mass-market adoption of EV certificates has anything to do with the inside baseball of CA politics.
So strike my last sentence. EV certs are still more onerous for site operators in terms of price and process than "normal" certs. They don't offer a credible increase in security or decrease in liability for anyone. Those facts suffice to explain the paucity of their mass-market adoption.
Back then people didn't know the extent and depth of NSA's surveillance, so they weren't motivated to learn. The stakes are higher now.
In retrospect, the timing of Google introducing PFS is interesting. It's possible they introduced it because they either knew about or suspected the surveillance but either had no proof or were unable to talk about it. Of course, maybe they're just security conscious but it's interesting that Adam Langley so explicitly referred to the recording for later decryption scenario.
The USA has one of the least intrusive, least overbroad surveillance regimes in the world. Google introduced PFS because governments in places like India and Russia openly desire to intercept all communications.
The average customer does not, but security professionals do.
I know that in many government scenarios, (think local governments) for example, policy guidance drives purchasing and other behavior. So if compliance with some security standard requires a "green lock" that lock matters.
That will drive behavior -- banks, insurance companies, and other businesses will be disqualified for all sorts of RFPs.
Make it blink or jiggle a bit. Problem of winning attention solved.