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

Bill Frantz <> Wed, 12 July 2017 00:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD782131705 for <>; Tue, 11 Jul 2017 17:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ZZ982E7sosF for <>; Tue, 11 Jul 2017 17:42:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 566E113181E for <>; Tue, 11 Jul 2017 17:42:48 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1dV5jq-0006zr-Vn for; Tue, 11 Jul 2017 20:42:47 -0400
Date: Tue, 11 Jul 2017 17:42:47 -0700
From: Bill Frantz <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r470Ps-10125i-9701DDD91F704B63AC879FF9EE01DBC0@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79d5084e92f929c64ac9c6b4f05d0e24fa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
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 00:42:50 -0000

I must admit that I mostly agree with Stephan that this kind of 
thing should not exist. However, it exists now, and the chairs 
have decided we should at least discuss it.

I think there are many ways to meet the "requirements" of 
network monitoring and protocol debugging, and some are worse 
than others. Leading the world in the direction of the least 
damaging ones seems to be the bese way to deal with a bad situation.

The major threats I see include:

   Coerced use by oppressive governments.

   Use outside the immediate private network

   Use by an ISP on its customers

   Use without both ends being aware that it is in use.

I think coerced use is by oppressive governments is an obvious 
bad and I hope I have working group agreement on this point.

Limiting the protocol to the immediate private network will 
prevent 3rd parties from activating it to spy on the enterprise. 
One possible way to enforce this limitation is to require 
compliant implementations to limit broadcast of decryption 
information to the IP addresses on the local subnet.

I would be nice to be able to keep an ISP from spying on its 
customers as part of its "private network". However, I don't see 
how to differentiate an ISP's network from a enterprise network.

If it is not technically possible to use the protocol without 
both ends being aware that it is in use, then user interfaces 
can reflect its use. One result would be that enterprise users 
would be continually warned that their messages aren't private.

Any technical fixes we build into the protocol that prevent 
these actions are a positive improvement.

Cheers - Bill

Bill Frantz        | If you want total security, go to prison. 
There you're
408-356-8506       | fed, clothed, given medical care and so on. 
The only | thing lacking is freedom. - Dwight D. Eisenhower