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 14:40 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 737951317A4 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 07:40:58 -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 D4M46WDD60Xk for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 07:40:57 -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 0DB8E131C7D for <tls@ietf.org>; Thu, 20 Jul 2017 07:40:57 -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 08:40:55 -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 08:40:55 -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/CxpFoIjfXaLPvrHggAB0dYCAAAVSoIAAApaAgAAC7XCAAATkAIAAJt3g
Date: Thu, 20 Jul 2017 14:40:54 +0000
Message-ID: <cd9e13f908224dc59472cf0e599b56ce@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>
In-Reply-To: <e9f89ee4-9b44-fa2c-84c7-f12bc77f7202@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_cd9e13f908224dc59472cf0e599b56cevenaficom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ELYaFccAiVLDwaiYsYgdu4Fo0dw>
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 14:40:58 -0000




-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Thursday, July 20, 2017 08:22
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?





Hiya,



On 20/07/17 13:04, Paul Turner wrote:

> 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.



Sorry, I'm not sure what you mean there, but guessing, yes, there can be multiple nation state actors who would try to compel use of this mitm, and for a proposal in this space that also causes intractable problems when a connection is supposed to be mitm'd by more than one of those, or one is not clear which is the appropriate nation state attacker to appease.



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. Did I misunderstand?



> Can you reply in that context? I’m truly interested in understanding.

> It wasn’t a “try”.

Hopefully the above helps, but it may also help to say that the appropriate context I'd consider for TLS is essentially all the applications of TLS and all the deployments that'd eventually be updated with whatever proposal is on the table.



Agreed.  It is critical to consider all of the possible use cases.



(Prior to getting it off the table when it's shown to be a bad plan:-)



Cheers,

S.

v2.23.0 | Report a Bug | By Email