IPETEE?

| Comments (3) | COMSEC
The Pirate Bay guys are floating a proposal for "Transparent end-to-end encryption for the internets". The basic idea seems to be IP-level encryption with an opportunistic, unauthenticated, inband key exchange:
The goal is to implement IP-transport encryption in a way that is transparent both to the IP-layer (including nodes in the network path) and to the applications that benefit from the encryption.

The solution inserts a crypto layer between the IP-stack and application. This could be implemented as a filter hook for an operating systems BSD-socket layer or as a network stack filter (Windows TDI, etc.).

Before establishing a "flow", defined as a new stream for stream oriented communications (i.e. TCP) and a new IP/port tuple for datagram oriented communications (i.e. UDP), key negotiation takes place over the data channel to establish a session key. If the key negotiation fails we fall back to unencrypted mode and just pass the application data untouched, otherwise the established session key is used to encrypt traffic before passing it down the stack and decrypt traffic before sending it up to the application.

This description is extremely sketchy, but it's still possible to get some initial impressions. As usual with amateur designs, this has some odd aspect. First, it looks like they're reinventing everything: both key management and packet formats. Second, they pick an odd set of algorithms, in this case Salsa-20 and AES-CBC with a fixed IV and ciphertext stealing.

But ignoring the details, it's interesting to look at the architecture. IPETEE isn't really isomorphic to any existing design.

Like IPsec, IPETEE lives at the IP layer, but unlike IPsec, where the key management protocol is out-of-band on a specific UDP port the IPETEE key management is in-band, apparently mixed with the application layer protocol. This has the advantage that there's much less of a NAT/Firewall traversal problem, since you don't need to worry about punching a hole through the firewall for the key management protocol. However, if I'm understanding correctly, because the key management data is on the same channel as the data, this means that if you try to connect to a node which isn't IPETEE-aware, you'll most likely cause a protocol error, which doesn't happen with IPsec, where your KMP just times out if the other side doesn't recognize it. Note that one could easily adapt IPsec so that the KMP ran over the application channel instead of on a separate channel.

SSL/TLS, of course, does all its key management (and everything else) in the data channel. So, as with IPETEE, there's no NAT traversal problem. The advantage of IPETEE over SSL/TLS (whether in application or SSL-VPN style applications) is that it will support any protocol that runs over IP, regardless of the transport protocol. It's not clear how big an advantage that is, since pretty much all major applications run over TCP or UDP, and so you can use TLS or DTLS.

The other advantages of IPETEE aren't really architectural, but rather implementation issues. First, unlike SSL/TLS/DTLS style applications is IPETEE is clearly designed to be transparent and automatic, as opposed under application control. However, that's not a protocol issue, but just an implementation issue. It's quite possible to do a kernel/driver version of SSL/TLS—this sort of thing was contemplated when SSL/TLS was first designed, but it didn't take off—to a great extent since one of the major advantages of SSL/TLS was that it could be implementated at the application layer and didn't require any messing around in the kernel or driver layers. There's a tradeoff here between universality and ease of deployment here.

Second, because IPETEE doesn't bother to authenticate either side of the connection, there's not really any endpoint configuration required beyond installing the software. Again, though, this isn't really an architectural advantage. As many have noted, one could easily deploy something like this with either SSL/TLS or IPsec, and IETF even has a working group (BTNS) doing something very similar for IPsec. Moreover, any opportunistic system (one where you don't know whether the other side will do security) has downgrade attack issues, where the attacker forces you down to cleartext. This system is actually worse, since an attacker can also man-in-the-middle you undetectably if there's no credential checking. Also, as Hovav Shacham pointed out to me, if you try to renegotiate with each connection, there are more downgrade opportunities. This can be dealt with to some extent by caching the other side's capabilities, but this interacts unpleasantly with NATs. Again, these are all architectural issues, not implementation ones; you just need to decide what tradeoffs you want.

None of this is to say that this system won't take off, of course, but from a technical perspective it doesn't seem like IPETEE has any major technical advantages that couldn't be easily gained by adapting well-understood existing protocols.

3 Comments

A few clarifications:

"Like IPsec, IPETEE lives at the IP layer"
No, IPSec is an IP protocol, IPETEE is an application layer wrapper totally independent of IP-transport. It could just as well be used over any other network transport.

"one could easily adapt IPsec so that the KMP ran over the application channel"
Yes, but it still wouldn't be equivalent to IPETEE because the transport is different (IP protocol 50, etc.). IPETEE doesn't mess with or even care about the underlying transport.

"one could easily deploy something like this with either SSL/TLS or IPsec"
Not with IPSec, since it isn't transparent to the underlying network (see above). You could certainly do it with a modified TLS implementation, but why carry all that extra baggage when a slim implementation of the bare essentials will do?

This proposal is, as you point out, still a sketch. Actually it is just a brain-dump of a drinking session. It was found and "leaked" by some blog and revealed to the world before it was ready for prime-time (it hasn't even been proof-read). Fine. I'll deal with that. What it seems to be lacking most is the rationale behind the design choices, so I'll try to add that during this week.

/olle (the proposal author...)

One more thing:

"they pick an odd set of algorithms, in this case Salsa-20 and AES-CBC"

What's so odd about these? They were only chosen because they are the currently most widely recommended stream and block ciphers. If you have alternatives you prefer, please explain why (as I said the proposal has yet to see any technical review).

The "odd" AES mode with implicit IVs and ciphertext-stealing was chosen to avoid changing the size of datagrams when encrypting, btw.

Cheers,

/olle

A bigger problem, it doesn't solve the problem the PirateBay needs to solve: How to keep the RIAA or its deligates from detecting pirates on the wire and blocking them!

Because you don't wiretap to do copyright enforcement, you do crawling and graph takedown, and encryption can't stop that.

Leave a comment