Steps are now being taken, rather faster since Dan Kaminsky came up with a really effective DNS poisoning attack, to secure DNS by using DNSSEC.

The basic idea of DNSSEC is that when you get an answer from the DNS it will be signed by someone you trust. At some point the “trust anchor” for the system will be “.” the DNS root, but for the moment there’s just a handful of “trust anchors” one level down from that. One such anchor is the “.se” country code domain for Sweden. Additionally, Brazil (.br), Puerto Rico (.pr), and Bulgaria (.bg) have signed their zones, but that’s about it for today.

So, wishing to get some experience with the brave new world of DNSSEC, I decided that Sweden was the “in” place to be, and to purchase “cloudba.se” and roll out my first DNSSEC signed domain.

The purchase wasn’t as easy as it might have been — when you buy a domain, Sweden insists that people provide their identity numbers (albeit they have absolutely no way of checking if you’re telling the truth) — or if a company they want a VAT or registration number (which are checkable, albeit I suspect they didn’t bother). I also found that they don’t like spaces in the VAT number — which held things up for a while!

However, eventually they sent me a PGP signed email to tell me I was now the proud owner of “cloudba.se”. Unfortunately, this email wasn’t in RFC3156 PGP/MIME format (or any other format that my usually pretty capable email client understood).

The email was signed with key 0xF440EE9B which was reassuring because the .se registry gives the fingerprint for this key on their website here. Rather less reassuringly footnote (*) next to the fingerprint says “.SE signature for outgoing e-mail. (**) June 1 through August 31.” (the (**) is for a second level of footnote, which is absent — and of course it is now September).

They also enable you to fetch the key through a link on this page to their “PGP nyckel-ID” at http://subkeys.pgp.net.

Unfortunately, fetching the key shows that the signature on the email is invalid.

Since the email seems to have originated in the Windows world, but was signed on a Linux box (giving it a mixture of 0D 0A and 0A line endings), then pushed through a three year old copy of MIME-tools I suppose the failure isn’t too surprising. But strictly the invalid signature means that I shouldn’t trust the email’s contents at all — because the contents have definitely been tampered with since the signature was applied.

Since the point of the email was to get me to login for the first time to the registry website and set my password to control the domain, this is a little unfortunate.

Even if the signature had been correct, then should I trust the PGP key?

Well it is pointed to from the registry website which is a Good Thing. However, they do themselves no favours by referencing a version on the public key servers. I checked who had signed the key (which is an alternative way of trusting its provenance — since the email had arrived to a non-DNSSEC secured domain). Turned out there was no-one I knew, and of 4 individual signatures, 2 were from expired keys. The other signature was the IIS root key — which sounds promising. That has 8 signatures, once again not people I know — but only 1 from a non-expired key, so perhaps I can get to know some of the other 7?

Of course, anyone can sign a key on a public key server, so perhaps it makes sense for .se to suggest that people fetch a key with as many signatures as possible — there’s more chance of it being signed by someone they know. Anyway, I have now added my own signature, using an email address at my nice shiny new domain. However, it is possible that I may not have increased the level of trust

Baltimore is one of what I believe are still three test markets that will go into commercial availability, albeit as much as a year after initial plans, and then months delayed after revised plans were announced. Still 2 to 4 Mbps is far above the level that current cell technology can achieve as a consistent range.

Delta's competitors with broadband interest, like Alaska, Southwest, and American, each have a different plan of attack. Alaska will test service soon with Row 44, which uses Ku-band satellite access, albeit with higher speeds and far lower costs, the company says, than Boeing's doomed Connexion service. Row 44 touts their over-water ability, critical for Alaska, which flies plenty of routes to the great northern state and to Mexico. A test is what's scheduled; not deployment.

Southwest did some deal with Row 44, but nothing further has been forthcoming. Summer's almost over, and we haven't heard more about the "four aircraft" mentioned in the linked press release.

American has the most fully formed plan, but they, too, are testing Aircell's service, and will shortly launch service on 15 trans-continental 767-200s, flying largely routes among SFO, LAX, JFK, and Miami. The company said in the past that they would decide on fleet deployment after the pilot stage.

