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

Ted Lemon <mellon@fugue.com> Tue, 24 October 2017 19:41 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 266CC13A039 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:41:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 4nHy20DGlnRf for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:41:25 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 569CD139D0F for <tls@ietf.org>; Tue, 24 Oct 2017 12:41:25 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id k31so31989480qta.6 for <tls@ietf.org>; Tue, 24 Oct 2017 12:41:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JENlbG5YVMU/JIGsrJ9ZYRK6DgyGX6bmYEi9/E76j5A=; b=TxC7ioDGblj6ERtNwNvJNd+L50Np2SyPkVU7AzopHg1tIagh8EMfR7Mzhty8+cESLr OUmBdsOGB3AMDzl93x3O+YeuBl0ft5tH6NKKvcuRMXhanG4e8+xTnhSqPHKwKPi0N/C9 hn8XjwCDz7zWOG8uVCDiJarw+Ocq8133ZEdXGF57sKsVoLj8jrwWCAHtcHnxMx1CnjoS lqmBnXqWcB5AnXxFeuKxEBk2uYAaAKp1aHZQ9IFGKV4PWN90+sixYnhrgOM8O+dKUpVc hqrTeRhNm1I5BMULx65IBv8EcE3H0irmUN36UPo2VoMZ85xpeiFbIWDg64mMFb0mIQ/T G9ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JENlbG5YVMU/JIGsrJ9ZYRK6DgyGX6bmYEi9/E76j5A=; b=nZmd5Jq5E7bECTT8VLuk1nqhQ6Ffchvpqv2WbEA6Im2OrkVSwDTdv635BDbWa8JTWd bj5rCIsB/iQsHv4DrM1jrCC9QOtGQuvY2UqlSRSh4qcP9QJRGut+komaL9+oFUt3EwBo DCnd14x8yuiMYYNwWxIUVU0Yluw/niFh4vuarLzQOAc4LTgAu/52JhthJrSwRhsbO928 CtWYeoo+5yk2UZbOp+zwYRxAuP5LXo3+FtjrVCdxw/a2XPzJjyC8lC/z90CHkiabUwT2 tEFcbS6zohwQicGpaJVL4KdVI0wW6kFAAkmUDUFuR64ERlpa5ZzwMSXnlwJim4nX7IRP 5obw==
X-Gm-Message-State: AMCzsaWE1p3G0AQYO2W8NQRZ2LwL5ZjMwPbywSzpGq7AYy75X806bJ5W k7QqAiNfGFMpRSwZziUL9JzQzFcL3HE=
X-Google-Smtp-Source: ABhQp+TLyt9i0KDMtwzJR317kgo7pBneEWKt1fHdJjViYpPXUO1MZo3MX5yWCgAisivdpVo+k9W2jw==
X-Received: by 10.200.12.193 with SMTP id o1mr26120514qti.254.1508874084486; Tue, 24 Oct 2017 12:41:24 -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 t5sm731608qkl.10.2017.10.24.12.41.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:41:23 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <60E804DC-11EF-4CCB-A67B-F8B0FCADD4A8@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F8B58B9-634A-4A99-9C2A-7893E8C1DD8B"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 24 Oct 2017 15:41:22 -0400
In-Reply-To: <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com>
Cc: "David A. Cooper" <david.cooper@nist.gov>, tls@ietf.org
To: Ralph Droms <rdroms.ietf@gmail.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <864AA57B-470C-4C1A-A44F-7F12BE57D64B@fugue.com> <89E9E608-0C97-4E2D-9BCD-D3F0837AF1D0@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cejyFnXsNt7lLj3EC83Rqt3j8qA>
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:41:27 -0000

On Oct 24, 2017, at 3:24 PM, Ralph Droms <rdroms.ietf@gmail.com>; wrote:
> ...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?

More likely the client would be failed with one that just automatically negotiates the visibility extension, because that's easier and quicker.

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

I don't think it's necessary to demonstrate that, because the browser that implements this extension will just automatically negotiate it.

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

There's no fig leaf of security if you allow connections with no TLS.

The problem with these proposals generally is that they push us in the direction of picking and choosing who we will allow to eavesdrop on us, and make it non-negotiable in order to access services we want.   You and I are smart enough to say "no" when presented with this choice; unfortunately, at least at present, many people are not, and see things like browser security warnings as annoyances.   This is why UAC failed in Windows Vista, and why Vista was widely reviled for its poor usability.

It is demonstrably the case that users will say yes to things that are not in their self interest to get to the resources they want.   Every time I visit my mom, she has new malware installed on her Chromebook that I removed on my previous visit.

So if we do not say no to this, it's likely that ultimately not enough people will, and a lot of end users will suffer as a result, some of them operating things we'd like to remain secure.   That is the discussion we should be having right now.