Subject: [Patient] Welcome to the PATIENT Mailing List

From: Brian Witten <[email-masked]>
Date: Tue, 7 Nov 2017 00:26:12 +0000

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

---

From: Brian Witten <[email-masked]>
Date: Wed, 8 Nov 2017 08:59:55 +0000

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.

[email-masked]

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

Dear All,

With My Deepest Thanks For All That You Do For The IETF, And For The World Through The IETF,
Brian
_______________________________________________
PATIENT mailing list
[email-masked]

---

From: Brian Witten <[email-masked]>
Date: Thu, 16 Nov 2017 03:24:09 +0000

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 <[email-masked]> on behalf of Brian Witten <[email-masked]>
Sent: Wednesday, November 8, 2017 12:59 AM
To: [email-masked]
Subject: [EXT] [Patient] Announcing the PATIENT meeting in Singapore

Dear All,

[email-masked]

Dear All,

With My Deepest Thanks For All That You Do For The IETF, And For The World Through The IETF,
Brian
_______________________________________________
PATIENT mailing list
[email-masked]
_______________________________________________
PATIENT mailing list
[email-masked]
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

---

From: Brian Witten <[email-masked]>
Date: Thu, 16 Nov 2017 03:25:20 +0000

slides attached as promised...

________________________________
From: PATIENT <[email-masked]> on behalf of Brian Witten <[email-masked]>
Sent: Wednesday, November 15, 2017 7:24 PM
To: [email-masked]
Subject: [EXT] [Patient] Slides from the PATIENT meeting in Singapore

Dear All,

Cheers,
Brian

Dear All,

[email-masked]

Dear All,

_______________________________________________
PATIENT mailing list
[email-masked]
https://clicktime.symantec.com/a/1/u7esSEkeDzi9VV6e_pIr8MP0kTnzaC5SC0hc1VY7T-U=?d=TFyj7xWFbynMhF1kQJEv50t9mhT5jM8Y4r6_cdpBY4I2rAmNOUCMUOioKZTDGAsb9ge-_QFOXjGhyHbnjhZECuVzNkuPkiEthTh6k7YT45SqNQRM0OaeeIk6VawJX2rFi_UzHCeba1c9xQHIVUqMIzq-VzG1E_EOtpVWfbWP4pC3GFewPb0kyYChtiH0VvlgLvJjBV_lbWmsY2NdyZ-xMMmZ2OGHt-A1WsE2Lqo8WQLxXJ_IiRCKH2msAiCOafeJW_lZUDPNf0IqhZ6ed0ae0xgu9tYtrGuJYzd5z-X1JUf-7qDqqXHeclRbzp9Mzux1lBYOa8tTlN8GdCaDcWIWEq7ycmtiWSZSeNRzdtZRR2CSRCWdsdGSAUlERiCqQomJ1WyTwxTAItf4U7eP1s2Tw4ZLxrnxGBHe2FsciSgI2SJEqcbXgwKVvKY0HaEKozokGQ%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient

---

From: Brian Witten <[email-masked]>
Date: Thu, 16 Nov 2017 03:27:21 +0000

...plus, as promised, the version with references.

From: Brian Witten
Sent: Wednesday, November 15, 2017 7:25 PM
To: [email-masked]
Subject: Re: [EXT] [Patient] Slides from the PATIENT meeting in Singapore

Dear All,

Cheers,
Brian

Dear All,

[email-masked]

Dear All,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Nov 2017 22:41:37 -0500 (EST)

On Thu, 16 Nov 2017, Brian Witten wrote:

> I'll also very shortly post the slides to this list as promised.

A URL would be better, we can share more easilly (as the archive will
likely mangle the attachment or create a very strange link for it)

> Unless anyone objects on this list, we're working on a more detailed set of notes, Chatham house rules

You can privately do what you want, but Chatham house rules is not
compatible with the IETF Note Well, so anything on this list should
not fall under those rules (and temporarilly working under different
rules for a subset of people seems a bit odd to me). So I am confused
about the "we".

