I’ve given some talks this year about the Internet’s insecure infrastructure — stressing that fundamental protocols such as BGP and DNS cannot really be trusted at the moment. Although they work just fine most of the time, they are susceptible to attacks which can mean, for example, that you visit the wrong website, or your email is intercepted.
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. [Update 1 Oct: I’ve finally now managed to validate it, see comment.]
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 🙁
We’d like to sign it too.
Since I happen to be consulting at .SE right now, I have pointed out your post to the people here.
Hm. Understanding trust and security has always been tricky for non-experts like me, and I suspect the process will need to be a good deal easier and more transparent before I can be sure of what I need and how to get it – and what benefit it’ll afford me!
Still – you’ve done a good job of diving right in. I shall watch on with keen interest.
I dont know how you can sign a Key which you cant verify. Where is the logic in this?
However I fully agree with your article, this is not the way to establish a trustable private PKI.
@Bernd
On balance, I do believe that the key does belong to the .se registry, and I have signed it on that basis. Although why you should expect “The Russian Mafia” to have anything like a normal key signing policy escapes me at present!
The point is that by linking to a version of the key on the public servers (rather than one on their own webpages) the registry has muddied an already muddy situation even further. They have mixed in all the complexities of what Zimmermann’s “web of trust” can actually provide. My choice of moniker should be irrelevant, but I rather suspect (and indeed intended) that anyone who sees it will fail to analyse the situation correctly.
So basically what you are saying is that they shouldn’t have chosen PGP Inline signatures over PGP/Mime because your e-mail application can’t handle them?
While PGP/Mime is the preferred choice in most situation it comes with it’s own set of annoyances, especially when it comes to webmail solutions. So I think PGP Inline is still a perfectly understandable choice.
I agree about the key though. They should post their key directly on their web. However, that does still not solve the problem with the public keysers and that anyone can upload keys with pretty much any signature, as your rather childish demonstration shows.
@Andrew
The reason that my app can’t handle the inline signature is the way that they’ve chosen to do it — not using multipart and not using the optional storage name parameter. When we developed Turnpike we (Hi Ian! Paul!) spent some considerable time getting Turnpike to interwork with other mail applications, and if anyone was using this scheme we’d have coded it up so that it worked…
… the further reason that the signature didn’t validate (an hour or so messing around late last night has finally enabled me to get it to validate) is the presence of wrapped long lines, non-ASCII characters, and mixed conventions for line endings; all of which must be unpicked “just right” in an appropriate text editor to retrieve the original text that was signed.
The bottom line of this aspect is that there’s a fine RFC specifying how to do MIME + PGP in a way that will interwork. Failing to use that scheme is going to cause trouble for a lot more people than just me.
Hey – I know Måns! He is a nice chap who wears kilt when he volunteers as electrician at rock festivals in the summers.
Just had to say that! 🙂
Thanks for the article!