Re: [TLS] datacenter TLS decryption as a three-party protocol

BITS Security <BITSSecurity@fsroundtable.org> Wed, 19 July 2017 18:05 UTC

Return-Path: <BITSSecurity@fsroundtable.org>
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 DB1C2131AAF for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 11:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.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 b3VkB_al--Ko for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 11:05:55 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0057.outbound.protection.outlook.com [104.47.33.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3225D12785F for <tls@ietf.org>; Wed, 19 Jul 2017 11:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sNgarBIts13ZMeFKEqwy+opFbGBePdD0ztpLivCS9gQ=; b=AtyCh161pN+/NqC9zbjNb0LGxyJHKNVxvmxTXdRjtnxF0Quqklb2sPEXpRYpPY4/MlDUn7YadkJxyapbteYjOqv3C7VuHV9d4ZDaqC0U4NggvluOChBXS0zTWkszzjvjOXlMh/UPuv3cCpBT5g7U3Jsidgjzntr5N0SW6vDiWoY=
Received: from BN6PR11MB1922.namprd11.prod.outlook.com (10.175.100.135) by BN6PR11MB1921.namprd11.prod.outlook.com (10.175.100.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:05:53 +0000
Received: from BN6PR11MB1922.namprd11.prod.outlook.com ([10.175.100.135]) by BN6PR11MB1922.namprd11.prod.outlook.com ([10.175.100.135]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:05:53 +0000
From: BITS Security <BITSSecurity@fsroundtable.org>
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= <colm@allcosts.net>, Ted Lemon <mellon@fugue.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJBar1BHW2E/7UWFUn2swYAliaJbXOSAgAAClACAAAm5AIAAAWoAgAAB0ICAAADYAA==
Date: Wed, 19 Jul 2017 18:05:53 +0000
Message-ID: <BN6PR11MB1922516F23D3307DC915906EF4A60@BN6PR11MB1922.namprd11.prod.outlook.com>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <87796a4e-e958-7119-d91a-b564db2cef39@cs.tcd.ie> <3f9e5ccf-2d5f-5182-5b76-ae24f8e7ecb5@akamai.com> <94ba928f-a6e3-5b10-7bd5-94c22deb5827@cs.tcd.ie> <CAPt1N1kDjeWSXucZJmxNr9rpVOh=hZoXknWn+HzL7sOYTXc4mQ@mail.gmail.com> <CAAF6GDcCnf=O64bnVQXnNHXQAQGY3h5RSjDD0sEE=R1ruEzGcA@mail.gmail.com>
In-Reply-To: <CAAF6GDcCnf=O64bnVQXnNHXQAQGY3h5RSjDD0sEE=R1ruEzGcA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=fsroundtable.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.117.248.226]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR11MB1921; 7:wzsLQZz9ss1lA2LQm7UFyGTEb+ikbGR0v2IQZdiQ/XCs/hk7tcUd5BlLdypnVqAo7LGIIdT1exgiqDA28J9irWcAzOn+iP8hEv6N6eKrjAG7XuAaJvT3xTRvDD2+aTPchNYpA5HCGfRbaZFjheWiQHAqEMdbI/eD4ABlye4a3XI+RUPR+e1uaDT+qRKDHt3yEIfEYuvtTdbGrvHP44dyseqoP5RLKMIhLQekjT+x3iBEDucRFMIRYkDWFuXsc3X4asK95ssFJxYeoqA2+vv4qKRQInOqVRADSf3bsIgwVXQqxCSdFeYgwrdDO1e3dN0v68bW7QWJU0R8B8ndnH8buHsER7UFmY+ewSqwUfqmEC1iNc9Bkfy/Y7wicXjPzLE1cbh041KaF4gF/57iCRb2SNXZDiIMXR4Gx9KSdNtKgWc2CGarMpvCye+ImX/lv509n+P0653YyAA0CwI7KsArc0rRLgSk16VJB+/oYbjCQIotEIYJmNL2EVdhQOHY+Puogs/7wZU+JDQEm0Rrel7WF+yt595WkOU6sGHxYvDbmHnwRX35TYLjg/B9aajB3GCoOM/d80ULHnxn9ly7algaoZJr2wjUTLwvpPzXELBnyEU2Kz3wSSthG+nCREkOpn/v4dRMKq1A3ZGLMJoRRCVRhXHFVTCdfLZ1fUqQeu4/+K8Ech/PPuS5io0CPI0RoFp3z0VaWb73q9NqO5zJxBrXhJQ3+F+8lMoZA8pAc3KvWK4wUxLMqrlXw6x5bl4JnHvqrPskyuIR6AciWL/mpfMbict9y6aiAlS8GCdY1Q6DUOU=
x-ms-office365-filtering-correlation-id: da41f077-d3c6-46bb-5d25-08d4ced0cbf4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR11MB1921;
x-ms-traffictypediagnostic: BN6PR11MB1921:
x-exchange-antispam-report-test: UriScan:(151999592597050)(125551606395959)(133145235818549)(26388249023172)(236129657087228)(100405760836317)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: <BN6PR11MB1921A7B68D3DFC9167475FDBBDA60@BN6PR11MB1921.namprd11.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR11MB1921; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR11MB1921;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39400400002)(39410400002)(39450400003)(24454002)(377454003)(19609705001)(53936002)(478600001)(6116002)(3846002)(102836003)(790700001)(6306002)(54896002)(55016002)(53546010)(6246003)(236005)(9686003)(93886004)(99286003)(229853002)(6506006)(189998001)(38730400002)(6436002)(74316002)(77096006)(86362001)(25786009)(7696004)(5660300001)(8936002)(2950100002)(8676002)(80792005)(50986999)(4326008)(2906002)(81166006)(2900100001)(3280700002)(3660700001)(66066001)(7736002)(33656002)(14454004)(54356999)(76176999)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1921; H:BN6PR11MB1922.namprd11.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR11MB1922516F23D3307DC915906EF4A60BN6PR11MB1922namp_"
MIME-Version: 1.0
X-OriginatorOrg: fsroundtable.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:05:53.4672 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1921
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KFFs2S4VHnGu-QH-GoJpfxni9iU>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
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, 19 Jul 2017 18:05:58 -0000

> It seems like we would be rejecting a good opportunity to make what the network operators want work in a better and more secure way, while making it harder for passive observers and coercive authorities, to use the same mechanism for other purposes. What do we gain? beyond a hollow moral victory.

+1 and this is fundamentally why we’ve made significant effort to work within the IETF process.  We strongly believe a consensus outcome will be better for all, including those who are currently in disagreement.  What we’d like to avoid is being told the solution is to ignore (or admire) the problem.  Finding a workable solution will reduce the risk of forking TLS and will increase the broad adoption of 1.3.

-Andrew



From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Wednesday, July 19, 2017 1:45 PM
To: Ted Lemon <mellon@fugue.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol



On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
The problem is that the actual solution to this problem is to accept that you aren't going to be able to decrypt the streams, and then figure out what to do instead.   Which is work the proponents of not doing that are not interested in doing, understandably, and which is also not the work of this working group.

I'm skeptical that there is a way for this working group to solve the proposed problem, but if there is, it involves figuring out a way to do this that doesn't make it easy to MiTM my connections, or, say, those of activists in dangerous places.

I find this a very bizarre outcome that works against our collective goals. If there is no mechanism at all, then it is quite likely that organizations will use static-DH or stay on TLS1.2. Those are bad options, in my opinion, because there's no signaling or opt-in to the client. We can do much better than that.  Client opt-ins are far from academic. For example, browser's incognito modes may refuse to support such sessions, if they knew what was going on.

It's also bad if organizations end up deploying static-DH and that means we can't do things like checking for changing DH parameters.

It seems like we would be rejecting a good opportunity to make what the network operators want work in a better and more secure way, while making it harder for passive observers and coercive authorities, to use the same mechanism for other purposes. What do we gain? beyond a hollow moral victory.

--
Colm