Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

"Ackermann, Michael" <MAckermann@bcbsm.com> Wed, 25 October 2017 03:31 UTC

Return-Path: <mackermann@bcbsm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF45013B0EA for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 20:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.091
X-Spam-Level:
X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 1SRMioY2CXYz for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 20:31:24 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 7AC1813A092 for <tls@ietf.org>; Tue, 24 Oct 2017 20:31:24 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id A04771C0987 for <tls@ietf.org>; Tue, 24 Oct 2017 22:31:23 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id E131F1C0985; Tue, 24 Oct 2017 22:31:22 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A6451FE04E; Tue, 24 Oct 2017 23:31:22 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4AEACFE048; Tue, 24 Oct 2017 23:31:22 -0400 (EDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.24]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Tue, 24 Oct 2017 23:31:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fkVHRO2xS7wCXT8HUI6ONylXwUzz7YVLjVs9eFQuJ/g=; b=o6l1lEnE2LONslyXrUgix4k9bsChAz0fhBPGK/6aUqSKlFwzuR/9BYSZlKB6sFYySx1adAhrw2LESduV/mjb90qQJ10SINZib7ziY5KDaAMwUJTG3wgJmVj/J4Aslnw+eD6ZTdoZ2JJgpfBNEpynt3Eolle/eTpDn2PHKORWRDw=
Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1364.namprd14.prod.outlook.com (10.172.149.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 25 Oct 2017 03:31:19 +0000
Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.20.0156.005; Wed, 25 Oct 2017 03:31:19 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "David A. Cooper" <david.cooper@nist.gov>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTTPr5HVvcnaInjUunozwwxCXv1qLzYRoAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjPAIAAAkyAgAAWooCAACCFcIAAF/KAgAAE61A=
Date: Wed, 25 Oct 2017 03:30:49 +0000
Deferred-Delivery: Wed, 25 Oct 2017 03:30:00 +0000
Message-ID: <BN6PR14MB13610227E80B81F0BC45582ED7440@BN6PR14MB1361.namprd14.prod.outlook.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <CY4PR14MB13686CD4119467FEEB5AC454D7440@CY4PR14MB1368.namprd14.prod.outlook.com> <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie>
In-Reply-To: <4ff287f3-fefa-d68a-ac56-52697d978ceb@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com;
x-originating-ip: [165.225.39.57]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1364; 20:7394xnP/JnvPQetOQmmwh9ye8uIFBA6ADDPfnR2N4g/PsV/yg1sGlzhGS9br4Z3T+Nmzdcgj8n3f6wDST8lu8IHXH6N6sfHffZz86jHdg313OTUgoLGfiAKfjtuwgg0NnkKN7C3vfW7uizDzAvtN8VQi4h8ekdi4gUVfG7+NEOc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0e0e5ab7-7d4c-4641-60a4-08d51b58db7b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR14MB1364;
x-ms-traffictypediagnostic: BN6PR14MB1364:
x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(65766998875637)(72170088055959)(86572411397741);
x-microsoft-antispam-prvs: <BN6PR14MB1364C79B120DE212B6C8EAB0D7440@BN6PR14MB1364.namprd14.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1364; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1364;
x-forefront-prvs: 0471B73328
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(85714005)(24454002)(189002)(199003)(51694002)(13464003)(966005)(2501003)(99286003)(33656002)(6246003)(50986999)(76176999)(54356999)(77096006)(230783001)(305945005)(6306002)(3660700001)(8936002)(86362001)(81166006)(7736002)(8656006)(106356001)(105586002)(81156014)(74316002)(53936002)(53546010)(55016002)(9686003)(8676002)(3280700002)(6116002)(66066001)(2906002)(110136005)(2950100002)(561944003)(97736004)(316002)(102836003)(3846002)(229853002)(72206003)(80792005)(189998001)(68736007)(5660300001)(6436002)(478600001)(7696004)(25786009)(93886005)(14454004)(6666003)(6506006)(2900100001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1364; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0e5ab7-7d4c-4641-60a4-08d51b58db7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 03:31:19.3504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1364
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: fceb14e5-1ff2-4bde-b9f2-3bd6a6620bfe
X-VPM-MSG-ID: 5961601d-3522-467c-a5f4-d31da2b19e94
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/N3pQdfqj2Y2jU7azuLqVmvl4MNM>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 03:31:27 -0000

Sorry,
My turn to disagree.  
I don't believe any points  stated by David or myself had been stated previously nor "Countered".  
And if "Countered" means you disagree with the assertions,  then you are saying that hosting providers are NOT doing MitM and that TLS is a multipoint protocol.    And once again I disagree.  
But since I too deplore "Noise",  I will comment no further on these aspects of the conversation and we can agree to disagree.  


-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Tuesday, October 24, 2017 10:01 PM
To: Ackermann, Michael <MAckermann@bcbsm.com>;; David A. Cooper <david.cooper@nist.gov>;; tls@ietf.org
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00


Michael,

What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry.

Thanks,
S.

On 25/10/17 01:41, Ackermann, Michael wrote:
> Excellent points/questions and I just wanted to add that your final example, regarding  hosting providers actually being a MitM,  is EXTREMELY prevalent in Enterprises today and is a management/ monitoring issue specifically pointed out by Steven Fenter in his presentation to the TLS WG in Prague.
> Without the ability to decrypt these sessions our ability to manage/monitor/secure is severely reduced.
> And TLS, being a point to point protocol,  cannot help in its current form.
> 
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of David A. Cooper
> Sent: Tuesday, October 24, 2017 6:39 PM
> To: tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> 
> On 10/24/2017 05:18 PM, Salz, Rich wrote:
> 
> 
>   *   And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers.
> 
> And that is a risk you are willing for the entire public Internet to take?
> 
> I'm not taking any risk.  The ability for a server to allow a third party to have access to data it is exchanging with a client already exists, and that ability isn't going away whether this proposal (or something similar) is standardized or not. As I've already pointed out, for the scenarios people are concerned about, the "attacks" being described would be much more easily carried out by some means other than draft-rhrd-tls-tls13-visibility.
> 
> So, no I am not worried about the "risk" of creating a complicated way for servers and middleboxes to collude to do something that they can already do now in a simpler way.
> 
> 
> And what about the fact that it provides a cleartext signal as to whether or not a client is willing to let itself be MiTM'd, does that bother you?
> 
> No. As I noted before, servers can already allow middleboxes to MiTM connections with clients with asking the client's permission. Public facing servers that want to allow this (even if as a result of coercion) won't use this extension. They'll just enable it without informing the clients.
> 
> There are also other ways a server could allow a middlebox to MiTM the connections that it has with clients that don't require the client's cooperation (or knowledge) and that wouldn't require any changes on the client side; ways that would be easier than trying to use draft-rhrd-tls-tls13-visibility.
> 
> If the only way (or the easiest way) these connections could be MiTM'd required getting clients' permission, then this might be a concern, I don't see servers that want to (or are coerced into) allowing connections to be MiTM'd asking clients whether they are willing. Given this, we aren't going to see browsers that are configurable to signal that the client is willing to "allow" the connection to be MiTM'd.
> 
> I haven't even gotten into the question of what does it mean for a connection to be MiTM'd. If Company X decides to have its web site operated by Hosting Provider Y is the connection between the client and Company X being MiTM'd? The client might think it has a secure end-to-end connection with Company X, but in reality its data is being intercepted and read by Hosting Provider Y, without the client's permission (and most likely without the client's knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be standardized until it can be proven that such a scenario is impossible?
> 
> 
> 
> 
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>  
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.