IETF Logo Mail Archive

Re: [TLS] Is there a way forward after today's hum?

Paul Turner <PAUL.TURNER@venafi.com> Thu, 20 July 2017 12:04 UTC

Return-Path: <PAUL.TURNER@venafi.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 45C6212EA7C for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 05:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 BAm_dmwE2Sqs for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 05:04:17 -0700 (PDT)
Received: from mail.venafi.com (unknown [198.190.131.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B183F126E3A for <tls@ietf.org>; Thu, 20 Jul 2017 05:04:17 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG01.res.venafi.com (10.1.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 20 Jul 2017 06:04:16 -0600
Received: from SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6]) by SLC-EXG01.res.venafi.com ([fe80::e9c4:73d1:e66e:cff6%12]) with mapi id 15.01.1034.026; Thu, 20 Jul 2017 06:04:16 -0600
From: Paul Turner <PAUL.TURNER@venafi.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Paul Turner <PAUL.TURNER@venafi.com>, Ted Lemon <mellon@fugue.com>
CC: Robin Wilton <wilton@isoc.org>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQGZY5pvJzH4JA3szzi/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XA=
Date: Thu, 20 Jul 2017 12:04:16 +0000
Message-ID: <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com>
References: <BN6PR06MB3395E47F181D02D5772EEC81BFA70@BN6PR06MB3395.namprd06.prod.outlook.com> <bbd5d287b07d4e5aac7cbd3add41da03@venafi.com> <CAPt1N1kRf-Z_FnK8pmRH_hp7wKTYPW1zu55136Dmp2jF7vgH3w@mail.gmail.com> <691913e7a5d1464e8dda20c8848f6149@venafi.com> <dbd1a70d-c5cf-89b6-36ee-6d5b672fda99@cs.tcd.ie>
In-Reply-To: <dbd1a70d-c5cf-89b6-36ee-6d5b672fda99@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [70.197.5.35]
Content-Type: multipart/alternative; boundary="_000_373f65c7c1e8483c9efdf06bbc5671cfvenaficom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UT-wBrd33Tgv9sP4iJ36OnDOxf8>
Subject: Re: [TLS] Is there a way forward after today's hum?
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 12:04:19 -0000




-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 07:54
To: Paul Turner <PAUL.TURNER@venafi.com>; Ted Lemon <mellon@fugue.com>
Cc: Robin Wilton <wilton@isoc.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Is there a way forward after today's hum?







On 20/07/17 12:44, Paul Turner wrote:

>

> I believe Russ was outlining a method where an extension would be

> added to TLS 1.3 that would provide for delivery of a decryption key

> to a third party during the handshake (correct me if I got that wrong,

> Russ). Because it would be during the handshake, it would seem to be

> visible to the TLS  Client—in fact, the client would have to include

> the extension to begin with. If the TLS client saw the extension and

> did not consent, it could abort the connection. If the TLS Server were

> attempting to provide access to the exchanged data to a third party,

> it would seem they could use 1, 2, or 3 above and not have to go to

> the trouble of attempting to subvert the mechanism that Russ proposes

> (and others have previously proposed).

Yeah, good try, but *which* third party?



Let’s use the oppressive government institution that I believe you’ve mentioned (pardon me if I got that wrong) with a connection over the Internet in this case. Can you reply in that context? I’m truly interested in understanding. It wasn’t a “try”.



The kind of (IMO) intractable questions that Would arise include whether or not enterprise clients only want their own snoopers to snoop and not everyone else's? And then the naming issues become intractable. And of course in many applications (e.g. SMTP) there's still >1 TLS session in the mail e2e path. And in the web there can be >1 box between the browser and content site. Yoav already brought up another one about about:config, and, and, and...



In the end, this'd be another failed proposal is my bet.

I volunteer to help in the engineering of that if needed;-)



That's not to doubt or deride the folks posing illformed requirements but because squaring circles is just not a good plan.



S.

v2.23.0 | Report a Bug | By Email