COMSEC: July 2008 Archives

 

July 14, 2008

In the comments section, Olle (the proposal author) responds to my comments on IPETEE:
"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

I'm still not sure what layer IPETEE runs at. If you're running HTTP does IPETEE run above or below TCP? This does matter, since if it's the former you can simply use TLS/DTLS, whereas if it's the latter, you need to do something new, though it may be quite modest, like a framing layer for DTLS/TLS. With that in mind, it's not clear to me how one makes a system that does per-flow keying but lives below TCP/UDP, since the concept of flows (in IPv4) is primarily one that exists at the TCP/UDP level.

With respect to the point about "why carry all that extra baggage when a slim implementation of the bare essentials will do?", there are a number of kinds of overhead here. At minimum, there's the cost of design and implementation, code size, CPU, and data size on the wire. It's true that you can reduce to some extent the code size and on-the-wire data size by doing a special purpose design (though this is less than you'd think in terms of code size, since people tend to use OpenSSL as their crypto implementation, which means that unless you're pretty careful you end up eating the code size anyway), but (1) code size isn't that important in most settings and (2) this comes at a really high cost in terms of design and implementation. Designing and implementing a good cryptographic protocol is hard, even for experts, and so doing one that isn't flawed is requires some serious thinking. And of course you can do a far more efficient implementation of SSL/TLS than OpenSSL in terms of code size if that's what you're optimizing for. It's not clear that you can do that much better with a custom protocol.

As far as on-the-wire data size and CPU cost, TLS/DTLS isn't optimal, but there's not that much room for improvement. There are five contributors to TLS/DTLS overhead:

  • The header (5 bytes)
  • The sequence number (DTLS only) (8 bytes)
  • The IV (8-16 bytes)
  • The MAC (10-20 bytes)
  • Padding (CBC mode only, 1-16 bytes)

You can reduce this somewhat without compromising security. I'm not going to work through the details here, but there's a certain minimum amount of overhead you need: a length field, a MAC to provide integrity (encryption wihtout integrity is dangerous business), and an IV and probably a sequence number if you're using datagram transport. The IPETEE claims to use a fixed IV and doesn't mention anything about a MAC or sequence number. This probably isn't safe except under fairly restricted attack models. You need to worry about both integrity attacks and pattern attacks from the fixed IV. (Incidentally, if you're going to use a stream cipher like Salsa20 for datagram transport, you need some method for using different keystream sections for each datagram or there are really serious integrity problems). The CPU requirements are similarly fairly constant.

WRT to the question of ciphers: if you want zero data expansion (and, as noted above, you generally do need *some* overhead) the standard procedure with AES is to use counter mode, not AES-CBC with ciphertext stealing. It's not clear what the advantage of Salsa-20 is, but it's not an algorithm that's commonly used in any protocol I'm familiar with. That's not to say there's necessarily anything wrong with it, but it's also not clear to me what the advantage is; standard procedure would be so stick with AES-CTR.

So far, I haven't heard any really compelling arguments why something entirely new is needed.

 

July 13, 2008

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.