Session 4 (Middleboxes) -- Paper 1: Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality in TLS

Authors: David Naylor (Carnegie Mellon University), Kyle Schomp (Case Western Reserve University), Matteo Varvello (Telefónica Research), Ilias Leontiadis (Telefónica Research), Jeremy Blackburn (Telefónica Research), Diego Lopez (Telefónica Research), Konstantina Papagiannaki (Telefónica Research), Pablo Rodriguez Rodriguez (Telefónica Research), Peter Steenkiste (Carnegie Mellon University)

Presenter: David Naylor from CMU

Paper: http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p199.pdf

Public Review: http://conferences.sigcomm.org/sigcomm/2015/pdf/reviews/193pr.pdf

The speaker motivated the pointing out two observations:

1. Encryption is increasing (more traffic is moving towards HTTPS)
2. In network optimization is important (e.g. DPI for intrusion detection)

But the issue is that in-network middleboxes cannot inspect encrypted traffic, and users are not willing (rightfully) to compromise privacy and security. One solution is to let the middleboxes perform MITM attack and decrypt the traffic, inspect it, and the re-encrypted. But this is not ideal as it gives middleboxes unrestricted access to all users' traffic. The speaker argued that such unrestricted access is not necessary and middleboxes can actually perform their functionalities with limited view into user's traffic. 

The speaker then talked briefly about TLS and what provides (authentication, secrecy, and integrity) and how TLS + middleboxes is problematic as there is no mechanism to verify middleboxes, no secrecy guarantees past the middlebox, and how middleboxes have unrestricted read/write access.

He then carried on to explain the high level design of mcTLS. mcTLS has two extra requirements on top of TLS: 1)visibility and control, 2)least privilege. mcTLS introduces the notion of "context", which the speaker said they can be seen as tags and showed an example of contexts for HTTP and how most parts of it don't need r/w access:

The speaker emphasized that mcTLS does not support transparent middleboxes, as in both end points are aware of the middlebox and the middlebox ONLY received a key for a context if both ends agree on that.

Finally, the speaker talks about mcTLS's performance and its overhead in terms of data, cpu, and time. mcTLS has a few Kb of data overhead and might hurt when getting small objects. In terms of time, it has the same number of round trips as TLS.

Q: Does mcTLS require clients to have public keys?

A: No

Q: So what do you require the client to have? It's providing something

A: This is actually same as TLS

Q: How do you authenticate clients then?

A: You don't need that for mcTLS. If you need to authenticate clients for example for a paid service, that should be done at the application layer

Q: You made a distinction between authorized and unauthorized middleboxes. Now who gets to decide what's authorized? You're building a system where you can draw that line hard, as oppose to soft. This could be dangerous

A: We decided to leave that to the end point. They have to both decide if they want that middlebox there.

Q: This seems to work well in theory, but it requires all parties to be updated!

A: yeah, all parties need to be updated, but you can always fall back into TLS

Q: but updating apps can be hard

A: yeah but you can build this into a library

Q: Middleboxes will never adopt this! I don’t see what’s the financial win?

A: Some of these mbs are helpful to clients and costumers might want this!

Q: there is 2012 IETF proposals, (?), didn’t really progress behind the draft. Have you seen it? how does it compare to your solution?

A: not very familiar.

Q: is there a solution for client or server to say I want to middle box to interfere with my traffic?

A: absolutely, both end points can deny access to the middle boxes