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

Paul Turner <PAUL.TURNER@venafi.com> Thu, 19 October 2017 15:06 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 CEC54134932 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 08:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.292
X-Spam-Level:
X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jRlNRehG-Yfm for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 08:06:41 -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 30AE9134939 for <tls@ietf.org>; Thu, 19 Oct 2017 08:06:40 -0700 (PDT)
Received: from SLC-EXG01.res.venafi.com (10.1.110.17) 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 09:06:38 -0600
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_256_CBC_SHA384_P256) id 15.1.1034.26; Thu, 19 Oct 2017 09:06:37 -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 09:06:37 -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//+buECAAGpJAIAABTXQ
Date: Thu, 19 Oct 2017 15:06:37 +0000
Message-ID: <d76828f02fc34287a961eba21901247b@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> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com>
In-Reply-To: <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/chJZgnidltl409YN0H3mvpgnW_A>
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 15:06:42 -0000


> 
> With this extension, any middlebox anywhere can drop traffic that is not
> tappable.  Regardless of who controls the clients and servers, we are now
> enabling entities to block traffic unless you acquiesce. For example, an inflight
> wifi could use this.  Maybe, ultimately, many/most of the servers that the
> passengers connect to will not support it, but some might.
> 

Can't any middlebox block traffic today if the client doesn't agree to trust its CA? If a middlebox drops traffic because the extension was not included, there will be no indication to the client that it was dropped because they didn't include the extension. If the middlebox does display a page back to the client saying "You have to turn on TLS-Visibility so that we can we can look at traffic for a server that we have control over but don't want to get the data from this directly.", how is that different than "You have to trust our CA in order to communicate with this server so we can route you through our reverse proxy. Please download our CA root from the following location and install it."?

The second seems much easier in terms of scenarios 2 and 3 from my previous message.

Paul