IETF Logo Mail Archive

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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Sun, 23 July 2017 16:05 UTC

Return-Path: <prvs=8377653b91=uri@ll.mit.edu>
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 7FB8112714F for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 G45WbSIL4Yg6 for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 09:05:56 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 246A912704A for <tls@ietf.org>; Sun, 23 Jul 2017 09:05:55 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6NG5si1031690; Sun, 23 Jul 2017 12:05:54 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Ted Lemon <mellon@fugue.com>
CC: Ilari Liusvaara <ilariliusvaara@welho.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6AgABH+AD//7+cAIAEFRUAgABfPoCAAB60AIAAGdEA
Date: Sun, 23 Jul 2017 16:05:52 +0000
Message-ID: <CE89217F-972F-4F37-B8BA-925AE1FE8D68@ll.mit.edu>
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: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; boundary="Apple-Mail-B6B58679-BB31-44BB-8715-985F33239231"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-23_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707230253
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3Ehnq6UK6hpz5bksSQJyZrhy_KE>
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: Sun, 23 Jul 2017 16:05:57 -0000

I think there's no way the connection can be established if the third party in control of the network does not allow that. 

My only goal here is to leave fewer possibilities to set the eavesdropping silently.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 10:33, Ted Lemon <mellon@fugue.com> wrote:
> 
> 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.
>

v2.23.0 | Report a Bug | By Email