I
have mostly come to the conclusion that trying to secure the routing
layer of the internet is hopeless. Protocols like DNSSEC impose pretty
significant costs on service providers and clients/recursive resolvers,
and at the same time don't provide any substantive security guarantees
that I'd be willing to rely on. I still want end-to-end
security—confidentiality and integrity, in particular—of the data
stream, something provided by TLS and support systems around TLS (e.g.,
certificate transparency).
DNSSEC doesn't even try to give me the one thing I'd really like out of the routing layer, which is privacy: it provides a base level of integrity...and that's it.
"Securing" BGP in a similar way would be worth even less, because routing decisions at that level can't even really be checked by clients as they don't have the context to understand why paths are configured with particular costs, nor do they know where state-level actor tap points exist, so it's not like they could sound an alarm on the existence of a suspicious route: how would you define or detect "suspicious"?
It's also worth considering that all widely-used protocols on the internet are built in layers: protocols at each layer are designed to create resiliency and add features beyond those which are provided by lower layers. Just as TCP takes IP and adds reliability and flow control, TLS takes TCP and adds a degree of end-to-end security. This is not simply chance or expediency: there's a reason things are built this way.
Note that I'm not claiming a perfect TLS provides us with all the security we want. The one gaping hole in TLS security that would be solved by a proper security design for the routing layer is that TLS provides confidentiality only of the actual bits being moved around: the metadata (routing information, size of data transferred, etc.) is wide open for analysis. But until something like TOR can accomplish this in a demonstrable (and preferably provable) way in an overlay network subject to constant surveillance, it's actually counterproductive to add some crypto at the lower layers, declare "we have routing layer security!", and call it a day.
Not only that, but the biggest problem with TLS—the trust model and how it is implemented in browsers—is not solved by adding DNSSEC-like security to the routing layer.
So, just to be clear, I'm not opposed to adding security to the routing layer... but it has to provide enough value to balance out the cost. What the TOR/Silk Road debacle tells me is that routing layer privacy is a hard problem: a protocol designed explicitly for privacy over untrusted networks nonetheless was vulnerable to targeted analysis. What makes me hopeless on this subject is that at some level even TOR relies on systems that know where packets are going to end up, so it's not clear that routing layer security of the sort I want is even possible.
DNSSEC doesn't even try to give me the one thing I'd really like out of the routing layer, which is privacy: it provides a base level of integrity...and that's it.
"Securing" BGP in a similar way would be worth even less, because routing decisions at that level can't even really be checked by clients as they don't have the context to understand why paths are configured with particular costs, nor do they know where state-level actor tap points exist, so it's not like they could sound an alarm on the existence of a suspicious route: how would you define or detect "suspicious"?
It's also worth considering that all widely-used protocols on the internet are built in layers: protocols at each layer are designed to create resiliency and add features beyond those which are provided by lower layers. Just as TCP takes IP and adds reliability and flow control, TLS takes TCP and adds a degree of end-to-end security. This is not simply chance or expediency: there's a reason things are built this way.
Note that I'm not claiming a perfect TLS provides us with all the security we want. The one gaping hole in TLS security that would be solved by a proper security design for the routing layer is that TLS provides confidentiality only of the actual bits being moved around: the metadata (routing information, size of data transferred, etc.) is wide open for analysis. But until something like TOR can accomplish this in a demonstrable (and preferably provable) way in an overlay network subject to constant surveillance, it's actually counterproductive to add some crypto at the lower layers, declare "we have routing layer security!", and call it a day.
Not only that, but the biggest problem with TLS—the trust model and how it is implemented in browsers—is not solved by adding DNSSEC-like security to the routing layer.
So, just to be clear, I'm not opposed to adding security to the routing layer... but it has to provide enough value to balance out the cost. What the TOR/Silk Road debacle tells me is that routing layer privacy is a hard problem: a protocol designed explicitly for privacy over untrusted networks nonetheless was vulnerable to targeted analysis. What makes me hopeless on this subject is that at some level even TOR relies on systems that know where packets are going to end up, so it's not clear that routing layer security of the sort I want is even possible.
Comments