More on IPETEE

| Comments (2) | COMSEC
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.



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.


Hi again!

"I'm still not sure what layer IPETEE runs at."
Between the network stack and the application layer. E.g. between TCP and the socket-API or (on Windows) as a TDI filter driver between the TDI client and TDI provider.

"you can simply use TLS/DTLS"
There is nothing preventing IPETEE from adopting TLS/DTLS framing, the proposal does not contain any details on key-exchange or cryptostream framing. Our initial assumption that the increased overhead of DTLS framing would create problems with fragmentation in UDP datagrams might be totally wrong and not an issue in the real world. Please, keep in mind that the proposal is not a finished work but a rough draft.

"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"
That's correct, please remember the design goals where the attack model is clearly specified. IPETEE is opportunistic encryption meant to protect against PASSIVE eavesdropping only, message integrity is not guaranteed (just as in unencrypted, regular IP). We are not trying to solve all the "problems" that other systems (TLS/DTLS, IPSec, etc.) are.

"if you're going to use a stream cipher like Salsa20 for datagram transport"
Which we are NOT proposing, the stream cipher is for stream-oriented flows only, where cipher-stream keying doesn't present the same overhead problems as in datagram-oriented communication.

"if you want zero data expansion the standard procedure with AES is to use counter mode, not AES-CBC"
That's interesting information and definitely something we will have to investigate. Thanks for the tip!

"It's not clear what the advantage of Salsa-20 is"
Salsa20 is proposed as the cipher for stream-oriented communications where a block cipher would introduce latency problems. It is currently one of the most recommended stream-crypto algorithms and was chosen because of the recent findings of the ECRYPT eSTREAM project ( Do you have a proposal for a better stream cipher?

"I haven't heard any really compelling arguments why something entirely new is needed."
Fair enough. The "new" concepts in IPETEE that are not being addressed by other solutions are zero-configuration opportunistic encryption with full transparency to the network and application layers (please read part 1.2.2 of the proposal-draft for reasoning). There are some other proposals for opportunistic encryption but they all have problems with transparency at the network layer. The number one goal of the IPETEE design is "if it worked without IPETEE, it should work with IPETEE", encapsulation at the network layer violates this design goal so IPSec, GRE and things like that are out. TLS/DTLS is the closest to our design goals and IPETEE might actually turn out to be a kernel implementation of TLS/DTLS with an anonymous key-exchange option.

Your input has been much appreciated, actually it's the only constructive criticism we have yet to receive... If you wish to continue the discussion in email, you have my address.



ABOVE TCP? Then thats TLS.

Only caring about a passive adversary? Thats false security. Anytime you have a passive adversary you can have an active adversary on today's networks.

The latency of AES? Don't make me laugh. AES can easily be run at 1 Gbps on today's processors, which means ~8 M-Encryptions/sec. So even if you were just doing a stream cypher on 1 byte packets, thats 64 Mbps.

You could easily get exactly what you want by doing an SSL/TLS, just say "OK" to self signed certificates.

Finally, your proposal is USELESS for your problem. This is all about protecting your pirated material from manipulation. It WON'T WORK. Period. End of story. Graph takedown and the like still work fine, traffic analysis for traffic shaping still works fine, etc.

You want to do it right? Just do IPSec over a UDP (IP-in-IP) tunnel. You really want to protect the integrity of the TCP header.

Leave a comment