I shouldn't forget Virgin America, which planned Internet access as part of a set of already-deployed in-flight networked services, but they have under a couple dozen planes at the moment, so they're not a real competitor except on a few routes. Their launch date hasn't been set.

Delta's announcement makes it clear that air-Fi is coming soon, and will likely change how business travelers plan trips. If you can get productive work done during a flight, that changes the financial equation of the trip's cost, and your time out of the office. Pair in-flight Wi-Fi with a cell data card, and you may curse the fact that you're always connected.

OnStar will soon include the ability for the police to shut off your engine remotely. Buses are getting the same capability, in case terrorists want to re-enact the movie Speed. The Pentagon wants a kill switch installed on airplanes, and is worried about potential enemies installing kill switches on their own equipment.

Microsoft is doing some of the most creative thinking along these lines, with something it's calling "Digital Manners Policies." According to its patent application, DMP-enabled devices would accept broadcast "orders" limiting capabilities. Cellphones could be remotely set to vibrate mode in restaurants and concert halls, and be turned off on airplanes and in hospitals. Cameras could be prohibited from taking pictures in locker rooms and museums, and recording equipment could be disabled in theaters. Professors finally could prevent students from texting one another during class.

The possibilities are endless, and very dangerous. Making this work involves building a nearly flawless hierarchical system of authority. That's a difficult security problem even in its simplest form. Distributing that system among a variety of different devices -- computers, phones, PDAs, cameras, recorders -- with different firmware and manufacturers, is even more difficult. Not to mention delegating different levels of authority to various agencies, enterprises, industries and individuals, and then enforcing the necessary safeguards.

Once we go down this path -- giving one device authority over other devices -- the security problems start piling up. Who has the authority to limit functionality of my devices, and how do they get that authority? What prevents them from abusing that power? Do I get the ability to override their limitations? In what circumstances, and how? Can they override my override?

How do we prevent this from being abused? Can a burglar, for example, enforce a "no photography" rule and prevent security cameras from working? Can the police enforce the same rule to avoid another Rodney King incident? Do the police get "superuser" devices that cannot be limited, and do they get "supercontroller" devices that can limit anything? How do we ensure that only they get them, and what do we do when the devices inevitably fall into the wrong hands?

It's comparatively easy to make this work in closed specialized systems -- OnStar, airplane avionics, military hardware -- but much more difficult in open-ended systems. If you think Microsoft's vision could possibly be securely designed, all you have to do is look at the dismal effectiveness of the various copy-protection and digital-rights-management systems we've seen over the years. That's a similar capabilities-enforcement mechanism, albeit simpler than these more general systems.

And that's the key to understanding this system. Don't be fooled by the scare stories of wireless devices on airplanes and in hospitals, or visions of a world where no one is yammering loudly on their cellphones in posh restaurants. This is really about media companies wanting to exert their control further over your electronics. They not only want to prevent you from surreptitiously recording movies and concerts, they want your new television to enforce good "manners" on your computer, and not allow it to record any programs. They want your iPod to politely refuse to copy music a computer other than your own. They want to enforce their legislated definition of manners: to control what you do and when you do it, and to charge you repeatedly for the privilege whenever possible.

"Digital Manners Policies" is a marketing term. Let's call this what it really is: Selective Device Jamming. It's not polite, it's dangerous. It won't make anyone more secure -- or more polite.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

So my next iteration of fun reading on security, logging and other topics.

