Re: [Patient] [EXT] Slides from the PATIENT meeting in Singapore

Brian Witten <brian_witten@symantec.com> Thu, 16 November 2017 03:27 UTC

Return-Path: <brian_witten@symantec.com>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0321A127275 for <patient@ietfa.amsl.com>; Wed, 15 Nov 2017 19:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvWGQD9Fg5vc for <patient@ietfa.amsl.com>; Wed, 15 Nov 2017 19:27:41 -0800 (PST)
Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEB812946A for <patient@ietf.org>; Wed, 15 Nov 2017 19:27:40 -0800 (PST)
Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat10.net.symantec.com [10.90.75.10]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id DD.CF.62423.AA50D0A5; Thu, 16 Nov 2017 03:27:39 +0000 (GMT)
X-AuditID: 0a5af81a-bccd09c00000f3d7-b8-5a0d05aa48f8
Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat4.net.symantec.com [10.90.75.4]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id A2.52.04178.8A50D0A5; Thu, 16 Nov 2017 03:27:37 +0000 (GMT)
Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 15 Nov 2017 19:27:27 -0800
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.128.3) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 15 Nov 2017 19:27:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EgXlsMEhUzMowmTFrs2UnaKHwqEi6za/x+ilk0ZZq2U=; b=WF0HwzaeUBbsja1o22Z8WCWeA8HiR0ci9GEGMG9UkZ12CfPkWHH4f5TnI31cEKOYAZ6vFgsf02+QgvSdk/oy66VfG4Bs2ATRxuI4AunnQXddwgDL1iV8rQyncbC5bQ4UL+qWnZX7SRZ1GrQZhQKBAinSGWDW837J5982EsoYldE=
Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1486.namprd16.prod.outlook.com (10.175.4.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Thu, 16 Nov 2017 03:27:21 +0000
Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0218.011; Thu, 16 Nov 2017 03:27:21 +0000
From: Brian Witten <brian_witten@symantec.com>
To: "patient@ietf.org" <patient@ietf.org>
Thread-Topic: [EXT] [Patient] Slides from the PATIENT meeting in Singapore
Thread-Index: AQHTXopdtzLxyoB5okmgmlUqi815LqMWV8TbgAAASDg=
Date: Thu, 16 Nov 2017 03:27:21 +0000
Message-ID: <MWHPR16MB1488977A3871D394978F6C36932E0@MWHPR16MB1488.namprd16.prod.outlook.com>
References: <MWHPR16MB148817B4DA4B82B793D44DB493510@MWHPR16MB1488.namprd16.prod.outlook.com>, <MWHPR16MB14882E7612CB8A1EEDEF73C593560@MWHPR16MB1488.namprd16.prod.outlook.com>, <MWHPR16MB1488343E419A6EC03325F78C932E0@MWHPR16MB1488.namprd16.prod.outlook.com>, <MWHPR16MB1488BE16CDA6AC3977AE4A19932E0@MWHPR16MB1488.namprd16.prod.outlook.com>
In-Reply-To: <MWHPR16MB1488BE16CDA6AC3977AE4A19932E0@MWHPR16MB1488.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [2001:67c:370:128:8412:f29c:9419:500]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR16MB1486; 6:Jvz4ObZF6B5y8y18tSJxKlC8Ers3Nt2c/yKw40+yu6BJU2es8gSyS19fXWJH/6IwHZEkkJWNloSGPj/i1XaqoTKgaeMEWL3c8Ve/vQjDIrH0q01rSjGkNQ4wBXmEzpPAhtv62H7EidutW+h2Dl6fZw22c5f5bBxulJyKOICt4l8nwcmNsDXcdupxzCItQcCg6JiLyoZ/R0j6241TKNRlMHckGzRdVOlkuA/snKbBJjPTo5DkdHW90vokeyHfXGvrt1TOKNnQYJkEN8OU5USS98J1FI8xoxJZ+AKT0sD4f2rPO1Zw+GHvrcpwlcdMXTJMgczKBnTSXyReAxq24aFlSmER5qsZsc3pbo4AMr9QThc=; 5:ZWDq/h4acGUvSEQMqlj1dB3ZwJRr9j87Vg5LwMUkQOiMaExrrkYZ64LCod+/bC5uvDCasXmDs8FMStssq8yaGgcV6o3+wQNS1C+Nd85RX7jy4fOQDvSqyWbuo1itmgqsr9aio4UD1r6PGTQGohv129wg8tUpCUMW3H+Ntqax1FM=; 24:rNEDg+lPYuCIFu6OeKVFhZM9LURKBCI577iKEYBBysfwOJkJjl3ZD0gxCoF18J1KNh1uz5I7PIO4IyjCZAaVS9cD7MmJ2t91T9A9NBj1Fnw=; 7:dWIR8lq+WvG54MzV3lyXVqa/0CNByA9dwIKkdehCdEiBxD9FDy4TE5K56UbuAdAAFKODkXt8PA7lPWXN49aaYPF8YkjfGtWaxVwRWnZaS6xEnLJzwy5wmszK1eIbOIF9Wkb2qQaNw81SWliBgSmXL0T5bmHZwkEmg/4WGcZhVB0n7074r2zUbWj3A4dqy7Eg4rgLwrRbkGXF1wmsEqOjBS1FofjpJ+LGUBrOd6ETtxXaNuIEWS8zNFL0Q8oJpko3
x-ms-office365-filtering-correlation-id: 4e216f05-ca72-4b7a-5bf8-08d52ca1f2a9
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:MWHPR16MB1486;
x-ms-traffictypediagnostic: MWHPR16MB1486:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=brian_witten@symantec.com;
x-microsoft-antispam-prvs: <MWHPR16MB1486A5A80C906CD9DA684444932E0@MWHPR16MB1486.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(244540007438412)(192374486261705)(100405760836317)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR16MB1486; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR16MB1486;
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(69224002)(52254002)(189002)(199003)(68736007)(478600001)(10290500003)(3660700001)(8936002)(53546010)(93886005)(3280700002)(99286004)(575784001)(86362001)(6246003)(966005)(102836003)(97736004)(2940100002)(2906002)(33656002)(6116002)(189998001)(53936002)(6506006)(105586002)(6436002)(77096006)(106356001)(2900100001)(5660300001)(2501003)(74316002)(25786009)(7736002)(305945005)(5640700003)(8676002)(1730700003)(81156014)(81166006)(9686003)(55016002)(6306002)(5890100001)(76176999)(54356999)(50986999)(99936001)(2950100002)(6916009)(229853002)(2351001)(7696004)(101416001)(316002)(14454004)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1486; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_002_MWHPR16MB1488977A3871D394978F6C36932E0MWHPR16MB1488namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e216f05-ca72-4b7a-5bf8-08d52ca1f2a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 03:27:21.1429 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1486
X-OriginatorOrg: symantec.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed7LNsdWr8v0sMhqGJHiXBYkEeIXu6lgHxJcSr3qi4q66Tat ZYRaoCmWlKKNZDNFTTNyRBqk2XSVWt4qJJnZal28IWjlzAvt3TuhLw+/c/7n+Z9zHh4BLnlP SgXpKh2jUdGZMp6QECqjhMGtpFipuNnHC5vuORiBTjQ0rGCxSCk8msJkpucxmpDw88K0X2O1 ZPbGYCd+0TJhwQrQWGUbXoq8BEAdgh/PrPxSJBRIqCUENRUtaFPo+9COc8IyAtO7RU9gRTB7 q8MT/EQwaJ/ksQFBXcfB9LCGxylVGFidA3zWTEL1ITCbo1nmUXKwrttIln2o/fDq/rx7km3U SVgr6sC4/Cm4MWHy1ByBlaHXBMsEtRd6ZhvdA4qpBFiY/IS4ZmMYFNUa3IIXlQiF1Rs8lhHl C8sDD9ymOOUHEw4jxm3nA/bRQR7H22H664armcDFh+H2VDCX3gljxjK3P1AWPnQ7q/icEANt xkWSE+oRrC389rxlIHz7+BnnGifAQNuMJ58BTbXsZbbBFVi6m8PdnSKhuXcYq0AKw3/zcZwO q7ZqZHAv6g39dxwEl1fAwpAR5zgIGutmPXwaXgyUkhyHQ+Foiate6OJBBKv9TR7TPVBZZueb kFcL2k1rk7RZOnWujs5mFKFyrT4rmT1o1+9Kliers8zI/b+c0k7ksEVbECVAMpE4AhMrJSSd 56q0oACX5ZdHrSNISqjUKkbmI46vEykl4hRaf4nRqM9pcjMZrQXtEBAyP3G50SVRqbSOyWCY bEazqWICL2kBkr+cH1nd8n3rxEzr36c5ObvovONZT5rjZGeCr9ojAmOiouVpy4Zq7/xArFgV 5giKLcmP7rrQvi+0LK5Xmo7KHx8rGH37p2S4e3Xu7L2uSGflODm8PlWcSKTqou5NP4+3ddab 9b4B9SZ/ZUzIG6vosiNpfF5vH58LCRH5X7NELskIbRp9IBDXaOl/qkWwWGcDAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc92zs6Gg9MyffICOchS05bZTUykvqitsIKIodhJhw43ndsy M4gpUaZQYZopyRZ5rW3QIPRLokel3MByFpZoS7RITUTLvEylnZ196MvL7/k/l//7vjwkT2LB Q0lVkUGpK6LVUkLEFynO8OM6cbFC1maXHZ/tPZyK0lpa1rFMpBAl5ynVqlKl7mDKFVHBH1cz rt12dvPKmHEGMyJXnZVXjYQkUIkw8OmVl0WkhFpFYB5d9geDCOZru/zBTwTOqUmCDfjUPR6Y bU8ILlOPweCaQ8AOk1ADCOx2OcsEFQ+DWxM4y0FUNLztXPAZ7qTSYbOyC+P0DLg/bvbXJMH6 8Ds+y3xqL/TOtyGWxVQWLE5+RZyZC4PK5iZfQkhlQ0XDNsEyooJh1WHxDeVRITA+Y8K41wXB 1IiT4HgXzE5ve81ILx+DR+44To4Al6nGNx8oRgA9a/UCLnEWrKZlnEs8R7C5uOL/shj4/uUb jzPOAod1zq8XQnsz28wa3ILfT0u4XjcOHf3vMU4PB0/NCU5/SUDX9BLxEB1o+u/eHKvAM9GA mnwfsAOGGmf4nC6DxWETj+NYaHs27+fz0OeoxjlOgYqRKm+9yMtOBJ6hdv/QSKirmRKYkfAF 2kPrr+o1Bo2BprUqWUK8/oYmlz1o73LlxucWa+zIt16ekG40vClnEEUiaaD4Q06gQoLTpd5K BoWRfGmIeHo/ppBQ+bRBWahUapW6HN01tVLPIIwUhhqRfOBicmtnHpOehP2KtLmNots4pJ6K GmsNb2aKyxPfWF4Xr56MKbl76Vx4mmf3Rn72dc3fcq020hGtMeJReNhpS9KKWk4UjiYEZBsX pB/pm2tzjT9sj91LDnN+cMBKWZ6h6nJPX0aU9sKR/tqxDtvQ56MNWxF3rA8yYzdC94mlfH0B fSiGp9PT/wBEngVJPwMAAA==
X-CFilter-Loop: ASB02
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/DV2E8s_2XIsRSTCx4Wiyl7Y6qNY>
Subject: Re: [Patient] [EXT] Slides from the PATIENT meeting in Singapore
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 03:27:46 -0000

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


From: Brian Witten
Sent: Wednesday, November 15, 2017 7:25 PM
To: patient@ietf.org
Subject: Re: [EXT] [Patient] Slides from the PATIENT meeting in Singapore

slides attached as promised...


From: PATIENT <patient-bounces@ietf.org> on behalf of Brian Witten <brian_witten@symantec.com>
Sent: Wednesday, November 15, 2017 7:24 PM
To: patient@ietf.org
Subject: [EXT] [Patient] Slides from the PATIENT meeting in Singapore

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 <patient-bounces@ietf.org> on behalf of Brian Witten <brian_witten@symantec.com>
Sent: Wednesday, November 8, 2017 12:59 AM
To: patient@ietf.org
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

bwitten@symantec.com

From: PATIENT <patient-bounces@ietf.org> on behalf of Brian Witten <brian_witten@symantec.com>
Sent: Monday, November 6, 2017 4:26 PM
To: patient@ietf.org
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
PATIENT@ietf.org
_______________________________________________
PATIENT mailing list
PATIENT@ietf.org
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
    
_______________________________________________
PATIENT mailing list
PATIENT@ietf.org
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