Re: [TLS] chairs - please shutdown wiretapping discussion...

Ted Lemon <> Wed, 12 July 2017 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14DF713169C for <>; Wed, 12 Jul 2017 05:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rbdwpooIx-fe for <>; Wed, 12 Jul 2017 05:57:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AC5512EC0F for <>; Wed, 12 Jul 2017 05:57:54 -0700 (PDT)
Received: by with SMTP id 16so21681831qkg.2 for <>; Wed, 12 Jul 2017 05:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p+EVI1nsy54hdY3Nq6WywqwHqxekIYInnJdcw+c1rQ4=; b=vS47xGgMvtFP5o3NWxfmKDmH57zd/CmsIqJiURkp/Jl9eiTyXXEb8xWlYW5kOyRxvN SQ7KJP2WOzM+S9X33wrEC+0LhN+ItNpNZlD+w7jmnQ4Cyu5lQ6ad7dxqs02OG2yVSBCL RAH6FiKmK8MOHJp+JK+dGc91OzNu35odMFsN+fGh5X0+EdeFejlKvjkwNKEJYwWyqNi8 0Dj+uFfOZV9n1uX8dxjDoo6jTod4rhsX4IEkqkgbWdbZv6hRVqXnPjJn0fjVYDLtQeTv kPR5WS73JpZ2FKIXR2lBbhfMAcuTEuD7IsY8OrEbOO5BNWy1rFk9bbga7XFYMU1fxGZS KryQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p+EVI1nsy54hdY3Nq6WywqwHqxekIYInnJdcw+c1rQ4=; b=FZNTnD08KPpX8bQQMwVvxkmMHK6EYio4iNc/ruL9s7Z8iWN8+5/uIM868tdTwXjhm+ Mb5RDUnEC1auZm12BYISyk3rs7TTMdin06XZw2y0EDWnjKiRuzKAHbOeku3yLFUe8GXU dbMG/MwuIEZYCv3xKYyldZJd+lvmz3wQYQt/Uo8rlKfrdgo7FLv1dd2H7RCJQs9O1uHp I5iRN8x8vMq7qYEsD6nlzqTeyDNVVGsV1aJ6I+69GCIW26ATxYi3gSpoXEFcf0Mqux30 XzDbatQR4qbDMfKesr9WaTbv1yh8PO2bXRWMz05HCUzpROQb8fOcMzf02JwHdVx06KTa E4Kw==
X-Gm-Message-State: AIVw1115oElotIClWM4wqAOaF+t+WtGyglWPA7i1k6qYq+iX5svkcpj1 V2mSrQmGILBXPmwVzaPRDg==
X-Received: by with SMTP id o13mr5533881qkh.116.1499864273657; Wed, 12 Jul 2017 05:57:53 -0700 (PDT)
Received: from macbook-pro-6.w50.lede.home ( []) by with ESMTPSA id c18sm1834748qtd.62.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 05:57:52 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_09A7FDCB-CB08-4CD2-BC6F-53B651453A04"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 12 Jul 2017 08:57:51 -0400
In-Reply-To: <>
To: Kyle Rose <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jul 2017 12:57:57 -0000

On Jul 12, 2017, at 8:24 AM, Kyle Rose <>; wrote:
> Much of this conversation seems to conflate wiretapping with collaboration. 2804 has a clear definition of wiretapping:

The problem is that in modern times we can't assume that collaboration is consensual, so the rules in RFC2804 aren't as applicable as they were.   There's no way to have the consensual collaboration use case without enabling the non-consensual use case.   Anything we do that makes it easier to enable the non-consensual use case is a bad idea.   So in my mind RFC 7258 is more applicable here than RFC 2804.

The problem with arguing this on the basis of whether or not there is a non-wiretapping operational use case for this is that there is a legitimate non-wiretapping operational use case here.   As I understand it, the motivation for doing this is to be able to avoid deploying different pieces of DPI hardware differently in data centers.   That's a legitimate motivation.   The problem is that (IMHO) it's not a good enough reason to standardize this.

I would much rather see people who have this operational use case continue to use TLS 1.2 until the custom DPI hardware that they are depending on is sufficiently obsolete that they are going to remove it anyway; at that point they can retool and switch to TLS 1.3 without needing support for static keys.   The advantage of this is that simply using TLS 1.2 signals to the client that the privacy protections of TLS 1.3 are not available, so you get the consensual aspect that Tim was arguing for without having to modify TLS 1.3.