Dan Kaminsky's Blog

Right.  Enough theory.  Lets get down to bits and bytes.  As of 1.02, the basic name/key mapping for http://www.hospital-link.org looks roughly like:

http://www.hospital-link.org IN TXT “v=key1 ha=sha1 h=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15”

Lets break this down:

• http://www.hospital-link.org:  We’re attaching the key record directly
• v=key1:  The subtype of this TXT record is key, version 1.
• ha=sha1:  The hash algorithm used on the attached data is SHA-1.
• h=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15:  When connecting to http://www.hospital-link.org, a certificate will be presented.  The hash of this certificate will be f1d2d2f924e986ac86fdf7b36c94bcdf32beec15, as per the hash algorithm declared in ha.

Yes, it really can be this easy.  One of the expensive aspects of X.509 was learning how to generate and maintain certificates.  Doing the above is much simpler.

Of course, that’s not allowed to be the end of the story.  What else might we put in there?

(Later, we’ll discuss the finer points of this particular grammar, effectively a space delimited flat key-value pair architecture.   There are other approaches, and I could be convinced to shift to them.  But this is what we’re using now, mainly for parity with most everything else using TXT.)

The power of DNSSEC is the ability to bootstrap trust.  There’s a very interesting technology out there called Strict-Transport-Security, that’s slowly being integrated into each browser.  Strict-Transport-Security, or STS, enforces the use of TLS when accessing web sites.  In effect, it turns off insecure HTTP.

“The server at http://www.foo.com will have the following public key” is not, seemingly, a particularly complicated message to express.

It can become one, though. Should the public key be encapsulated by an X.509 certificate? Or should it be expressed directly? Perhaps we should instead insert a hash, to save space (a principle we’ve reluctantly abandoned with DNSSEC, but bear with me). Do we hash the key or the cert? Which algorithms do we support?

And that’s just semantics. What of syntax?  Do we encode our desires with strings? Or magic numbers?

And just how do we manage upgrades over time?

So there are engineering challenges. And, as it turns out, when I say there are no right answers, that means there are no right answers. There are only “ways we did things in the 90’s”, or “ways we did things in the 00’s”, and a battle over which disasters we’d prefer not to repeat.

Finally, as if this discussion wasn’t meta enough — the lack of dead bodies in computer “engineering” is the thing that puts quotes around computer “engineering”.  The pain of failed IT projects, even to the tune of billions of dollars, strangely drives far less change than the dead bodies, past and future, that haunt all other engineers.  (Did you know you can’t even call yourself an engineer in Canada without a license?  There, you’re an Engineer.  Because you might kill people.)

We’ll return to the DNSSEC Diaries soon, but I wanted to talk about a particularly interesting optical illusion first, due to it’s surprising interactions with DanKam.

Recently on Reddit, I saw the following rather epic optical illusion (originally from Akiyoshi Kitaoka):

What’s the big deal, you say?  The blue and green spirals are actually the same color.  Don’t believe me?  Sure, I could pull out the eyedropper and say that the greenish/blue color is always 0 Red, 255 Green, 150 Blue.  But nobody can be told about the green/blue color.  They have to see it, for themselves:

(Image c/o pbjtime00 of Reddit.)

So what we see above is the same greenish blue region, touching the green on top and the blue on bottom — with no particular seams, implying (correctly) that there is no actual difference in color and what is detected is merely an illusion.

[And, we’re in Forbes!] [DanKam vs. A Really Epic Optical Illusion] [CNet]

So, for the past year or so, I’ve had a secret side project.

Technically, that shouldn’t be surprising.  This is security.  Everybody’s got a secret side project.

Except my side project has had nothing to do with DNS, or the the web, or TCP/IP.  In fact, this project has nothing to do with security at all.

Instead, I’ve been working on correcting color blindness.  Check it out:

These are the Ishihara test plates.  You might be familiar with them.

If you can read the numbers on the left, you’re not color blind.

You can almost certainly read the numbers on the right.  That’s because DanKam has changed the colors into something that’s easier for normal viewers to read, but actually possible for the color blind to read as well.  The goggles, they do something!

So, I think it’s fairly elegant and straightforward to put a key into DNS like so:

http://www.hospital-link.org IN TXT “v=key1 ha=sha1 h=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15”

On connecting to http://www.hospital-link.org over TLS, a certificate will be delivered.  Traditionally, this certificate would be interrogated to make sure it was signed by a trusted certificate authority.  In the new model:

• If DNSSEC says the above TXT record chains to the (one) DNS root, and
• The subtype of the TXT record is key1, and
• The SHA-1 hash of the delivered certificate is precisely f1d2d2f924e986ac86fdf7b36c94bcdf32beec15, and
• TLS is happy with the public key in the certificate

…then the connection is considered authenticated, whether or not a CA ultimately signed the certificate.  That’s it.  Move on with life.  Cheap.

Can it really be this easy?  I’ll be honest, some people aren’t the biggest fans of this design.  Implementers like it.  Ops guys like it.  I like it.

Some old school DNS people do not like it.  They don’t want to see everything shoved under a single record type (TXT or otherwise), and they don’t like the idea of a seemingly unstructured textual field containing anything important.  Heck, they even wrote an Informational RFC on the subject. The core arguments in this doc:

• No semantics to prevent collision with other use
• Space considerations in the DNS message

It’s really not a great RFC, but these aren’t meaningless concerns.  However, the heart of engineering is understanding not just why systems succeed, but why they fail.  Lets talk about why, despite the above, I’m convinced public keys in DNS should be encoded as TXT records.

It has come to my attention that there are forms of writing that do not fit into 140 characters.

I intend to explore them.

This should be interesting.  For the last two years, I’ve been studying DNSSEC — what it is, what it can be, how to make it useful.  Much of what I’ve learned is dotted across the slide decks cited on the right of this blog.

Slides are not papers.  And there’s quite a bit that hasn’t made it into the decks at all.

So I’m going to do something I hope you’ll find useful:  I’m going to blog, in occasionally excruciating detail, the design decisions behind my use of DNSSEC in the Phreebird Suite.  I’m just one engineer, and I won’t always be right.  But hopefully these writings will shed some light on why I switched sides, from someone who thought DNSSEC was too much work for not enough benefit, to somebody who’s decided this is a major shift in the Internet’s ability to deliver secure, scalable, affordable systems.

It is not enough to deliver security.  We must, as a community, learn how to deliver security cheaper.  Like or not, we compete with insecure, and insecure is winning.

DNSSEC gives developers the ability to authenticate small bits of trusted data in a namespace that transcends organizational boundaries.

That’s great, because application developers have a real problem authenticating across organizational boundaries. PKI based on X.509 was supposed to fix this, but a couple billion dollars in failed deployments later, it’s become painfully clear:  X.509 is really quite expensive and painful.

But developers don’t have a problem doing DNS lookups — complex as distributed databases are, DNS operations coalesce into a small bit of code that’s completely abstracted away.  If developers could authenticate peers, as easily as they could look up an IP address — well, we’d see a lot more authentication.

And a lot fewer password prompts.

But — to be plainly honest — DNSSEC was not originally designed for user applications to validate just any small bits of trusted data.  The original vision was somewhat constrained to validating IP addresses being sought after by a special subset of systems known as Name Servers.

That’s OK.  Believe me, Tim Berners-Lee had no idea when he originally designed much of the web, that practically every page delivered would be dynamically generated from some managed language like Java, C#, or PHP, or would come from complex, worldwide load-balanced Content Distribution Networks.  But there was nothing in the protocol that required pages be static files on a hard drive somewhere.  And look what you could do, if you just dreamed a little bigger…

(Hehe.  This is a fun post.  Hopefully it annoys the W3C and Security communities equally.)

Just to go on the record: I’m just not all that concerned with new security threats from HTML5. Frankly, minus WebGL, HTML5 in 2010 gives us roughly the functionality that Flash gave us in 2004, but with oddly less polish.  (I’m not kidding:  They’re still trying to figure out how to correctly implement full screen video.)

From a security perspective, that means whatever is scary about HTML5 has already been in place, in 99% of browsers, for half a decade.  Not that that means we’ve attacked, or fixed it all — we in the open security community aren’t exactly known for our speed in finding issues.  But I can’t say I’ve seen much in HTML5 that’s made me nervous, at least relative to problems that already exist in HTML4 and Flash (to say nothing of Java).

What does however bother me is the lack of security technology in HTML5.  The performance guys got goodies.  The artists got goodies.  Even the database guys got goodies — they’re getting SQLite in every browser!  Meanwhile, Cross Site Scripting and Cross Site Request Forgery attacks remain endemic to the web, and fixing them remains embarrassingly expensive.

