Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Paul Turner <PAUL.TURNER@venafi.com> Thu, 19 October 2017 14:37 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 B0728134921 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 07:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Level:
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_20=-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 3FmtNWP3GCJ9 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 07:37:49 -0700 (PDT)
Received: from mail.venafi.com (unknown [34.193.116.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB55D1342F1 for <tls@ietf.org>; Thu, 19 Oct 2017 07:37:49 -0700 (PDT)
Received: from SLC-EXG02.res.venafi.com (10.1.110.18) by AWS-EXG01.res.venafi.com (10.50.110.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:37:47 -0600
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_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 08:37:47 -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, 19 Oct 2017 08:37:47 -0600
From: Paul Turner <PAUL.TURNER@venafi.com>
To: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQDO0nP6IcKCRq1bnEFoblkG8dV0CgHq1icUpOTCoYCAAG+9gIAAANmAgAABFgD//5uPgIAAZaGA//+buEA=
Date: Thu, 19 Oct 2017 14:37:47 +0000
Message-ID: <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com>
In-Reply-To: <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [75.115.210.166]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bu3xvPc6mz1Rwf8Aq25ifL7wU64>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 19 Oct 2017 14:37:51 -0000


> 
> There’s no way to limit it to the use-case it was putatively intended for.  We
> now have a signaling mechanism that says “allow interception.”  Firewalls can
> drop connections where the client doesn’t send that extension. Therefore they
> can force only tappable TLS traffic. This makes the job easier.
> 

Can you please be more specific about the scenario(s) you're describing? 1) Is this for communication between servers within the nation state's boundaries and do they have complete control over the owners of those servers (totalitarian state). 2) Is this for communication between servers within the nation state's boundaries and do they not have complete control over the owners of those servers (an apparently democratic state). 3) Is this for communication between servers outside the nation state's boundaries and do not they not have complete control over the owners of those servers (international scenario). And, based on the scenario, how is the third party going to coerce the server vendors into cooperating (for 1, that seems clear, but then they have complete access to all communications anyways)? I'm not just asking these questions to be difficult. I would like to better understand the scenario in which a client and server can be coerced so that it is possible to judge "easier" against the alternatives.

> I take it you want to see this draft adopted?
> 

Yes but I'm also keeping my mind open to understand all of perspectives to see if something would change my opinion.