Re: [Patient] Internet Draft posted as requested -:$

Paul Wouters <> Thu, 14 December 2017 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F8221200F1; Wed, 13 Dec 2017 18:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=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 1yMecKFGujHV; Wed, 13 Dec 2017 18:21:23 -0800 (PST)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63958127517; Wed, 13 Dec 2017 18:21:23 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3yxy3h1npfzCt4; Thu, 14 Dec 2017 03:21:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1513218080; bh=gWH4ePG+U+FIuTSGgFFV+6Vo/jBrE/JZDApx7cBZFso=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WFkC248HXe8q853r7C4QdvKyBvQtsyDPSbERDwPc4UZxg3vohjvughgFR87yLTzMv XnwqrqAtfScCxIYuuMRjpq8tm3dtofXlkAkq7qJD0wYqhCk3+yFa4RNzIwiGhhOLw7 w7b9s4xeMTNNPkMIOZwnfDtPryYDHr/Bf4YObeC8=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l-2JW9aQsRVD; Thu, 14 Dec 2017 03:21:18 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 14 Dec 2017 03:21:17 +0100 (CET)
Received: by (Postfix, from userid 1000) id 161F070A3FA; Wed, 13 Dec 2017 21:21:17 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 161F070A3FA
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12AE24070CE2; Wed, 13 Dec 2017 21:21:17 -0500 (EST)
Date: Wed, 13 Dec 2017 21:21:16 -0500 (EST)
From: Paul Wouters <>
To: Brian Witten <>
cc: "" <>,
In-Reply-To: <>
Message-ID: <>
References: <>, <>, <>, <>, <>, <>, <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <>
Subject: Re: [Patient] Internet Draft posted as requested -:$
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Dec 2017 02:21:26 -0000

On Wed, 13 Dec 2017, Brian Witten wrote:

[ Adding for now, as I don't think many of the security
   people made it to the new patient list yet ]

> I wanted to get the Internet Draft ( )

This document confuses me.

- It does not specify a new protocol
- It does not specify a concrete problem (use cases)
- It does not specify any kind of architecture

The Abstract states:

    This document describes the logic for third-party and network
    security to complement strong cryptographic protocols, and presents
    data, including independently verifiable data, helping scale the
    importance of blocking attacks that might be hiding in encrypted
    network traffic.  This report includes data from multiple sources.
    Some of that data is verifiable.

What logic does it specify?

What complementing security does it specify?

The conclusion states:

    Precluding network based protection for endpoints is not consistent
    with the imperative to treat mass surveillance as an attack.  Mass
    hacking of endpoints is surveillance by another means.

Equating the number of compromised hosts with the number of visible hosts
to a pervasive monitoring agent makes no sense. But more importantly,
you state that pervasive monitoring should make way for network based
monitoring (or rather, "voluntary" host based extrusion of privacy to
(un)trusted third parties). This obvious comes with a huge problem
of designing an "opt-in" protocol that a nation state can abuse to be
"never opt-out"

As much as I don't like draft-mm-wg-effect-encrypt for fear of security
companies grasping at it for a justification of pushing back against end
to end encryption, if you read that document, it does a much better job of
neutrally informing people of the issues of deplying endpoint encryption
(which I prefer to call "pervasive privacy"). If you remove that content
from your document, nothing much is left.

I know from your presentations and conversations that you believe hosts
securly connecting to a proxy is not good enough to solve the issues you
deem exist. Your document should instead focus on that. Which current
IETF protocols are in use to achieve endhost security, why are these no
longer feasable, what changes do you need to make this work. You don't
need to present statistics about security failures.

So far, I am still not convinced that a SOCKS proxy or even a DNS proxy,
connected via a VPN, is not sufficient to filter out malicious data.

Again, from your conversations and presentations (not from this document)
I know you are looking at endnodes giving out private key material to
a trusted third party. Convince me why this is required from a protocol
point of view, not a business model point of view.

The fact that your collegue's email showed leakage of such "protection"
system by leaking links in response to
an ietf email does not help be gain confidence that I should change a
security protocol to facilitate the protocol modifications presented at
the BOF.