Re: [TLS] chairs - please shutdown wiretapping discussion...

Timothy Jackson <tjackson@mobileiron.com> Wed, 12 July 2017 08:53 UTC

Return-Path: <tjackson@mobileiron.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 4416412EC3B for <tls@ietfa.amsl.com>; Wed, 12 Jul 2017 01:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.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 ptK9CRyiNUO3 for <tls@ietfa.amsl.com>; Wed, 12 Jul 2017 01:53:10 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0054.outbound.protection.outlook.com [104.47.37.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32B712708C for <tls@ietf.org>; Wed, 12 Jul 2017 01:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OMneTC90MYQsUru3FYYTd9XIfpgbv8ZKthRhcivk11U=; b=rWJBjWq5LzmuYCpPTmCP0m29kawNeGB8Z80gD3x4u2f4RwLrxBKmS6Ez4+WqCrzAOugTbh7ZyZvICoMtKlFW11VUIFm0bjkz7jMC8GQtU/yDQ/C1wKE9ZGOzqXipNjofrii6QciYPJDO3jjWmUUBkvECl1pc3XHHAd2Sgkb2eyc=
Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1735.namprd10.prod.outlook.com (10.172.69.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Wed, 12 Jul 2017 08:53:09 +0000
Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.1240.020; Wed, 12 Jul 2017 08:53:09 +0000
From: Timothy Jackson <tjackson@mobileiron.com>
To: Bill Frantz <frantz@pwpconsult.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] chairs - please shutdown wiretapping discussion...
Thread-Index: AQHS+YQIIMr3b+F8O0+nlKMGCO8wcKJNL/oAgABE5ACAAAwtgIAAD9QAgAAChYCAAAJwgIAA4XWAgAAd/4CAAAYnAIAAZHCAgAAIVICAAAIXAIAAAyWAgAABLICAAAevgIAABoEAgAAEgYCAAALtgIAADVkAgAABpYCAAClRgIAAiQJv
Date: Wed, 12 Jul 2017 08:53:09 +0000
Message-ID: <pabvkvrnfltgqkgt51u2b2ek.1499849588747@emailplus.mobileiron.com>
References: <340c77ed-ad4a-98cd-7b90-b372f665a26a@cs.tcd.ie>, <r470Ps-10125i-9701DDD91F704B63AC879FF9EE01DBC0@Williams-MacBook-Pro.local>
In-Reply-To: <r470Ps-10125i-9701DDD91F704B63AC879FF9EE01DBC0@Williams-MacBook-Pro.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pwpconsult.com; dkim=none (message not signed) header.d=none;pwpconsult.com; dmarc=none action=none header.from=mobileiron.com;
x-originating-ip: [204.8.168.222]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR10MB1735; 7:3J2QLa4ivt3PUq3+xmFxRCMdvWah99xyyQNRzhIawhdvU0AJ3dAzYbhsIz94Byer2pJFeiPpwQTtBdY7+IuESW3fGL2hp7Zj/ObdePe+7WZPiIGN3ZSZ42cqih5DFvHuZC8q8wyD9PKyDY5O/5c3iYfwOQMUfcQr59ia2Qx3e7fc3/tZoLLYE3F1VyeW4jqJvFxo3UEu6vSKZo4R92AMOtn2AKKKmsIUGNLG89sV6IEDMxzXkLPDFOx1luiF2jr6IleAvtbP8TzyQXMM7QhlaKLu0RePsdA4Kfje4XxMA9AJW8c1/iv+57wj1mZmhGq2XJH9rBcDj8P/M8sJvH+fVvv7V6OdIFpcyw2b/mI7Utv3glm1YbIi4LeNFWxBd+IkIsMr+UH8pAd6RZ+mL+vEw2nFb63PQur7ZnopLBjhw5EVgVbkLgtHFwmzbvXHYp9V/NO2nFsxi5NkNlUxlIxrZGsVC/PmGfb1tMR+hpKH1vY1yWGo3eeOE26gxOd91o4DA7PV4RQBFSXa5uJi1fU45SO/pmjIb8aRCVuWcH53pQkgMYsvrpSR3FizA6yVaYKIxfoF+RgEjLOzHWIUNyDZaZ/vrXX379MfYvnDawvVe0cvu88pMWwSUvN1HU/bpuch9iyM84rNbSA6xD0rUEIwxQVO1sUREndZS4oTNLoIMoh2bYUYFjx1gG3CMeJrr1Uudwq+bVZuyMHJ3FrHYZqKkWuHk9d2z7gMi57hC95Uni6bs/UTSfMTEzme/waNzOvn9Q0DdBNySlc8XOwKjsYXAuOllR3eUo0aIp1bQPufW/E=
x-ms-office365-filtering-correlation-id: 5a9d3d1a-456f-471d-064d-08d4c9036bc7
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:CY4PR10MB1735;
x-ms-traffictypediagnostic: CY4PR10MB1735:
x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(148574349560750)(247924648384137)(17755550239193);
x-microsoft-antispam-prvs: <CY4PR10MB17358D8E187644762CFCF1F0AAAF0@CY4PR10MB1735.namprd10.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR10MB1735; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR10MB1735;
x-forefront-prvs: 036614DD9C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(377454003)(66066001)(189998001)(86362001)(3660700001)(7736002)(3280700002)(2900100001)(5660300001)(76176999)(50986999)(54356999)(8936002)(2906002)(14454004)(81166006)(33646002)(95246002)(25786009)(53546010)(8676002)(1680700002)(38730400002)(6116002)(102836003)(478600001)(53386004)(6506006)(3846002)(6436002)(229853002)(236005)(51650200002)(606006)(54896002)(966005)(99286003)(77096006)(53936002)(6512007)(6306002)(6486002)(2501003)(2950100002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1735; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_pabvkvrnfltgqkgt51u2b2ek1499849588747emailplusmobileiro_"
MIME-Version: 1.0
X-OriginatorOrg: mobileiron.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 08:53:09.4810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1735
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2xhWbxRb3EV29JKfVbJ1ggEb5r4>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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, 12 Jul 2017 08:53:15 -0000

Bill,

I agree that we need to find the "least bad" option, if for no other reason than to prove there is no acceptable solution. If I may, I'd like to suggest another possible way to get to "least bad".

Perhaps our goal should not be to prevent servers collaborating with the monitoring, which we can't actually do anyway, but rather to ensure both sides to know when this is happening. This will give clients the opportunity to decide whether or not to allow it. A few people have started down this path on this thread.

One can imagine a few ways to approach this (these are examples to get people thinking and admittedly aren't fully baked, so be nice ;-) )
1. Define a new ciphersuite(s) explicitly for this purpose. Call it TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256_MON(itor) or whatever. This would make it obvious what's happening and the client can choose to enable or disable such cipher suites. Browser/OS vendors might let users/admins enable these cipher suites for local network connections and disable them for connections to the wider internet.
2. Include something in the server's certificate (a new X509 extension or the static ECDH key perhaps?) as a signal to the client that the server is enabling monitoring. Again, this can be allowed for connections within an organization but potentially blocked for connections to external networks.
3. Use a 3-party handshake. As I recall, there are three party versions of RSA and DH (Joux, 2000) and at least progress on making 3-party ECDH work based on Ben Lynn's work. (I haven't checked to see what the latest status on this is.) This probably becomes an extension and possibly some newly defined cipher suites as well.

There may be any number of other solutions, this isn't meant to be an exhaustive list, just get people thinking. Because this request is so specialized (monitoring inside an enterprise), it seems reasonable to me that the solution can be non-generalizable to the internet at large. In fact, that's probably a desired trait. Therefore, the use of custom ciphersuites, extensions or the like may be viable, since both ends of the connection are ostensibly under the control of the enterprise. (I'm sure BITS et al will speak up if they disagree.)

Cheers,

Tim
--
Tim Jackson
Senior Product Security Architect

________________________________

From: "Bill Frantz" <frantz@pwpconsult.com<mailto:frantz@pwpconsult.com>>
Date: Tuesday, July 11, 2017 at 5:43:03 PM
To: "tls@ietf.org"; <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...

I must admit that I mostly agree with Stephan that this kind of
thing should not exist. However, it exists now, and the chairs
have decided we should at least discuss it.

I think there are many ways to meet the "requirements" of
network monitoring and protocol debugging, and some are worse
than others. Leading the world in the direction of the least
damaging ones seems to be the bese way to deal with a bad situation.

The major threats I see include:

   Coerced use by oppressive governments.

   Use outside the immediate private network

   Use by an ISP on its customers

   Use without both ends being aware that it is in use.

I think coerced use is by oppressive governments is an obvious
bad and I hope I have working group agreement on this point.

Limiting the protocol to the immediate private network will
prevent 3rd parties from activating it to spy on the enterprise.
One possible way to enforce this limitation is to require
compliant implementations to limit broadcast of decryption
information to the IP addresses on the local subnet.

I would be nice to be able to keep an ISP from spying on its
customers as part of its "private network". However, I don't see
how to differentiate an ISP's network from a enterprise network.

If it is not technically possible to use the protocol without
both ends being aware that it is in use, then user interfaces
can reflect its use. One result would be that enterprise users
would be continually warned that their messages aren't private.

Any technical fixes we build into the protocol that prevent
these actions are a positive improvement.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | If you want total security, go to prison.
There you're
408-356-8506       | fed, clothed, given medical care and so on.
The only
www.pwpconsult.com<http://www.pwpconsult.com> | thing lacking is freedom. - Dwight D. Eisenhower

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls