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 >
- [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] [EXT] Internet Draft posted as requ… Mingliang Pei
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] Internet Draft posted as requested … Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Peter Gutmann
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] Internet Draft posted as requested - Paul Wouters
- Re: [Patient] [EXT] Re: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Black, David
- Re: [Patient] [EXT] RE: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Mark Kennedy
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [saag] Internet Draft posted as req… Roland Zink
- Re: [Patient] Internet Draft posted as requested - Roland Zink
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Stephen Farrell
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Peter Gutmann
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Benjamin Kaduk
- Re: [Patient] the IETF participant choice Eggert, Lars
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Kathleen Moriarty