People barely pay attention to the lock icon. Why would color-coding the lock make a difference?
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.)
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)
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)
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)
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.
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.
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
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.
Worth watching even if you don't care much about DNSSEC, Bernstein is a good speaker.
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.
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.
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?
> 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?
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.
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".
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.