IETF Logo Mail Archive

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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 19 October 2017 17:12 UTC

Return-Path: <prvs=1465889b5f=uri@ll.mit.edu>
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 9BF2D134300 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 10:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 kzshaScYy8ew for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 10:12:16 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C76481342FC for <tls@ietf.org>; Thu, 19 Oct 2017 10:12:15 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v9JHCCTK006435; Thu, 19 Oct 2017 13:12:12 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Paul Turner <PAUL.TURNER@venafi.com>
CC: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO713gKFaj/ze3UaJfDxWNuaqP6LqPDwAgAFTKoCAAAWQgIAAANiAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAFZAA==
Date: Thu, 19 Oct 2017 17:12:11 +0000
Message-ID: <D01E6FD7-C141-4039-BDE0-67D66034D6F0@ll.mit.edu>
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> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com>
In-Reply-To: <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; boundary="Apple-Mail-B3B25DAC-787D-4CC1-81DD-692662DAB562"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190236
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VDkR2cFEMO18nPOUkZzOLVschOw>
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:12:30 -0000

If those middleboxes already have sufficient alternative options, why do we spend time discussing this draft? Why do we need to add yet another alternative for them?

Regards,
Uri

Sent from my iPhone

> On Oct 19, 2017, at 13:08, Paul Turner <PAUL.TURNER@venafi.com> wrote:
> 
> 
> 
>> 
>> 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").
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email