IETF Logo Mail Archive

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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 20 July 2017 20:42 UTC

Return-Path: <prvs=837464833d=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 F0A62131B74 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 13:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 RdDtBiNiSnXe for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 13:42:12 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3345B1316A1 for <tls@ietf.org>; Thu, 20 Jul 2017 13:42:12 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6KKgBUT007318; Thu, 20 Jul 2017 16:42:11 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
CC: "<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+cAA==
Date: Thu, 20 Jul 2017 20:42:10 +0000
Message-ID: <17109486-336E-44C0-B9FC-D65EE14310B5@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>
In-Reply-To: <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3583413730_1809210182"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_11:, , 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-1707200317
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IP8FChTuk5uiJZ-rkMho8OeD5Zs>
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: Thu, 20 Jul 2017 20:42:14 -0000

On 7/20/17, 16:32, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
> Maybe we are better off just retrofitting RSA-key-transport back
    > into TLS-1.3? 
    
    This has in fact been requested. Kenny Paterson said about the request:
     -----------------------------------------------------------------------
    My view concerning your request: no. 
    Rationale: We're trying to build a more secure internet.

My rationale to resurrect it: others are trying to push TLS-1.3 into an invisibly-insecure state. If we must satisfy them (and I’m not at all sure we should), then this is the most obvious way to at least avoid the “insecurity” being silently pushed upon you. At the very least you’d have an option to continue under surveillance or abort connection.

v2.23.0 | Report a Bug | By Email