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

[Paul Wouters <[e-mail]>]

On Wed, 13 Dec 2017, Brian Witten wrote:

[ Adding [e-mail] 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 ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt )

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 https://clicktime.symantec.com/ 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.

Paul