1. "Security-as-control" vs "security-as-assurance" - a very useful idea (more here), which is often confused with bad results (e.g. "secure" software = has password authentication OR has has no overflow bugs)
2. Rich Mogul grabs GRC by the balls and kicks it, hard, again. A Burton Group guy comes and helps him by doing a nice roundhouse kick in its butt. Still, it doesn't die, as more people kick it ... Maybe 'cause Andy "loves or hates it?"
3. Good advice from Andy IT Guy: "We need to step back from time to time and evaluate what we are doing to determine if it still makes sense." (more)
4. BBC on cloud security, actually interesting. More on the same subject, albeit with a dumb name
5. Breach disclosure laws and security study by CMU, that SANS called idiotic ("What a silly study. It measures the wrong outcome. What matters about data breach notification is what it does to the quality of defenses.") AND "badly flawed" as well. More fun comments on it are here.  More discussion of this complicated subject. Rick kicks it too here.
6. Along the same line, "Data breaches at retailers are the top cause of credit and debit card theft, accounting for about 20% of all incidents." Wow!
7. "The biggest issue in both Audit and IT is a lack of strategic thought." (maybe) When I read it, it reminded me of the old wisdom from Ms Trunk: "if you think you are a 'strategist' - check maybe you think that 'cause your execution sux"
8. A very fun read: "Facing The Monster: The Labors Of Log Management." I am happy that log management has been granted a monster status :-)
9. Role of compliance for SCADA security puzzles me: think about it - you need a law to make people protect systems that control utilities EVEN THOUGH you already demonstrated (kind of) that hackers can explode generators remotely. So, people fear fines from regulators more than exploded power generators? Yep.
10. Is it time to regulate the security of cloud computing?
11. "How to Sell Security" by Bruce Schneier - a MUST read. BTW, FUD is NOT dead, and won't be dead. Ever!
12. OMG, this is huge and will grow: PCI Compliance and Virtualization (think "only one primary function per server" mandated in PCI). Same source on costs of PCI (also fun!) - still, IMHO, PCI is cheaper than properly securing your environment ... And while we are on the subject of PCI, check out Rich's "The Good (Yes, Good) And Bad Of PCI" and the discussion that followed.
13. New wave of compliance is incoooooooooooooming. Take cover!!!
14. Please shut up about ALL security being rolled into the network. Hoff says it best here.  If you want to join this bandwagon, say "all NETWORK security will be in the network."  (you'd probably still be wrong, but less embarassed :-))
15. Finally, some "Unintentional hilarity" from David: this is sooooo the world we live in :-)
    

This is an old problem. In 1996, when I was advising the BMA on clinical system safety and privacy, we trained the staff at one health authority to detect false-pretext phone calls, and they found 30 a week. We reported this to the Department of Health, hoping they’d introduce some operational security measures nationwide; instead the Department got furious at us for treading on their turf and ordered the HA to stop cooperating (the story’s told in my book). More recently I confronted the NHS chief executive, David Nicholson, and patient tsar Harry Cayton, with the issue at a conference early last year; they claimed there wasn’t a problem nowadays now that people have all these computers.

What will it take to get the Department of Health to care about patient privacy? Lack of confidentiality already costs lives, albeit indirectly. Will it require a really high-profile fatality?

Sir Lancelot or Guinevere? Hey don't laugh it could happen to you. In the meantime what has Richard so hot and bothered that he is subscribing mythical qualities to Rohati?  It seems they are using a layer 4 to 7 firewall to control access to applications. They call it network based entitlement control.  I wonder how they stack up to Palo Alto Networks and some of the other next gen application aware, access control firewall products.  From what I understand Nevis Networks and ConSentry can do similar things with the firewalls in their secure switches.

Nevertheless Rohati has gotten some good press, albeit with most coverage carping on the fact that they are founded by former Cisco employees (there are enough former Cisco employees to found many companies I would think). I do think that application aware access control is of tremendous value and this technology will find its way into many technologies. It is a logical extension of identity based access control. 

As usual though Richard can't resist taking a few cheap shots at NAC vendors.  In Richards idyllic view of Camelot, somehow performing pre-connect health or integrity tests is the devils own work.  Richard will just admit that these tests have value and people want them.  They do not preclude doing the rest of the job of access control that Richard seems to approve of though.  Alas, Richard and I have danced this dance before though and I am not going to get into the why it is important.  In fact, here is a new tact for you Richard, it is not important. If you are not going to be convinced, forget about them.  Look beyond admission control tests at what NAC vendors offer around access control and you may find similar type of technology to Rohati in the near future. 

Until than though Richard let me paraphrase Merlin from the movie Camelot "Never be too disturbed if you don't understand what a former analyst is thinking. They don't do it very often".