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

"Black, David" <David.Black@dell.com> Mon, 18 December 2017 16:19 UTC

Return-Path: <David.Black@dell.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 3ED6C126B6D; Mon, 18 Dec 2017 08:19:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.821
X-Spam-Level:
X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=dell.com header.b=wxWxnVaj; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=Q6ClChUg
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 O99fuZPtbvfR; Mon, 18 Dec 2017 08:19:09 -0800 (PST)
Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 79E83124C27; Mon, 18 Dec 2017 08:19:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1513613350; x=1545149350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fiP6gVGP9kxKi9+KRabHz1czkazixeRId4uaIr4X3HU=; b=wxWxnVajSUoZjYJWBQ1ULFCACznMhgFNomG8mkrTm5vpZQ2khKK/SOvY FtXF9/nr7CFvidkgJNeFC+BaZHCr+6jVdN9BiphaitxN7GjEEdDceiv65 KTPB+/BHuCsZOpNjZAntJDTXYj1LBtlRdbItNIT0neB65pcL2lX6+TXqH o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AJ0fjsByCAUBZ3YzXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0uoRKPad9pjvdHbS+e9qxAeQG9mDsrQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPfglEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2y?= =?us-ascii?q?bIUPAOgAPelEoIfyqEADrQelCgSoGO/j1iNEi33w0KYn0+ohCwbG3Ak4Et4ArX?= =?us-ascii?q?nUqM/6O7sRUeyt0aLGwy/Mb+1X2Tjg5oTDbxcsr/+WUrJucMre1FMjGh7BjlqK?= =?us-ascii?q?tYPlPCiY2fkTvGif6+psT/6gi2kiqwxopDWk28kiio7Mho0Py1DE8z10z5woKt?= =?us-ascii?q?KjTE57ZsKrEJhItyGeKot2WdkuQ2ZyuCY10rEGt5+7fCwWyJs53R7fb/2Hc5OU?= =?us-ascii?q?4hL4TuqePTB4hHdjdbmihBiy6VCtx+z/W8WuzlpHoDRJnsPRun0N2RHf8NaLRu?= =?us-ascii?q?dj8ku5xDqDyxrf5v9KLE03j6bWJJEszqQtmpcdsknPBiH2l1v1gaOKc0gp/+ul?= =?us-ascii?q?5uvjb7Xoo5KRN5J7hRvgPqkrh8CzHP83Pw0BUmWV+umx1Lvu9lDjTrpQlP05iK?= =?us-ascii?q?zZvYjfJcQcu6G2HRdY0p0m6xajFzem18kYnWUfIFJFZh2Hi4/pNknQL/DjF/iz?= =?us-ascii?q?nU6gnyp1yPDCOr3tG5LNLmXfkLj6erZ99khcxxctwdxF5pJUErEBIPf8W0PrqN?= =?us-ascii?q?PYCRo5PxS1w+bhFtp9ypsTVGOMD6ODLq/fv0GE6vgyL+SMaoIZoijxJ+Q76/L2?= =?us-ascii?q?iH82g14dfa2n3ZsNb3C4G+xrLUuDbnryg9cODH0Gsxc6TOPwlFKCUiVeaGusUK?= =?us-ascii?q?I44jE3Ep6pDYDGRoy1mryOwD+7HoFKZmBBEl2MCm3neJ+LW/oXaSKdPNNhkjIe?= =?us-ascii?q?WbimUY8h2gmktBXmxLp/MurU5ioYuIr71Ndv++3TlA899TpoD8mG0mGCUX10nm?= =?us-ascii?q?0SSz8xxqB/rh819lDW6rR1m/xVE5R97ulTXwM+fcrH0+FiC930HAzIZM2ETFKO?= =?us-ascii?q?Sc7gHTo9CNM8lZtGKV50B9SviAzr3ie2DfkSjbPBTMgs+77d0n7tD8dw13iA07?= =?us-ascii?q?Mu2R1uCNBGPGKOh6Nj+U7UHYGD2xGCnq+lXaURwCCL832MmzmgpkZdBURaVazO?= =?us-ascii?q?XjRXSkLIrNizrhfuRqGvBfINNgJKyuaOJ69OLNbuiAMVF7/YJN3CbjfpyC+LDh?= =?us-ascii?q?GSy+bJNdKydg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ERAACf6DdamMqZ6ERcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJsgTh0JweECYohjwiCAJchghUKGAeBD4QNAhqEbT8YAQEBAQE?= =?us-ascii?q?BAQEBAQIQAQEBAQEICwsGKC+COCQBDmwMAQEBAQEBAQEBIgEpAg0CICECGAEBA?= =?us-ascii?q?QMBIxEMHw8MBAcEAgEGAhEEAQEBAgIGHQMCAgIwFAEICAIEAQ4ECAyKDggBD4w?= =?us-ascii?q?bnWyCJ4MRh1YBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4Jfgg6BV4Fogh6BD?= =?us-ascii?q?oMvgXAVgn4xgjKSIJEbBgKHfaEgjRuFaAGDRwIEAgQFAhqBOx+CCW9RgimCUxA?= =?us-ascii?q?MgWd4AQaIeoEVAQEB?=
X-IPAS-Result: =?us-ascii?q?A2ERAACf6DdamMqZ6ERcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?sgTh0JweECYohjwiCAJchghUKGAeBD4QNAhqEbT8YAQEBAQEBAQEBAQIQAQEBA?= =?us-ascii?q?QEICwsGKC+COCQBDmwMAQEBAQEBAQEBIgEpAg0CICECGAEBAQMBIxEMHw8MBAc?= =?us-ascii?q?EAgEGAhEEAQEBAgIGHQMCAgIwFAEICAIEAQ4ECAyKDggBD4wbnWyCJ4MRh1YBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4Jfgg6BV4Fogh6BDoMvgXAVgn4xgjK?= =?us-ascii?q?SIJEbBgKHfaEgjRuFaAGDRwIEAgQFAhqBOx+CCW9RgimCUxAMgWd4AQaIeoEVA?= =?us-ascii?q?QEB?=
Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 10:09:09 -0600
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 22:08:31 +0600
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBIGJ2Ks020823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Dec 2017 11:19:07 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com vBIGJ2Ks020823
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1513613947; bh=zwWPXtT/N+J3jlL7MnQz+5T3xqE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Q6ClChUgQMXK2baWCd1lVo3H58q4cQq3xRmToJGXQegIaAWQuR+fm3Znj7wuSiOhH mRq5Az7S6jsPMkcfz2zPD0XMOmvjA6xjPI9HyBFhDkrrUUbh0yEiQjA6vXq0tkEfx5 a2frqCgo7l3ed28KRQvf6y6l4MEY4G/OY+f6uGfI=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com vBIGJ2Ks020823
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Mon, 18 Dec 2017 11:18:44 -0500
Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBIGImXX024542 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 18 Dec 2017 11:18:49 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0352.000; Mon, 18 Dec 2017 11:18:47 -0500
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] [Patient] Internet Draft posted as requested -
Thread-Index: AQHTd42B8AeAsyHgxE2f7m0T/khZiqNIka0AgACxWjA=
Date: Mon, 18 Dec 2017 16:18:47 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FE1ED76@MX307CL04.corp.emc.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: [10.238.44.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/MfHP7jUdFgkdIp3QTmD0cB0sfTc>
Subject: Re: [Patient] [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 16:19:11 -0000

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

If "breaking" is defined as "MITM-ing connections without any form of knowledge or authorization by the endpoint," then I would agree that "breaking TLS or HTTPS" is a bad idea.

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

+1 on worthy, no comment on likelihood of success.

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

Also, no comment on people's intents, but I do want to respond to one of Stephen's earlier remarks ...

> Just for a laugh, I loaded [2] in a default setup browser (chromium).
> Among the 269 http requests that caused was [3]. Are you (Brian)
> seriously trying to claim that you actually believe that a random
> person can sensibly decide 269 times if 2001:db8::bad:1dea ought
> be allowed to mitm that connection?

A person (random or otherwise) - of course not ... however ... a community or otherwise maintained blacklist or whitelist is plausible, although that does require both that the involved middleboxes to have stable visible identities, and that there be a viable community or other maintenance organization for the list or lists.

A blacklist approach seems reasonably effective in other domains - for examples, try these links:
	https://adblockplus.org/subscriptions
	https://filterlists.com/

Thanks, --David

> -----Original Message-----
> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Sunday, December 17, 2017 7:24 PM
> To: Diego R. Lopez <diego.r.lopez@telefonica.com>om>; Brian Witten
> <brian_witten@symantec.com>om>; patient@ietf.org; saag@ietf.org
> Subject: Re: [saag] [Patient] 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.
>