[Patient] Slides from the PATIENT meeting in Singapore

[Brian Witten <[e-mail]>]

Dear All,

First, please let me thank everyone who participated in last night's discussion.

As both feared and expected, the discussion was quite divided.  Still, with roughly 60 people in the room at any time, and 90 people joining throughout the two hours, I was glad to see so many experts & leaders engaging in this important discussion, bringing the diversity of viewpoints crucial for such a discussion.  Thank you again.

Stephen Farrell had a great and constructive "ask" to assemble the data, particularly verifiable data, into an internet draft on the merits of third party security, particularly third party network security.  I'll be doing this over the next few weeks, so I'd welcome any data, particularly verifiable data and statistics, beyond the data to which I already have access.  Feel free to ping me on email 1:1 if you'd like to contribute.

I'll also very shortly post the slides to this list as promised.  For those of you who could not be here in Singapore last night, or missed the slides and joined only the Q&A as the plenary ran so long, I'll be presenting these slides again for discussion by Webex November 30, 9am US Pacific, specific webex link to-be-announced on this list next week.  Please also let me know 1:1 if you'd like a more detailed set of notes from last night's discussion.  Unless anyone objects on this list, we're working on a more detailed set of notes, Chatham house rules, capturing comments strictly without attribution, and happy to share next week unless anyone prefers otherwise.

As always, please feel free to reach out anytime with any questions or concerns.  As mentioned yesterday in my opening comments, the notion of network devices inspecting encrypted traffic to protect endpoints is understandably controversial, with clear risks.  I'm happy for the next step to be an internet draft that assembles the data on why such an approach _might_ be needed in some cases despite the risks.  Still, I'm happy to connect with anyone on this well before that.

Either way, you have my deepest thanks for all that you do for the IETF, and for the World through the IETF.  Thank You Again!

Cheers,
Brian



From: PATIENT <[e-mail]> on behalf of Brian Witten <[e-mail]>
Sent: Wednesday, November 8, 2017 12:59 AM
To: [e-mail]
Subject: [EXT] [Patient] Announcing the PATIENT meeting in Singapore
  

Dear All,

For anyone interested in Protecting against Attacks Tunneling In Encrypted Network Traffic (PATIENT), we'll be having a meeting in Singapore.
 ** When: Wednesday, November 15, 8pm, shortly following the plenary.
 ** Where: Orchard Room of the Convention Center where the IETF Meetings are being held.

This side meeting is akin to "bar BOF" in preparation for hopefully hosting a full Birds of a Feather (BOF) meeting at IETF 101 in London in a few months.  Please feel free to directly let me know any questions or concerns.

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

[e-mail]

From: PATIENT <[e-mail]> on behalf of Brian Witten <[e-mail]>
Sent: Monday, November 6, 2017 4:26 PM
To: [e-mail]
Subject: [EXT] [Patient] Welcome to the PATIENT Mailing List
  

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.

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
_______________________________________________
PATIENT mailing list
[e-mail]
_______________________________________________
PATIENT mailing list
[e-mail]
https://clicktime.symantec.com/a/1/MqpjARURSrBQvzQXBbSdXpk0YlaYJOUnJ1zXATRb8fY=?d=tZSBsTk5ZrDAVuYcQoAyKtZ4l3mUF8gsnIFA1Kb2na_qi0RhviWWw8dFuRca9pup_hy2tW4ha5j7K0FmW3JbA_NE-ic-2HuBos-teTqp1kn5GtqvrC9TYtSKU_NICoYm6YwSM3kas3m5cQGYz3vS4l80kXildr347ZwYrJs2MGrODzdbNdL3hnT_yUECZ14mGUe49yQ78X_c2PHsp9J1OBBILAoQJjMezBIR6kni2HjQCTcfM55DgS3HF_x_EJPnm82PH9Q8-kX1IaTWG9lsegAikSnK1t7NA_X3ibccoY6hnS465Cp7BHYhLUtkUObjv3kH2nVcrYOA4UX7IS4tY-h4oPqzTl9rnrKr2vOQRVAMEx4q1xPjfAwKj1Ib5M1e5aFeg-XnbnAAYI0N_iNZW4AzwP92AhmWxivN48U43BPvgycwFyk8pVbQmypLrjXs&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient