[TLS] FW: [saag] Announcing the PATIENT mailing list & meeting in Singapore

["Salz, Rich" <[e-mail]>]

Of interest here

From: Brian Witten <[e-mail]>
Date: Wednesday, November 8, 2017 at 9:18 AM
To: saag <[e-mail]>
Subject: [saag] Announcing the PATIENT mailing list & meeting in Singapore

Dear All,

For anyone interested in Protecting against Attacks Tunneling In Encrypted Network Traffic (PATIENT), I’m announcing both a meeting below, and mailing list, further below.  Intent of PATIENT is to create a secure multi-party protocol for making such protection far safer without modifying, constraining, or breaking TLS in any way, a protocol complimenting current TLS including TLS 1.3.


Intent of PATIENT is to do so in light of both (a) vulnerabilities in today’s common approaches, and (b) huge growing number of attacks tunneling in encrypted traffic, already hurting billions of people, sometimes with dire consequences for their privacy, freedom, & physical well being.


The meeting will be:
** When: Wednesday, November 15, 8pm<x-apple-data-detectors://0>, shortly following the plenary.
** Where: Orchard Room of the Convention Center where the IETF Meetings are being held.

I note that pre-conceptions have severely polarized a number of past attempts at solving problems similar to this, and without better standards for such protection, security suffers in many ways, including challenges safely rolling out important new protocols like TLS 1.3 as quickly and as widely as we’d all like.  We seek a “middle” ground that is not a sacrifice by either side but rather hopefully a best of both worlds.

If you are wanting to protect against attacks tunneling in encrypted traffic, and wanting to make such protection far safer from both security and privacy perspectives, please join us for this meeting, and please join us in helping keep discussion constructive and respectful of people with widely differing views.  I believe we all want to make the Internet and world safer.

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

[e-mail]<mailto:[e-mail]>


Begin forwarded message:
From: Brian Witten <[e-mail]<mailto:[e-mail]>>
Date: November 8, 2017 at 12:59:55 AM PST
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 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]<mailto:[e-mail]>

From: PATIENT <[e-mail]<mailto:[e-mail]>> on behalf of Brian Witten <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 6, 2017 4:26 PM
To: [e-mail]<mailto:[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]<mailto:[e-mail]>