The real problem with HTML5 is not what risks it adds.  It’s what risks it doesn’t even attempt to remove.  I don’t think we can even blame W3C for this — who, in the security community, has been willing to spend the years necessary to push a spec through?  Thus far, not enough of us.

In the long run, if we’re going to actually fix things, this is something we’re going to have to do more of.  I of course have my own thoughts on what to do about these endemic attacks — I think we need better session management — but actual participation is probably more important than a random slide deck and some code.

Been recovering some old writings that never got posted.  Back in August, we were talking  a lot on Full Disclosure about DLL hijacking.  The question of what represents a bug, is actually more complex than people realize, so I weighed in.  I’m responding to Matt from AttackVector.org, and he’s just posted another attack, this one an AutoRun variant.

Sure, but you have the same problem most of the other DLL hijacking exploits have:

There’s no security boundary that says that what appears to be a.ppt, actually is one.  The attacker controls both the icon and the filename.  That’s the case from a network share, that’s the case from a USB mount, that’s just the way it is.

Here’s the larger picture:

These are unusually interesting findings.  On the one hand, you have arbitrary code execution, generally the gold standard for vulnerability.  On the other hand, operating systems *by definition* execute arbitrary code  The question is whether they’re supposed to execute code in this particular context.

The answer is not actually obvious.

The specific boundary at play seems to be the document boundary.  There are very popular file formats that we’d like to be able to read and view, without running any embedded code inside — powerpoint files, for instance.  In the proposed scenario, the user has double clicked a file from a remote share.

Calc pops up.  Clearly a vuln, right?

Here’s the problem:  How could this boundary ever be maintained?  The user has no actual way of knowing that the file he’s clicking on is, in fact, a PowerPoint document in the first place.  It could just as easily be a.exe, faking its icon.  And every major operating system has been hiding file extensions for years.

Worse, even if extension weren’t hidden, its not like applications have any sort of “safety contract” when executed from the desktop.  Some formats have very clear mandates, inherited from being trafficked via email.  Others are outright scripting languages and are fundamentally designed to execute arbitrary code.

The web has developed a very clear security model:  If you can parse it zero click from a web site, it’s required to stay within the browser sandbox.  The desktop has no such model — some formats are ‘safe’, others aren’t.

There was some talk about whether PSD was “vulnerable” to this flaw.  The complexity comes from the fact that, for all we know, opening a PSD file executes arbitrary scripts by design.  Why shouldn’t it?  Not everything is a web browser.

So, it’s not that this is a weak bug or a massive bug.  It’s a characteristic, that has managed to make the otherwise unambiguous proof of concept — popping calc — ambiguously problematic.  That’s actually impressive, if a bit meta.

We’ll probably see some unambiguous attacks pop up, but they haven’t yet.

They still haven’t, though I don’t expect this state to last forever.

Well, I didn’t get to make it to SIGGRAPH this year — but, as always, Ke-Sen Huang’s SIGGRAPH Paper Archive has us covered.  Here’s some papers that caught my eye:

The Frankencamera: An Experimental Platform for Computational Photography

Is there any realm of technology that moves faster than digital imaging?  Consumer cameras are on a six month product cycle, and the level of imaging we’re getting out of professional gear nowadays absolutely (and finally) blows away what we were able to do with film.  And yet, there is so much more possible.  Much of the intelligence inside consumer and professional cameras is locked away.  While there are some efforts at exposing scriptability (see CHDK for Canon consumer/prosumer cams), the really low level stuff remains just out of reach.

That’s changing.  A group out of Stanford is creating the Frankencamera — a completely hackable, to the microsecond scale, base for what’s being referred to as Computational Photography.  Put simply, CCDs are not film.  They don’t require a shutter to cycle, their pixels do not need to be read simultaneously, and since images are actually fundamentally quite redundant (thus their compressibility), a lot can be done by merging the output of several frames and running extensive computations on them, etc.  Some of the better things out of the computational photography realm:

• Flutter Shutter Photography:  If you ever wanted “Enhance” a la CSI, this is how we’re going to get it.
• Light Field Photography With A Handheld Camera: What if you didn’t need to focus?  What if you could capture all depths at once?

Getting these mechanisms out of the lab, and into your hands, is going to require a better platform.  Well, it’s coming 🙂