Lost in security
One of the last documents I’m reviewing before my term on the IESG ends is LOST, a protocol for locating the right service center to handle 9-1-1 calls. It illustrates one of the easiest security mistakes to make: insecure binding. Here’s how it works.
You know what domain you are in. You look up using U-NAPTR to convert that domain and the label “lost” into a URI. You expect the URI to be an HTTPS URI and go to the LOST server at that address.
Finding the right server is important. An attacker could cause your 9-1-1 call to be intercepted by the attacker, or could misdirect critical calls. So, how do you know you have the right server? The current spec says you follow the rules in RFC 2818. You take the hostname from the URI and expect it to be in a certificate that you get from the server you talk to. That certificate is signed by someone you trust. So, you have a binding from the hostname to the public key of the server you’re talking to.
There’s one big problem. How do you know you got the right hostname? You just got this URI out of DNS. There’s dnssec, but you’re not actually using that today. Currently in the spec, you have no way to actually secure that the DNS information you got is the one you expect.
The problem is one of binding. For authentication to be secure, you need to establish a binding from some name that you trust to the party you’re talking to. That binding needs to be trusted. With LOST, the name that you have is your domain name. However, today, there is no way to trust the binding of that name to the result from DNS, so you don’t actually have a way to authenticate that you are talking to the right party.
Problems can get even worse in situations where you don’t have a name you trust. Let’s say you have some GUI that allows you to pick the service you want to talk to in a peer-to-peer environment. The services are described by user friendly strings. You pick “Bob’s computer” from the list. How can you trust that name? What stops anyone from going into their computer and renaming it “Bob’s computer?” For systems like the web, we can come close to solving the trustable name problem because entities can prove to companies like Verisign that they are permitted to use the domain name they are using. However in systems where people get to choose their own name and where there aren’t good ways to figure out if the person who chose the name is reasonably allowed to use that name, it becomes difficult or impossible.
All hope of security is not lost in this sort of situation, but there are attacks you cannot protect against. You can do things like make sure it is the same “Bob’s computer” that you’ve talked to in the past. Assuming of course that Bob never needs to reinstall or replace his computer.