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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 14 December 2017 02:51 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C761B1276AF; Wed, 13 Dec 2017 18:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjVoGFWV5W_j; Wed, 13 Dec 2017 18:51:39 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A827120727; Wed, 13 Dec 2017 18:51:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 509C4BEBB; Thu, 14 Dec 2017 02:51:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmqdVG35bQFt; Thu, 14 Dec 2017 02:51:34 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B290BE55; Thu, 14 Dec 2017 02:51:34 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513219894; bh=m/l3dpiOE6f4U7vJYmz3gUac1ICtBW18W+RAI4g28Ww=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dPx3cL1SRC492JRZ+hmbghzmHK7soYvs+FIEU3Zyy7tb/M91nLf0RnXmIbws5VztB Waigi3sSqHehnoiI9/WQAsj6KHCgwTlx/ELoosnqppUzPW9Zm2h3GLInywiJ1R4xjk fWprSnSo1x71t9RLUn4MRyXF0l3LaDItnCvASirA=
To: Paul Wouters <paul@nohats.ca>, Brian Witten <brian_witten@symantec.com>
Cc: "patient@ietf.org" <patient@ietf.org>, saag@ietf.org
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <alpine.LRH.2.21.1712132056130.28112@bofh.nohats.ca>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <570c0df2-afdb-e77c-ab1d-bfaef7d14791@cs.tcd.ie>
Date: Thu, 14 Dec 2017 02:51:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1712132056130.28112@bofh.nohats.ca>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NgAvau0geWH2Ll4er4bAef09rf3wOUmPT"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/TLX0bOMp_nTKqxoLOfAZXk4VK88>
X-Mailman-Approved-At: Thu, 14 Dec 2017 09:02:39 -0800
Subject: Re: [Patient] [saag] Internet Draft posted as requested -:$
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 02:51:42 -0000

I also had a quick look at the draft.

In addition to Paul's questions, I have one more:

Where in the draft is there evidence of anything
at all that actually argues for the mitm attacks
on https that you (Brian) are espousing? There is
blatant assertion of irrelevancies, but nothing
that I saw that actually makes a logical argument
that the mitm attack you want is even useful, never
mind necessary.

Put another way... to quote the start of the
abstract: "This document describes the logic ..."
where is the description of anything at all
that could be called relevant logic? I failed to
find it, sadly.

Secondly, and keeping the criticism to the abstract
(in what is a target-rich field;-): "This report
includes data from multiple sources." is nonsense
as none of the "data" from (anonymous!) sources that
is presented (and all in a non-verifiable manner [*])
is actually relevant to the claimed thesis that mitm
attacks on https are "needed" (for any other reason
than presumably selling products and services).

Note that I do think it ought be possible to
produce evidence that these kinds of mitm attacks
are not valueless, [**] but that's not done here, and
even if it were, I doubt it'd be worthwhile as a
trade-off to choose, given the gigantic costs of
breaking security for all the rest of us who want
at least commsec that resembles something that
works in a known manner. (And who recognise that the
state of the art is not perfect.)

So this seems to me like an utterly risible failure
to make an even vestigially convincing argument for an
in-any-case losing argument.

Cheers,
S.

[*] The challenge I made (and that Brian accepted)
at ietf-100 was for the proponents of this iteration
of breaking https to produce some verifiable evidence
that such mitm attacks are at all useful, never mind
necessary. As anyone who'll read the 6 pages produced
a few months later will see, that challenge remains
to be met.

[**] It ought be easy to convincingly show that inbound
malware detection latency is lower vs. other solutions
such as endpoint mechanisms or honeypots in at least
some verifiable circumstances. (And even if so, the
costs involved aren't worth breaking things so much.)
The draft here is clearly light-years from such a
demonstration.



On 14/12/17 02:21, Paul Wouters wrote:
> On Wed, 13 Dec 2017, Brian Witten wrote:
> 
> [ Adding saag@ietf.org 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
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>