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

Ted Lemon <mellon@fugue.com> Tue, 24 October 2017 19:17 UTC

Return-Path: <mellon@fugue.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 9EBAE138F9C for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 sxfblamTD93Y for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:17:52 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619401386F3 for <tls@ietf.org>; Tue, 24 Oct 2017 12:17:52 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id z28so31847011qtz.13 for <tls@ietf.org>; Tue, 24 Oct 2017 12:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zaJGYUWPDMSERfJVTYdx9yvC8vG/5cu/4FQlzP8hw3g=; b=bz9htvQMCB4vCUBnymDHLtlzmveXWRQQyASfYvGy/kwHWqS0R35KYP5tRdkMy+d7YI qAeMUNehsILTQajT2w3vQZilvwsk8/gIW4OL4Fekn+tWCtWA8PFvY4U/PLbbBKVQHLAT fiX+6jsBF/yJiVQmOdz+PrfvvG7+CZVqM0piHd1awtRkYzZ/E0gWg+Yq/1sMoQUdlgcR 9818k6ITT7m31LCRjgSFi0+c2XZWVLIa+58oi3vFBtzp9fQf5qxgksF5D0tKtnx0hW1p jmokKWh/Qj5kFjHYWiBhDdiyfyWZhal43A6RWX8N+IEwGXormqmEu4+m20Fmo0UH/CJC AfVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zaJGYUWPDMSERfJVTYdx9yvC8vG/5cu/4FQlzP8hw3g=; b=agDMCIO3Lf/6b0Krr8JnIK8oQlfBbwsZpGt7oyoKkifWL7alhowL6RM0mMTIaweGCI kxMfd5vG+jO2m/C/c3Wsci0Rtc+HZRQTF/BI/LjCyvo76qtTLIFhh9NcqZBr3gZrxGym IulPAF83WxHawePqWtu0OR1xAMydd8RIwI2+1XU2jVfA/ocZsnPyHuF/BR1F36pzGBYQ 7FIfpxFWdNHb1jHTDt6gLKSjAOojOSOtJcZYQ6yi/FsTk+i9UApQFACgRzqpg5Bso28F C+17jgIMlae8TrHyHE3OFhb7odi3qCvg+95dFjVASMoqYPilkGq9jDSv/bmb88Ni4Tzg 2rlQ==
X-Gm-Message-State: AMCzsaUI0ePJVlA+RIOFoCON2ubQMabQsI7kShq2Nr79ZKUf8UnwZNr4 njr5fwdUV+1SEgZ5D8OecqkP3A==
X-Google-Smtp-Source: ABhQp+Qf2EGnameYBh70GQIlFtP+Yz216n1xoY9iH91DSfvZH5lrgaVIGZ3Aj08/p7gjpnP2G6NPHA==
X-Received: by 10.200.3.31 with SMTP id q31mr26147509qtg.284.1508872671470; Tue, 24 Oct 2017 12:17:51 -0700 (PDT)
Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a190sm677356qkg.15.2017.10.24.12.17.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:17:50 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov>
Date: Tue, 24 Oct 2017 15:17:49 -0400
Cc: "Salz, Rich" <rsalz@akamai.com>, tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov>
To: "David A. Cooper" <david.cooper@nist.gov>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RlAUKDkpk3n8Kwwi2tNxLcT8STg>
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: Tue, 24 Oct 2017 19:17:55 -0000

On Oct 24, 2017, at 3:04 PM, David A. Cooper <david.cooper@nist.gov>; wrote:
> In order for a middlebox to be able to use this draft to intercept traffic that is TLS protected, it would need to:
> 
> 1) get the server to agree to allow it to intercept the traffic; and
> 
> 2) get the client to include the new extension in its ClientHello.
> 
> How would the middlebox get the client to include the extension.

Block all TLS connections that don't use it.

>> I believe I know why people want this now. They are worried that if TLS 1.3 goes out without something like this, then the market (standard widely available browsers) will not implement it. Let me assure you that this isn’t an issue. The extension would *never ever* make it to the MUST state, and the browsers would be unlikely to ever implement it anyway.
> 
> I partially agree with this and partially disagree. I agree that browsers (and other similar clients) would be unlikely to ever implement it. I disagree with the suggestion that proponents of this draft want for browsers to implement this or want it to be a MUST. Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.

Let's be clear.   While I may have made some statements about the balance of concern over who pays for this, nobody is saying that the proponents of this draft intend a nefarious use of this extension.   The concern is not that BCBS is going to invade my privacy.   It is that if BCBS gets its way, someone _else_ will use this technology to invade my privacy, or to trojan horse some malware onto my computer, or some other attack.

> So, given your agreement that browsers would be unlikely to ever implement this extension, how would the in-flight WiFi (or other middlebox) be able to get clients to include the extension if the software they are using doesn't support it? It seems that the only way would be to coerce the clients into using a browser (or other client) provided by the attacker (i.e., in order to use the Internet while in flight you must install Evil Airline's browser/app). But then, if the attacker is able to get the client to install and use its own software, then it would easily be able to intercept all traffic from the client, not just traffic to cooperating servers, so why would it bother using this draft at all in this case?

You've inverted the chain of causality here.   The chain is (to the best of my ability to explain it, anyway):

1. Standardize this extension
2. Someone with a service people want to use starts blocking connections that don't enable it.
3. Browser vendors are forced to implement it, or end users are forced to download special browser software.
4. Now an attack surface exists on the user's machine that hadn't previously existed.
5. The user's machine is now subject to attack by a larger set of attackers than it had been previously, using a larger set of attacks than were available previously.

None of this is a smoking gun.   If everybody keeps all the plates spinning, we won't have a problem.   The problem is that everybody keeping the plates spinning is something that pretty much doesn't happen in the real world, as we've seen if we follow the news.   And some of the everybodies in this equation are operating infrastructure that we really, really need to be well protected.   And others are being stalked.   And still others are trying to do secure transactions online.