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 15:23 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 E628D131CE6 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:23:29 -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 5x7ubT_hMfkf for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:23:28 -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 26A94131C43 for <tls@ietf.org>; Thu, 20 Jul 2017 08:23:21 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) by SLC-EXG02.res.venafi.com (10.1.110.18) 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 09:23:20 -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 09:23:20 -0600
From: Paul Turner <PAUL.TURNER@venafi.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XCAAATkAIAAJt3ggAAEtQCAAAcpsA==
Date: Thu, 20 Jul 2017 15:23:19 +0000
Message-ID: <6a05aa8a00b847b9aac5fd020a57c928@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> <373f65c7c1e8483c9efdf06bbc5671cf@venafi.com> <e9f89ee4-9b44-fa2c-84c7-f12bc77f7202@cs.tcd.ie> <cd9e13f908224dc59472cf0e599b56ce@venafi.com> <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
In-Reply-To: <4b3855e4-0d37-bf25-5215-1ff179c13c59@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [70.197.8.30]
Content-Type: multipart/alternative; boundary="_000_6a05aa8a00b847b9aac5fd020a57c928venaficom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ApCe2PBHkA_c-8jL__jxdvtqx0Q>
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 15:23:30 -0000




-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 10:58
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 15:40, Paul Turner wrote:

> I’m assuming that you’re referring to multiple nations being between

> the TLS client and server. If a TLS client is set to not include the

> extension, it seems the TLS client would simply close the connection.

> It seems the client could choose whether it wanted to appease the

> nation states.



Through how many nations states did this email travel between you and I? Mail is maybe worse than the web, but that's just with our current deployments but who knows when they'll migrate a 5G VM for a web server close to my base station?



Can you clarify on the scenario a bit? Is one or more of the MTAs in the nation state (that wants to listen)? If so, it seems the nation state can get to the data with options 1, 2,  or 3 in my earlier message (options that are available with TLS 1.3 today). They don’t have to attempt to circumvent the method Russ eluded to at the beginning of this thread.



I'd assert there's no way TLS clients in general could know when to set or unset the "please wiretap me" evil bit in a ClientHello, regardless of how complex a configuration is used.



It seems like the guidance would be for all TLS clients to NOT include the extension by default. Anyone who wanted to enable it on their TLS client would have to explicitly turn it on through configuration. Since the client wouldn’t include the extension and the server would know that the client would abort the connection if it included the extension in return (a violation of TLS 1.3), the server would simply proceed in killing the connection itself. It doesn’t seem like there would be the need for complex configuration decisions to be made by TLS client users who have no intention of enabling it. Is that correct?



Cheers,

S.

v2.23.0 | Report a Bug | By Email