[Patient] Welcome to the PATIENT Mailing List

[Brian Witten <[e-mail]>]

Dear All,

Welcome to the mailing list for Protecting against Attacks Tunneling In Encrypted Network Traffic (PATIENT).

We are thrilled to see over half of the world’s web connections encrypted, and we do not want to weaken crypto or TLS in any way.  At the same time, half of the world’s attacks are now tunneling through encrypted sessions, and many endpoints need help protecting themselves against these attacks.  Often they can only get that help from the network.  Fortunately, there are in fact ways for network devices to help protect against the full range of attacks that might be tunneling through encrypted sessions.  Still, for endpoints to get such help of course they need to Trust some entity or service in the network to help protect them.  That entity or service helping protect them might be operating on their behalf, or on behalf of their employer, or some other entity they choose to trust.  However, they have a right to choose who they trust to protect them.  For these reasons, we want to collectively engineer a secure multi-party protocol which:

(a) Helps each endpoint control which parties and network devices are empowered to decrypt traffic to help protect them,
(b) Helps each endpoint see when one of those parties or devices modifies content coming from the other endpoint, such as removing attacks, and see that with a cryptographic audit trail of who changed what where when and why, such as removing attacks,
(c) And does all of the above without breaking or weakening any of the cryptography or cryptographic protocols in any way, including not breaking or changing TLS.

It is important to consider the “delegated protection” model.  In such a model, unauthorized eavesdroppers represent one of at least two crucial threats which must be mitigated.  In such a model, the remote endpoint represents another crucial threat which must be mitigated as that remote endpoint might be malicious even though the endpoint of our care wants or needs to communicate with that remote endpoint.  This model is surprisingly common today.  For instance, server to client web attacks are increasingly common by malicious or compromised websites.  Of course, client to server attacks have been common for years.  More recently, it’s become increasingly common for servers to surveil and profile clients, a privacy threat compounded by servers collaborating through massive advertising (ad) networks for tracking user activities.  Such surveillance through profiling and tracking represents a privacy threat many people would like to see better mitigated.  In fact, it is also a privacy threat that can be potentially mitigated by protection services running in the network.  In all such cases, it’s reasonable for limited endpoints to choose more powerful network services to protect them against such threats.

Fortunately, several starting places exist for protocols to achieve requirements (a), (b), and (c) above.  For instance, with some modifications, it would be good to use the Stickler protocol proposed by A.
Levy, H. Corrigan-Gibbs, and D. Boneh in conjunction with modified variants of unfortunately named protocols such as mbTLS and/or TLS-RAR.  Our vision is for such a protocol to run in parallel to TLS, complimenting it, without modifying or constraining TLS while helping coordinate network protection of endpoints.  To do so, such a protocol should also better inform endpoints of the specifics of network devices available for protection, specifics which the endpoint might care about before empowering such network devices by trusting them to help provide such protection.

With such valuable research accomplished to date in this space proposing a variety of potential protocols as starting points, it’s important to soon engineer a standardized protocol to meet the rough consensus of the IETF for providing such protection more safely than today’s common practices.  Today’s common practices not only fail to meet the three requirements outlined above, but today’s common practices also (1) allow middleboxes to negotiate weaker TLS sessions without advising the endpoint of the risks of the weaker session on the far side of the middlebox, (2) fail to inform the endpoints of how secure the middlebox might or might not be, the manner in which the middlebox itself is safeguarded, and (3) fail to inform the endpoints of the information retention and disclosure policies under which the middlebox is operating.

Clearly a better approach is needed, and urgently.  Network mediation can play a crucial role in protecting people from the server to client attacks that have been used to unmask the anonymity of dissidents speaking up against repressive regimes, dissidents who were then disappeared after the server to client attacks were used to unmask them by compromising their mobile endpoint.  Trustworthy network mediation can play a crucial role in protecting people against such attacks, but today, where endpoints trust middleboxes, there is not yet a standardized protocol for endpoints to understand when those middleboxes are weakening the crypto, changing the content, trusting other middleboxes, and doing other things that might cause the endpoint to not trust the middlebox.

Still, engineering such a protocol is not easy.  Such protocols would need to address a range of use cases including both real-time and post-facto, along with both wide-area and datacenter use cases.  As initial working differentiation of these terms, we’d propose real-time to include blocking of attacks. Post-facto includes both forensic investigation of sophisticated attacks and also audit compliance aka out-of-band decryption. Wide-area use cases include shared networks where the device or entity helping provide protection is only reached across a network operated by and/or shared with other untrusted parties.  The datacenter use case includes networks adjacent to the endpoint and owned by the same party as owning the endpoint.

In engineering such a protocol, it’s important to respect fundamental principles of end-to-end encryption and, at times, similar end-to-end flexibility in route optimization.  On end-to-end encryption, some of the approaches that have been proposed include leveraging the symmetric key determined strictly between the server and client, and then having the endpoint share that symmetric key only with a network device or service which it trusts to help with protection against the remote endpoint.  In addition to preserving end-to-end encryption and accelerating deployment of stronger crypto, it’s also important to preserve end-to-end flexibility in routing whenever possible.  Currently, for attacks tunneling through encrypted network sessions, network based protection is often provided through proxies and the like either embedded in network gateways or datacenters hosting personal-VPN type cloud based services through which all of a client’s traffic is routed.  However, longer term, such protection could be achieved by having such “protection services” running more flexibly in a distributed manner, in hardware protected enclaves and/or Trusted Execution Environments migrating the functionality among Software Defined Networking (SDN) and/or Network Function Virtualization (NFV) enabled equipment.

>From discussions within not only IETF participants, but also people engaged in related discussions in IEEE, UN/ITU, ETSI, and others in this area eager to participate in an IETF process in this area, we believe that there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.) for meeting requirements (a), (b), and (c) described above.  Many of us personally believe that the IETF is the right best place for such work for countless reasons. We are of course very familiar with previous attempts within the IETF, including Explicitly Trusted Proxy and TLS Proxy server among others.
https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 
https://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01

We are also aware of the need for coordination of such work not only with the TLS working group, but also DPRIVE, QUIC, I2NSF, and other IETF efforts, and we believe that an independent WG could be more helpful than trying to do all of this work in any existing working group such as the TLS WG, particularly since the best solution might be a new protocol that compliments TLS, running in conjunction with TLS, without extending, changing, refining, or breaking it, or any other existing protocols already so important to security and proper functioning of the network.

In that the world has already seen anonymous dissidents disappeared after what many would consider repressive regimes used sophisticated server-to-client attacks to unmask their anonymity, I believe that we need a world where both (1) the connections are secure a la great TLS, and (2) the traffic is safe to receive, as vetted by something or someone the endpoint chooses for protection against remote endpoints.

In that context, we are deeply grateful that IETF has allowed creation of this mailing list for discussion of these important topics.  Please let me know anything that I can do to help you or the IETF on this.

With My Deepest Thanks For All That You Do For The IETF, And For The World Through The IETF,
Brian