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

Ralph Droms <rdroms.ietf@gmail.com> Tue, 24 October 2017 19:24 UTC

Return-Path: <rdroms.ietf@gmail.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 5AE621397EF for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 2YbGxfhanSOM for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:24:19 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 1C0931393A1 for <tls@ietf.org>; Tue, 24 Oct 2017 12:24:19 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id v41so31847579qtv.12 for <tls@ietf.org>; Tue, 24 Oct 2017 12:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2kXiibuXBgQcURtB+5QRHlvBBWpZ1VhIxAP568UpU/8=; b=HJEPQ3qSnY3XyheMf4yI7a9Vt9qzbrlaMSQS4+4DxDjDpyPs8ePOVjZevNu1Mv/T4E GFqa4rptgc5bY5CyoaUvI/SbmAKhW8TLymcO8RQ+j1t1DvK0/6cOUFy5uXWQWb1rQJ7G /Qnmwusfaxc6iDBS1hwLD6OcGn2HBMisIgVUq2vjr5pG8fvE02BAzygoG04UCypZeBdN 9hlzjzoygEY7QFsuOjJX0WCv5791nZbRkapeVK75AppEY46jl6/EFbz3Ox5pMZcPUS8c SjmiuGcvDLivcDei06Lv4W7VddUJTSwv7NMKEz706GTKjARbr0grThc4y71iMIaVqaFE nevQ==
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=2kXiibuXBgQcURtB+5QRHlvBBWpZ1VhIxAP568UpU/8=; b=Aw5amfdKt0Jw46zjT6JDlIorh47dNNskrWZWgZdXoWBH9StZsSh3hNWbL4vSIRXY3/ kuRt3Bz/wkwXIZf/FHVDR8NOvtggpD1+YTRaOtcF5tdxJIZsw+VhbHm7Gc3UIiO3xNim EYWphQaOWNVCK0yz+InngegJQ4ExH0MAHAG9SZxwvGClSFn1gN2CM/cSnIKnW4kCb+ky KUhBqbbPN8eZkwDAs9vg8H1UpYjrk7wcivDZna2d2e+evYiZq6sK1ZzXtaE9Ibsmncjl 55XkSLUWzLI1OZpkkJ5yE/9k51+FSRJuWyv18bJkaRVxY2hj4WEKDa719WQnFF2Kefcu bWxw==
X-Gm-Message-State: AMCzsaXCLQhIr4USJRMe0I9Gi60kLsECya0/6doMRSoRqHi4hlzGJHcp 5v+7d4zA828C4ONAU+CQy1Cu8Eyo
X-Google-Smtp-Source: ABhQp+T7MlntvjWykPBskE8qSMDn0CoNjzAzXg9xN7v1byi70LcxHxKByyHDhM7jm7uugucpdebq+Q==
X-Received: by 10.200.48.171 with SMTP id v40mr26423742qta.120.1508873058150; Tue, 24 Oct 2017 12:24:18 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:3db6:d45b:1b54:f2a3? ([2601:18f:801:600:3db6:d45b:1b54:f2a3]) by smtp.gmail.com with ESMTPSA id t18sm742831qtc.58.2017.10.24.12.24.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:24:17 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com>
Date: Tue, 24 Oct 2017 15:24:16 -0400
Cc: "David A. Cooper" <david.cooper@nist.gov>, tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DW6oZetd_WHkAkU5cnQLIAckYOE>
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:24:21 -0000

> On Oct 24, 2017, at 3:17 PM, Ted Lemon <mellon@fugue.com>; wrote:
> 
> 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.

...with the assumption that a client would automatically revert to trying the connection with the visibility extension if it can't make a connection without the extension.  Why would that assumption be useful?  How is this situation different than the current practice of using HTTP if HTTPS fails?

> 
>>> 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.

Can you demonstrate how such an attack would work without the assumption that a client (e.g., browser) would, as policy, downgrade to using the extension if it can't connect without the extension.  I understand the general concern.

> 
>> 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.

I still don't see how step 2 is different than forcing a connection without using TLS at all?  Why is the visibility extension more dangerous than only allowing connections with no TLS?

> 
> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls