Re: [TLS] datacenter TLS decryption as a three-party protocol
Felix Wyss <Felix.Wyss@genesys.com> Sun, 23 July 2017 17:17 UTC
Return-Path: <felix.wyss@genesys.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 97A5E129AA0 for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 10:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=genesys.com header.b=k3pTYe9A; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=genesys.com header.b=K1CLqy8I
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 QMRc3LuIkSUy for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 10:17:47 -0700 (PDT)
Received: from us-smtp-delivery-154.mimecast.com (us-smtp-delivery-154.mimecast.com [216.205.24.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E254F120725 for <tls@ietf.org>; Sun, 23 Jul 2017 10:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genesys.com; s=mimecast20160503; t=1500830265; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=w0LHnlmx7qzJC/oEGedvKAAsudK7btjikx4o+aupGe0=; b=k3pTYe9ARVyKWTKpHqFg1Y9XSwKLRP4yOoYthEWGLbS7G8aaRsZLkXlpsRp8QjW9K7Z39JT/smSj/kg448RMKV4ahvgZxxLqV+WxNGB+10dUeuIOHW9JyJI9SqPBvbX4TfzNY2Ntu2SLkRA+P4lXSC+wbjblanydegx8/dHPsDM=
Received: from webmail-us.genesys.com (208.79.170.203 [208.79.170.203]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-105-mHelJPa3Pxi5cCyudpaFyw-2; Sun, 23 Jul 2017 13:17:44 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (207.46.163.23) by webmail-us.genesys.com (10.20.102.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 23 Jul 2017 10:17:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genesys.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pulKfi3PxA21QdwgfahFS5KSJttnfZX79Hm/r64EXe4=; b=K1CLqy8I/xJ+a6/IoBagg0HcGePsb1UuIuEBO/WPsupnAMql+7j+V3/zmtRIMVG1rPw9MKO56o/erhq+42RyB9S5zdtccKbYBQbzDYaBQFcH9V4jaIIv7bf87fvY4TWrW3pkYtovzUs9YRFtjFFxcN55s6jF+eGRJ5a617PbBmo=
Received: from MWHPR1001MB2335.namprd10.prod.outlook.com (10.174.167.157) by MWHPR1001MB2333.namprd10.prod.outlook.com (10.174.167.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sun, 23 Jul 2017 17:17:06 +0000
Received: from MWHPR1001MB2335.namprd10.prod.outlook.com ([10.174.167.157]) by MWHPR1001MB2335.namprd10.prod.outlook.com ([10.174.167.157]) with mapi id 15.01.1282.017; Sun, 23 Jul 2017 17:17:06 +0000
From: Felix Wyss <Felix.Wyss@genesys.com>
To: Ted Lemon <mellon@fugue.com>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB9s0c0IhkYUEqc/kGJh0JOpKJbXOSAgAACkwCAAAm5AIAAAWsAgAAB0ICAAFVNAIAABBuAgAB/KYCAAASrgIAACjOAgAAC6wCAAJbcgIAAAy4AgAADmQCAADBYAIAAA9yAgAAE6gCAAAKqAIAD0gcAgABfPwCAAB6yAIAATz8A
Date: Sun, 23 Jul 2017 17:17:05 +0000
Message-ID: <EC5396F6-98D2-4A04-94E5-1618BC8A2C5D@genesys.com>
References: <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com> <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII> <C0772D29-CB26-418F-981B-BC2E2435E655@ll.mit.edu> <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
In-Reply-To: <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [62.167.199.44]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR1001MB2333; 20:QjD57yDnQZbIxscWx8ccBmKYZuQHkrC4Kv920RWUFriAf8mz351NJSU2hzLos0AwdA5EnQRlEz15nll1fb1afg0FIK8nvhBh/l6cWWgh6HDNXWLCbbcYZ2ydVIljDmQuOIDaAtS3t7DSErlChydU0ZCLyN9V35h3Y9684XGmBgg=
x-ms-office365-filtering-correlation-id: e2a91ca9-7886-4787-c529-08d4d1eea4bd
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:MWHPR1001MB2333;
x-ms-traffictypediagnostic: MWHPR1001MB2333:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: <MWHPR1001MB23336E62C1124679F6E610A19BBA0@MWHPR1001MB2333.namprd10.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR1001MB2333; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR1001MB2333;
x-forefront-prvs: 0377802854
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39450400003)(39400400002)(199003)(189002)(189998001)(3280700002)(105586002)(3660700001)(93886004)(6512007)(54896002)(229853002)(6306002)(83716003)(33656002)(2906002)(86362001)(478600001)(82746002)(36756003)(97736004)(5660300001)(3846002)(72206003)(106356001)(6116002)(102836003)(14454004)(53546010)(7736002)(2900100001)(4326008)(8676002)(81156014)(81166006)(6436002)(25786009)(2171002)(6486002)(66066001)(77096006)(68736007)(8936002)(6506006)(99286003)(76176999)(54356999)(50986999)(53936002)(101416001)(38730400002)(2950100002)(6246003)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1001MB2333; H:MWHPR1001MB2335.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2017 17:17:05.9279 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 785ce69c-90cf-4dc7-a882-eaf312d1d15d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2333
X-OriginatorOrg: genesys.com
X-MC-Unique: mHelJPa3Pxi5cCyudpaFyw-2
Content-Type: multipart/alternative; boundary="_000_EC5396F698D24A0494E51618BC8A2C5Dgenesyscom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CBHqNGxrgCH9hJjltL1J5goadGk>
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: Mon, 24 Jul 2017 05:31:55 -0000
How about requiring a record of a fixed size that either contains the session key encrypted with a “leaking key” or the output of a stream cipher keyed with the session key. A 3rd party observer would not be able to determine whether the session key is being leaked but the client can tell and act accordingly. --Felix From: TLS <tls-bounces@ietf.org> on behalf of Ted Lemon <mellon@fugue.com> Date: Sunday, July 23, 2017 at 16:34 To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Cc: "<tls@ietf.org>" <tls@ietf.org> Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning. It's actually better for the server to secretly use a static key than to negotiate. Stephen has already explained why: if this is a negotiation, then it's possible for a third party to simply block any negotiation that doesn't allow it. We have no control over evil endpoints, and it's silly to pretend otherwise. Pretending otherwise makes us less secure, not more secure.
- [TLS] datacenter TLS decryption as a three-party … Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Yoav Nir
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Derrell Piper
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… BITS Security
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Tony Arcieri
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Christian Huitema
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Jeffrey Walton
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Felix Wyss
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Sean Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara