Re: Review of draft-mm-wg-effect-encrypt-09

Christian Huitema <> Fri, 07 April 2017 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DAC7128B8E for <>; Fri, 7 Apr 2017 15:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Status: No, score=-2.621 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmRZMnmXeZsJ for <>; Fri, 7 Apr 2017 15:31:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C05B112714F for <>; Fri, 7 Apr 2017 15:31:25 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <>) id 1cwcPc-0002zp-13 for; Sat, 08 Apr 2017 00:31:25 +0200
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1cwcPZ-0002ml-3e for; Fri, 07 Apr 2017 18:31:23 -0400
Received: (qmail 21848 invoked from network); 7 Apr 2017 22:31:19 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 7 Apr 2017 22:31:18 -0000
References: <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Fri, 7 Apr 2017 15:31:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tRjemhPmvrkcBRqDaXrwuTBOeUdstdI5A"
Subject: Re: Review of draft-mm-wg-effect-encrypt-09
Authentication-Results:; auth=pass smtp.auth=
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.12)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoPCVymTWz1uTkktataArLFRcOb18WfxGyg6Om6u4YYm9TyXzfF3J6jTvvI 6UncKfo5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qnTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0tNqH1SeM PJJ05aeBYzCpn7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/klMQ2q4n8BL2ta15Q6ywoQ6tlBUQ0Dl04Q1 kcE1KDT0GyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+afg30EnuC0exlTpeePYDi+Ke72V7y3QDXL8JTpxprEN
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Apr 2017 22:31:34 -0000

On 4/7/2017 12:37 PM, Eliot Lear wrote:
> On 4/7/17 5:24 AM, Martin Thomson wrote:
>> To the extent that we have the tools necessary to protect against pervasive
>> monitoring, we have to accept that more-legitimate uses of monitoring are
>> collateral[...]
> ... DAMAGE.
> You couldn't even say the word. 
> The whole point of the document is to expand upon the implications of
> what operational practices are impacted in an encrypted world.  That
> doesn't mean people should stop encrypting, but it does mean that we
> should understand what is breaking.  To do otherwise is to stick our
> heads in the sand.  Let's not do that.  And let's not question whether a
> particular function is "legitimate" which ironically applies a value
> judgment, something that you yourself complained about.
> Better to focus on whether the impact of encryption has indeed been well
> documented.
Having read draft-mm-wg-effect-encrypt-10, I agree with Martin. This
draft is hard to read, and provides a confusing mix of business goals,
techniques, and complaints. My personal recommendation, like Martin's,
is that it would benefit from a thorough rewrite before publication.

I also agree with Martin's recommendation to leave QUIC out of this
business, since it is not standardized yet. The proper place for the
QUIC related text is in a contribution to the QUIC WG.

The draft presents a number of practices, but does not really articulate
practices and business goals. In fact, it starts from the practices,
instead of starting from the goals. My recommendation would be to start
by articulating the "business goals" such as Parental Control, Spam
Filtering, Phishing Prevention, Data Leak Prevention, Insertion of
Super-Cookies, Traffic Engineering, Traffic Prioritization, Data
Compression, Traffic Intercept, Censorship, or Load Balancing. The draft
could then explain how each of these goals are performed by a variety of
techniques, some of which are deployed on the end points, and some other
at various places in the network using a variety of techniques,
including header analysis and deep packet inspection. And then the draft
could have another section explaining how network-based techniques may
or may not be affected by the deployment of encryption.

As a bonus point, we could also note that many of the business goals are
somewhat controversial, and state the controversy.

But the current draft is too confusing for being endorsed by the IETF.

-- Christian Huitema

> Eliot
> ps: but I agree with your point about statistics.