Re: [Patient] [EXT] Re: [saag] Internet Draft posted as requested -

Brian Witten <brian_witten@symantec.com> Mon, 18 December 2017 17:39 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 155D8126CBF; Mon, 18 Dec 2017 09:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[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, T_RP_MATCHES_RCVD=-0.01] 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 OniYp3ep98t8; Mon, 18 Dec 2017 09:39:51 -0800 (PST)
Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.35]) (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 19AC6126579; Mon, 18 Dec 2017 09:39:51 -0800 (PST)
Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat1.net.symantec.com [10.90.75.1]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id CF.0C.35258.56DF73A5; Mon, 18 Dec 2017 17:39:49 +0000 (GMT)
X-AuditID: 0a5af819-80ab69c0000089ba-b0-5a37fd65bd3a
Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat5.net.symantec.com [10.90.75.5]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 28.F6.04260.56DF73A5; Mon, 18 Dec 2017 17:39:49 +0000 (GMT)
Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 18 Dec 2017 09:39:48 -0800
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.1) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 18 Dec 2017 09:39:48 -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=PjZm6YqSlCIEmTa+o7MfyFGmIJgnLLLKVv8nqcAcAZE=; b=4gic8th4C+hjTt/A2T504DAt71e5/TVJI85pEqvo5zgVHh2i5K5xwe29Zpi78eKBvj9MUhkR8X9qdqBU42+pa2Z8BG7AWWcIM+bU+FIG/sF0rqfsdSPQ85p+LNdy3tlwLOiigAonxXJqdlLiYLTnyVxpomruTJBw/Y74Rg+gJgA=
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_P256) id 15.20.323.15; Mon, 18 Dec 2017 17:39:46 +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.0302.017; Mon, 18 Dec 2017 17:39:46 +0000
From: Brian Witten <brian_witten@symantec.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Diego R. Lopez" <diego.r.lopez@telefonica.com>, "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [EXT] Re: [Patient] [saag] Internet Draft posted as requested -
Thread-Index: AQHTd415HLZtNjcH2kGG5FkwS/mPNKNIPdsAgAEe6Lc=
Date: Mon, 18 Dec 2017 17:39:45 +0000
Message-ID: <MWHPR16MB14889F9F1671437D969B83D8930E0@MWHPR16MB1488.namprd16.prod.outlook.com>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <dfdb52ca-81ae-50b7-cd5f-e256b5cb047d@cs.tcd.ie> <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com>, <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie>
In-Reply-To: <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [155.64.38.107]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR16MB1486; 6:5ZpQxWXND6lT8spJycMzvSbQyX/U5THbnl6vU5k0+vM+iYuvwChy6D4+4sigwPM349/4GSjk+84MS2BRFoftw+sr/xYa5TNYtR0ZjO/ave5c+Ve2er5DQsfznssJo21bdLGBVITRhJRilx4XsYUuh+qcV2Fg3Gai7urxKxTyjzGVj5KUg2IOppEgR3O5tlEoBJgJpXGX0ESmRmIfQLBLj4AmvDFR6YaCgY7cJHyh5U5anTuRFgGKzX1AVhDMBLKc3JT70bbjNAnsF7HrQhSEteRQFfF1Jrf13BNVhzSaOg0Z/y8UQ9bSI2TYMcNiwM0EV2XNfkBcwX8+4iGXWgV7lKWw37S0TMNj5hJXyrYb89k=; 5:bNwY/bIS3K/YdmHGYZSnHr39o0R0g1SGAg7putNcIcq5PB8qae6gootYF5iCkctoU0qPMWxlHyfwr7mYHQmdQaAOcpu1dbklSPSIoBRc5E0Uhxmz1N1MHaO6sZxVhf6VJnCEHy8+AtGoVss+p6sNEsFu6yiDraVRJEIwGmV1an0=; 24:2qD04hFo5mENU3HUdUn6DFWV7Uar2FzJ1tXF6qNWMJn9nN3kB/32rg3jtE+OMEoc9yv1ETvqz8jRGHcfNhlsU8i5K0HSudNMQOjmh5OHWr8=; 7:G0EUs/dsFviQ2VSHv+/hL0VSRnfQUfP1WtE5qgb4maMLIO3y51kV8yHiM78rvm/wM0EB7NC4rSa2YESxSdPJu0GVOB7ahZ2/K+yhZI1jAP4Al/9eRWWM+SweaG4dArNlzuOy1fpJxLg/SPWvN4js8St6yUntYcCArx4qdwtGWfHdQwKaIWrfyOEFGouPpe9gOaEfmpkEh/F4xxPBFnH1t3WizVmCDTxLQqfrJocnlZygr/t7yHUJDGVn6ejDjl6d
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ae235759-0762-4d3e-594f-08d5463e5475
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1486;
x-ms-traffictypediagnostic: MWHPR16MB1486:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=brian_witten@symantec.com;
x-microsoft-antispam-prvs: <MWHPR16MB1486CD5F8A7C3BC39022B9A1930E0@MWHPR16MB1486.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011); SRVR:MWHPR16MB1486; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1486;
x-forefront-prvs: 0525BB0ADF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39860400002)(24454002)(189003)(199004)(2501003)(9686003)(53936002)(2906002)(55016002)(99286004)(93886005)(7736002)(305945005)(3280700002)(345774005)(3660700001)(74316002)(33656002)(5660300001)(14454004)(68736007)(105586002)(106356001)(86362001)(3846002)(6116002)(102836003)(97736004)(8676002)(81156014)(7696005)(76176011)(81166006)(478600001)(59450400001)(6506007)(53546011)(8936002)(316002)(2201001)(2950100002)(6436002)(66066001)(110136005)(10290500003)(229853002)(6246003)(77096006)(25786009)(2900100001)(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: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ae235759-0762-4d3e-594f-08d5463e5475
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 17:39:45.9186 (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: H4sIAAAAAAAAA02Sa0hTYRjHeXfOtuNy8LZMHw2pBvlBac2SlK6GBVJaEmGxLDvpScXLZJu3 Pk0jcxvilMrScimzILTSEic2qzVz3smwUKyEnLhkdF9KqG07M/ry8nve//+5wUMRokZuCJWV p2IUeXSOmCcgBbIjaCuzFC2Tto3tjPk64OTFOJ7viLlapeHE1Jrf8mPJ+FbdOC/eaFzkxGv+ EEmETLAnncnJKmQU2/adE2R+aLpB5L+MLW6c7eKrUW+UFvlRgKOgRV9JapGAEuFvCBZnLxGr grmrB7GCC8GUuY7HBlYEDQulXDaYQ/Dw3XWvjcQaAvoNVp9yjQPmKxb0L2fFpud5KvOwBHqX pryuANyCYKz7BfII63ACqE1LpIcDcCK0V49yWN4FDtsb71gk3gKDukd8LaIoIU4B+9RGtoGe D66yOW+uH94LHRVDfA8jHAi/B1q8dQgcBJMzBg67Hgbj01HfquvB8WmZy/JmaP1u9XEojBl0 3g0AW/hw++NlPitIoKPaiVhOhMEVu89kdG/jbPJ1CAf7xDTBTpECA62ffd2y4f0Pva9DCnRb XvP1aHvdfwOyLIUvIwaC5Qi42zjvZSFeC/03Z8g7iLyPNtHK88pclbxARecz0kiJsiQ3zfPQ 7rNJk6TJc9uR93AWgk3IakuwIEwhsb+wyR4tE3HpQrfTgoAixAHCo8PuL2E6XXKRUchTFQU5 jNKCNlCkOEhY4wqTiXAGrWKyGSafUayqHMovRI2KQiNPaR/7u3p3O4YMJ8/+esUkB9edGS+/ dayAWlMqvudwnk4KH5FPpraUd9fEPqgc9u9jhJMlJ3Cc+uD+zPkMDV3cPN1WZo+rejbTo54e 7jsW8aSBceqSl2s6bRBYhUwXkk0d1ekTg0XmQ52Whr7jYRX1h+ulP2ub7WUHrHViUplJR4YT CiX9F4pGeXQ0AwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42LhivJm1U39ax5lcO2xgcWHU2/ZLF4eMLaY 0t/JZDF97zV2BxaPtd1X2TyWLPnJ5NH5mzmAOYrLJiU1J7MstUjfLoEr496iGcwFhx0qFj7b yd7AeNSki5GTQ0LARGLvzn2MXYxcHEIC3xgl7uydxQbhHGGUmPejkRXCecEosf76NLAyFoFO ZomT849AZaYySextP8QI1/P/xAQ2kMlsAnoSR//eAasSEVjDKHFp90FGkISwgI9Ew46/LCC2 iICvxKaJ55kgbCuJlycuM4PYLAKqEqe7N7B3MXJw8ArESDy9Iw+xYAK7xLemF2C9nAK2Els7 zrCD2IwCYhLfT60Bm8MsIC5x68l8Joj3BCSW7DnPDGGLSrx8/I8VwlaUWPvpCJQtK3FpfjfY BxICh9gl5t5vZYdI6ElsnfiWEcL2lTj9/ylU0RKgb94ugtqgJfH05gNmiCtiJE6tfQW1LVvi 7ucJUBtiJHYfusgO0byAWWLO5iY2iISMxOMj3SwTGPVmIbkcwjaQeH9uPjOErS2xbOFrMJtX QFDi5MwnLAsYWVYxKiQWJxXnluSWJCYWZBoY6hVX5iaDiERgsknWS87P3cQITji/xXYwHvjj c4hRgINRiYd3xlXzKCHWxDKgykOM0hwsSuK8jzWYooQE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw7inYE96ZK7tO3meaCu/XIAnH1kPHZ70Wrgl2+jUxM0Rk946CY+n6W2fl/rx08K+sRd7F lx+eNy748urF0S42I3fhlLKbWxf9ZA+udpu/yGXC1QU7iiq5FZvuej7QmHnecmfYPi7e2QXX edy4Q1ki1gSu7XixNZFrW1oDG1eoyZaVUlPTOJd+UWIpzkg01GIuKk4EAOh2YcwZAwAA
X-CFilter-Loop: ASB04
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/7b1KMLPHfoM8uB10u1qQKt68D3I>
Subject: Re: [Patient] [EXT] Re: [saag] Internet Draft posted as requested -
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: Mon, 18 Dec 2017 17:39:53 -0000

Hi Stephen,
 
Thank you for taking time to reply over a weekend.  The extra effort is appreciated.
 
Where you say, “Middleboxes are as likely to have bugs,” this is of course completely consistent with my emphasis in Singapore that “all software has bugs & vulnerabilities,” including both endpoints and network appliances, virtual and physical.  One of my points that you might’ve missed in Singapore was that “when something goes wrong,” such as a vulnerability being exploited, I’d much rather have that "blow up" in some remote (and easily reset) network thing (virtual appliance, container, or lambda) rather than in the endpoint.  Why?  Network “things” can be dedicated to flows that are specific to a remote endpoint, like a client running a set of proxies in a cloud based infrastructure that they and millions of others trust, with each software instance of the proxy dedicated to mediating communication with a different server.  In this context, if the server hacks the middlebox, it only hears it’s own conversation with the client.  In contrast, if the server manages to hack a client, it can hear all that client is doing, including today lots of location based information, as well as seeing state accumulated from past conversations with other servers.  So, I’ll stand by my two assertions: “All software has vulnerabilities,” and “When things go wrong, I’d rather have them go wrong in an easily reset network thing, much rather than having things go wrong in the endpoint.”
 
Back to the thought that “all software has vulnerabilities,” taking the discussion further, in fact, just as some endpoints have more vulnerabilities than others, some network appliances have more vulnerabilities than others. That’s of course among the reasons I believe it’s good for endpoints to know as much as possible about the network appliances which they are considering trusting with cleartext.  Some people in this discussion have proposed narrowing the scope so that endpoints only trust a set of well-known, manually pre-configured set of such appliances, but still tackle challenges like end2end integrity.  Others see value in tackling the more flexible, more SDN/NFV like aspects.  I’d be happy with either scope. Either scope would be better than trying to pretend that network appliances aren’t needed for security, or trying to pretend that network appliances never need to see cleartext to be effective.

Re, “That's incomplete to the point of being misleading,” it would have been incomplete if I hadn’t already said much of what I’d said above, but I’m happy to repeat myself here to be sure all is captured electronically for everyone, and, as promised, I’ll try to similarly consolidate all of these points into the v01 of the Internet Draft.
 
On your reference to analysis of encrypted traffic without decryption, that can be great for detecting “command and control” communications after an infection, and maybe sometimes even for blocking later stages of a multi-stage attack, but of course it’s not always very effective against blocking initial infection.
 
Re Diego’s points I agree with him completely on all the points he mentioned yesterday, including changing the phrasing of point (3) to “may require.”  Some endpoints are easily updated, others are not.  Even for “easily updated” endpoints, people operating many endpoints often find that network protection is an efficient way to quickly protect many, many devices, all at once, while endpoints individually update their protection.
 
Re “random person can sensibly decide 269 times,” um, no.  I’ve repeated myself here on this a few times, but I’m happy to do it at least one more time.  Power users might choose to run their own protection in their own cloud based infrastructure, but that’s not a random person.  Many people choose to have someone or something help protect them.  Many employees choose to let their employer help protect them.  Many people often choose to have security companies help protect them.  Some people choose to have network providers help protect them.  I believe people have a right to choose who protects from them from potentially malicious servers.  I believe people have a right to choose protection from someone other than the endpoint maker and someone other than the remote server.  Maybe we differ on this.
 
Re shutting down the dedicated list for this discussion, we all recognize that has been your desire from the start.  In contrast, some of us see value in the discussion.  Where you concluded PATIENT was started for only watching what people do on the web, and not helping protect IOT “things,” that view is of course surprising to me as one of my earlier notes highlighted “particulary for … IOT devices,” and I continue emphasizing “increasingly closed” endpoints including both mobile & IOT.  Of course, like TLS, PATIENT would be most valuable well-covering a broad range of settings, including Web, Mobile Apps, and IOT.
 
Re, “no clue how that can reflect a genuine technical opinion,” I’m happy to talk by phone if that’s more convenient for you.  I’m hoping that you are willing to grow past your (actually quite famous) a priori biases on this topic.  Re, “magical thinking … new lies … and …snow job,” I find your choice of such words simply insulting and not constructive, but I’m willing to look past that here.  It’s an important discussion, and I have a thick skin.  I’m sure there’s a joke somewhere near that re thick headed.  More importantly though, as I was saying, “how we (as a community) protect increasingly closed endpoints, at scale, now that we are beginning to enjoy the fruits of pervasive encryption,” is an important topic.  I’m obviously eager to continue the discussion.  Thank You Again.

Brian

    



From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Sunday, December 17, 2017 4:23 PM
To: Diego R. Lopez; Brian Witten; patient@ietf.org; saag@ietf.org
Subject: [EXT] Re: [Patient] [saag] Internet Draft posted as requested -
  


Diego,

I generally disagree with some of your earlier points where
you disagree with me:-) I do agree that there are hard
problems with updates and bugs in general for endpoints and
devices in the middle. I don't agree that breaking TLS or
HTTPs is a viable way to improve that, It'd make it worse.
But rather than repeat things I've said to you in person
before, for this threat, maybe it is work saying that the
proponent here claimed to be interested in a new multiparty
security protocol (in the mailing list description) which
could have been a worthy, if unlikely to succeed endeavour.
In Singapore, I concluded that they are primarily or maybe
only interested in the web as used by people and in mitm'ing
that. So personally I think the separate mailing list would
be better closed down as it seems to have been started on
the basis of some confusion wrt folks' goals.

On 17/12/17 23:19, Diego R. Lopez wrote:
> 
> I am afraid I don’t follow you here… What do you mean by “random
> name/address that claims to be “good””? Given there are appropriate
> roots of trust, how is this “random” trust different from the
> certificate verification process in TLS?
The difference in the above context is the the proponents
here want TTPs that tell lies all the time, and that are
so wide-spread and not well-known that they appear to the
endpoints indistinguishable from a random router. The public
Web PKI TTPs we have are far from perfect but at least they
don't do that so far.

There also appears to be some magical thinking that allows
some proponents to say that they think these new lies can
benefit the user and give the user more control. I have no
clue how that can reflect a genuine technical opinion.

S.