IETF Logo Mail Archive

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

Paul Turner <PAUL.TURNER@venafi.com> Thu, 19 October 2017 17:07 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 C437D134231 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 10:07:25 -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 cUnId-HynMAy for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 10:07:25 -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 1DFE3134228 for <tls@ietf.org>; Thu, 19 Oct 2017 10:07:25 -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 11:07:22 -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 11:07:21 -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 11:07:21 -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//+buECAAGpJAIAABTXQgAACtID//5vkEAANLUoAAAM3PJA=
Date: Thu, 19 Oct 2017 17:07:21 +0000
Message-ID: <3d5a0c1aab3e4ceb85ff631f8365618f@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> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com>
In-Reply-To: <4167392E-07FB-46D5-9FBC-4773881BFD2C@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/8W-RDz-ul0qk-uYvhlflIN-rSxA>
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 17:07:26 -0000


> 
> Subverting one CA cuts across a large scale of Internet traffic and might be
> noticed or can be routed around.  

With respect to "be noticed", forcing clients to opt-in seems like it would clearly be noticed. My understanding was that you were saying that the middlebox could block traffic. That seems in conflict with your statement that they can be "routed around". 

>Certificate transparency helps prevent a
> single CA from being coerced into misissuance.  

It seems like a middlebox that is able to deny traffic (has that level of power, would simply use their own CA and force trust of that)

>With this extension, someone
> doesn’t have to coerce a CA or force victims to trust a new CA.  Instead they
> have to gain the cooperation of the origin(s) they are interested in.  

Gaining the cooperation of the servers (origins) seems relevant. If they get the cooperation of the servers, they can simply get the data directly from them. But, again, they also have to get the cooperation of the clients. 

If a middlebox has sufficient power to block traffic, force clients into opting in, and coerce servers into opting in, it seems like they have sufficient alternative options that are of equivalent effort ("ease").

v2.23.0 | Report a Bug | By Email