IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Fri, 20 October 2017 14:08 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 4FF3313339A for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 07:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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 r6t5WgqiTZx4 for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 07:08:48 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 7C2C1132C3F for <tls@ietf.org>; Fri, 20 Oct 2017 07:08:48 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id b15so14428876qkg.9 for <tls@ietf.org>; Fri, 20 Oct 2017 07:08:48 -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=N2YGfET3HehIYcjSpYN13KPcooV1/Ogi7w/JdTRDk+Y=; b=QDDwM7+M9jPbXXYD0ZTEh9btfK7xurI/OPMgKMZDA9z5iu5aeIkVE1p0JU7WBFQmwq KpIqJTn++nio6XC8vHT13gFAvc+jbQZvt2VvtVkYKjVlkjBrA/BFSCFO9gVC2R5PthcV sFkGOyrr88JEkpnIzJsGSSOTQXjQ+2RtFMRRTYnL/E4BLPvmjXk83QTgjCrjua0kNFHl jzGSaZkrSf5Dd8ekyKkcIYLfJ3W9q2wa9l6rZg8UxrdHflaE8ds3MPvkvE4o6NswZtYJ Q7SUqNFz8Uepho+HseOtBsPhljwdmc6i9k8mQqbLyLjn9YhQMY/c3/Nr2q6extU0PBYp fEoA==
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=N2YGfET3HehIYcjSpYN13KPcooV1/Ogi7w/JdTRDk+Y=; b=U91p1KGYEJlJARoBKBbMRTzCyQhT4rOd0vnl2fMtVR7DbmTNoRADlI18sKA6vF+ZMy B3aKq7//OXJufm45vLzg3cNi3DM/D9gGzLlTflSiuT2147aKtRJ85X01FLRiCjl30iLJ wJHXbNZOWePoVX2cxw7/FyS85Ydb984VrI6EjGWyFdwcvfVzC1funZXXEkg3RKMa3W1O UWYJrrkMibjQO7fxcocHNy/YUlHjZYb8D7lfRXV4xkpN3T4Tmm/IUIkfvVMvcqSwnLzn HF+ewoGCtCGw6hCgCE93RDJwrAfdUA9HIe7Gry+RqXezcnuWlw/aorHDTu+BaLMBd4/R WTCg==
X-Gm-Message-State: AMCzsaW2iiQYxI2z1WTLd0b7rRICPHCtWzLtwcoi6WI8VPmEDJWnPg+I CgSkKRhEP6r03TXzt/Ye5jxWtw==
X-Google-Smtp-Source: ABhQp+SqGYdP4hiIEkngD/iz+fIJQzCA2E3GVNIq1qngaTTpBq0SRJZnHrPeFgaQhnyQbfbKR30tIA==
X-Received: by 10.55.179.198 with SMTP id c189mr7250892qkf.211.1508508527540; Fri, 20 Oct 2017 07:08:47 -0700 (PDT)
Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id v30sm639387qtg.88.2017.10.20.07.08.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 07:08:46 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <E9573C0C-15F2-4622-B7F8-0A449A5A1F98@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E291C3C7-0089-4B6E-9D28-2C1ED3111FB5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 20 Oct 2017 10:08:44 -0400
In-Reply-To: <d18d8e26-33ef-2147-8755-4d0b86b0a45f@cs.tcd.ie>
Cc: "Salz, Rich" <rsalz@akamai.com>, Darin Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <d18d8e26-33ef-2147-8755-4d0b86b0a45f@cs.tcd.ie>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AARecn6ZR5stD38t0RrFLBhAHxA>
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: Fri, 20 Oct 2017 14:08:50 -0000

On Oct 20, 2017, at 9:54 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> Others did
> comment that the lack of client opt-in was a
> bad aspect of draft-green, but I'm not sure
> that anyone clearly said "I do want draft-green
> snooping, but with client opt-in."

I can say for myself that there was a really strong hard sell on the notion of doing this in Prague.   Not being sufficiently paranoid, my general sympathy for people facing hard problems led me to consider what they were proposing, but each time they came up with something, someone with more paranoia fu than I have pointed out a hole in it.   During that period there were several periods when I was reluctantly willing to consider some less-bad version of draft-green.   This is a long way from "want," and even a pretty long way from "support."

My personal feeling having been peeled off the herd and hard-sold like this is that there is some really powerful motivated reasoning going on here, and that the working group should just stop entertaining this process.   Weakening TLS is not the right way to approach the problem that has been described here.

I hasten to add that I don't think the people doing the hard sell are bad people, or that they didn't have good reason for trying to do it.   My point is simply that we've been collectively sucked close to a black hole here, and we need to take a step back from it.   In the same sense that LEOs who want key escrow have good reason for wanting it and are not bad people for wanting it, so too with the people pushing this proposal.   But like key escrow, this proposal is not beneficial for end-users or for security as a whole.

In order for it to make sense to go forward with this proposal, two things would have to be true that I don't think are true.   First, we would have to agree that user security is not a primary goal.   And second, we would have to agree that overall network security is not a primary goal.   Discussing the details of how much security we are willing to give up, what attack surfaces that we could remove we are willing to leave in, only makes sense if we are willing to drop those two primary goals.

Watching this conversation has been a really good learning experience for me, so I don't regret it, but I think we should stop.

v2.23.0 | Report a Bug | By Email