> (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.

I still do not see why I cannot selectively use either a SOCKS proxy or
regular proxy, over regular TLS, to the middleware box / protection
service, on a per-domain basis. That is, you have not convinced me there
is any need for a protocol change. Without a clear need, the exitsing
protocols should not be further complicated.

Paul

---

From: Brian Witten <[email-masked]>
Date: Thu, 16 Nov 2017 04:02:47 +0000

Thank you Paul for the clarification, particularly on the Note Well!

I'm rusty at this since my last IETF was nearly 20 years ago.

In light of your clarification I won't be distributing more detailed notes in case any of the comments were meant for the moment not for eternity.

Re the URL, will do.  Probably next week if not sooner.

On "why is anything more needed," one of the risks is the "malicious CDN" concern framed in Boneh's Stickler paper, and I can walk through the other limits of current middlebox/proxy approaches as well, but I'm happy to focus first on the ask from Stephen, unless you prefer otherwise.

Thanks Again Either Way!!

Cheers,

Brian

________________________________
From: PATIENT <[email-masked]> on behalf of Paul Wouters <[email-masked]>
Sent: Wednesday, November 15, 2017 7:41:37 PM
To: Brian Witten
Cc: [email-masked]
Subject: [EXT] Re: [Patient] Slides from the PATIENT meeting in Singapore

Paul

_______________________________________________
PATIENT mailing list
[email-masked]
https://clicktime.symantec.com/a/1/7-NZRAvvKnLiRMsQn_pvOJLF807sbWToQe7lFzwCgt4=?d=eexAo6dIX-LOqBzrZPtp3kWS2Y4tkAUQuu0Yt0YntK2V5TnEaRSePWV3hU7KkNbhxO1MwNRnpkyKWYobHNq-bixHBef1KMwY1VN4gm8FbqLT_18q642X6zQhzW3iIwqB8VJZtGFLYeWCbUvfs2yUdnRmUP0hdv3SxIOBRwZAEQgKQJbx5zGYlklLU0Hiai9ChCq9mfsY_rHnoygD8VpcTbOIkmyYiXXAvq9F0I1CPKGp3OAhHytTwN3fkWr9hMiXIt5BFjpNNtQoLjxDxUB5WgxaHat5EX8oAV9EqWQKkMi7ZqlGjcZtULdgCG0_WAPAolWlsAd5zrCNMD5NTROlrLlaZgBsvwZpvUQojIDgTF6w8xg-AnMGg-GeSCXlIqPNq2Pe5cRo3jm6rsJ12W4ymP97N6mbvgFk&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient

---

From: Brian Witten <[email-masked]>
Date: Wed, 22 Nov 2017 22:38:12 +0000

Hi Everyone,  I'm just including below, as promised, download links for the same slides sent earlier -
Slides are at http://bit.ly/2iHSKZJ
Also, speaker notes notes are at http://bit.ly/2A1dvJY

From: Brian Witten
Sent: Wednesday, November 15, 2017 7:27 PM
To: [email-masked]
Subject: Re: [EXT] [Patient] Slides from the PATIENT meeting in Singapore

From: Brian Witten

---

From: Brian Witten <[email-masked]>
Date: Tue, 28 Nov 2017 17:16:11 +0000

Hi Everyone,

For any of you wanting to join the WebEx presentation of the PATIENT slides from Singapore, particularly in case you were not able to travel to Singapore for IETF 100, we’ll be presenting them Thursday November 30th, 2017 at 9:00am PST.  Note: this is the normal meeting time for a related IEEE activity interested in the PATIENT discussions, so they are likely to join the call as well.  As always, my thanks to Olaf Bonorden for his leadership in the IEEE and his generously allowing us to use the bridge for the call:

https://mcafee.webex.com/mcafee/j.php?MTID=m30a4dac70591471aabc9aa02193d7f70

Join by phone
+1-866-662-9987 US Toll Free ( other options below ) Access code: 928 066 720

International numbers:
https://mcafee.webex.com/mcafee/globalcallin.php?serviceType=MC&ED=501374167&tollFree=1

Popular Toll and Toll Free Numbers:
Location // Toll-Free Number // Toll Number
United States // 1-866-662-9987 // +1-210-795-1110
United Kingdom // 0800-376-8336 // +44-20-7108-6317
India // 0008-001-6132
Australia // 1-800-001-979 // +61-28205-8113
Netherlands // 0800-023-4635 // +31-2071-88512
Japan // 0066-33-812356 // +81-36868-2627

________________________________
From: Brian Witten
Sent: Wednesday, November 22, 2017 2:38 PM
To: [email-masked]
Subject: Slides from the PATIENT meeting in Singapore

From: Brian Witten

From: Brian Witten