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

Stephen Farrell <> Mon, 10 July 2017 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D264127735 for <>; Mon, 10 Jul 2017 14:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lz3-wW0nokjF for <>; Mon, 10 Jul 2017 14:17:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 637BD12EC05 for <>; Mon, 10 Jul 2017 14:17:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEB7ABE2F; Mon, 10 Jul 2017 22:17:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aixA6urwMeBx; Mon, 10 Jul 2017 22:17:37 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2D9DCBE2C; Mon, 10 Jul 2017 22:17:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1499721457; bh=wMcV9F11E7wfsGe45c7ZRkUjb2luRanZlh6+xk8OVFc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wbNvVq54sAhxkKfUklD+Vb0i4ES9ZTwDmRnFom7VrB5eRqKNqz2p0/xCm9vgeJhrI AFuWvby1kO2mxYhQcIH8Mv1fhqYYSIkEvXHkMgNHc6Axz3FzeBHTYhmF2PHc2Q4xQK cz1aWyW0WMKRpp5XXqOTinQcXgtETa6KHAhbmcQ4=
To: "Ackermann, Michael" <>, "Polk, Tim (Fed)" <>, "" <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Mon, 10 Jul 2017 22:17:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cciNJrR9LGLh67KX7svETKfI65QUVdCnL"
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: Mon, 10 Jul 2017 21:17:43 -0000

On 10/07/17 21:20, Ackermann, Michael wrote:
> Then we read 2804 differently.     When I read 2804,  the contained
> discourses on what is and is not wiretapping,  clearly says to me,
> that what Enterprises do within their networks,  is NOT wiretapping
> according to 2804 (or to me for that matter).

You're misunderstanding what 2804 says and what the
IETF is about. 2804 says nothing about your, or my,
network at all. You are free to define middle-endian
ordering and three-valued bits if you want or to do
whatever forms of wiretapping you like in your n/w.

2804 is instead about standards track protocols as
specified by the IETF, which are used in many networks.

In the case of TLS the changes for which you are
arguing would clearly enable wiretapping in many networks
and the draft is therefore clearly inconsistent with 2804
and the standards track.

And to avoid a repeat of Russ' failed justification, many
protocols use and depend on TLS where the entity controlling
the TLS server private key materials is not the higher
layer sender or receiver, so all four points in the definition
in 2804 are fully met by your wiretapping scheme. If you want
examples, think about STMP with STARTTLS or CDNs and the web.
I'm sure there are loads of others.

Bottom line: that draft is a wiretapping draft.

At best, it ought be an ISE RFC, and even then I could see
arguments against that if what is documented has not actually
been deployed. (That last seems to me to be needed to acquire
the utility of publication described in 2804 - RFCs about
speculative schemes don't seem to me to offer any value
at all.)


> We (and many others in this discussion),  have different
> perspectives.   Perhaps this is a contributing reason the Chairs
> determined it should continue.     I sincerely hope this will lead to
> some mutually acceptable dialogue and related solutions.
> -----Original Message----- From: Stephen Farrell
> [] Sent: Monday, July 10, 2017 3:37
> PM To: Ackermann, Michael <>;; Polk, Tim (Fed)
> <>;; Subject: Re: [TLS] chairs -
> please shutdown wiretapping discussion...
> On 10/07/17 16:30, Ackermann, Michael wrote:
>> Given the above scenario,  I do not understand how this can be
>> construed as "Wiretapping".    2804 seems to make this clear.
> TLS is much more widely used that you seem to imagine.
> Please see the comments to the effect that there is no way to control
> to location of the wiretap/TLS-decrypter in the protocol.
> If that's not obvious, I don't know how to explain it further.
> See also text in 2804 wrt tools being used for more than initially
> envisaged.
> And if coercion of a server to comply with a wiretap scheme like this
> stills fanciful to you, please check out the history of lavabit - had
> there been a standard wiretap API as envisaged here it's pretty
> certain that would have been the device of choice in a case like
> that. While it's easy enough to envisage many other abuses that could
> be based on this wiretap scheme, that one is a good match and a real
> one.
>> Such critical colloquy,  with significant long term impact,  should
>>  not be prematurely terminated,  IMHO
> "Premature" is nonsense, this debate has gone on too long already.
> S.
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any unintended
> receipt and delete the original message without making any copies.
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue
> Cross and Blue Shield Association.