Re: [Patient] Internet Draft posted as requested -

Bret Jordan <jordan.ietf@gmail.com> Fri, 15 December 2017 23:47 UTC

Return-Path: <jordan.ietf@gmail.com>
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 651091242F5; Fri, 15 Dec 2017 15:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QeV4pOWWkorg; Fri, 15 Dec 2017 15:47:23 -0800 (PST)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3141241FC; Fri, 15 Dec 2017 15:47:23 -0800 (PST)
Received: by mail-qt0-x241.google.com with SMTP id e2so14133537qti.0; Fri, 15 Dec 2017 15:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xbfYDP0azV/MzBGTFmKQxgxG2jD5+mrGuocrDPD2PUM=; b=A/9T/jtumB5RO378xiNPNoNy4WEe0OTmc2juSBTw4jrAtxt75BGnGuKDpb1OG1+KQ0 UW1hnBLcgGhkEBhzr/gh2b2whmlKWNiySnUt6WIEhzlOBHwUc7OE2EYH9Sa905erbhW5 ZC/uhMJk715rgk9ZzhKvmaYkEiXkEQt4cQc1mzMmafPJUCpodCMOxwi0wKT+dGNIi1GW zA73Doh1DPLmVpVol5/iKkgA3bUwdSB/5GiatdLS2jcaNCd9WN8BrcYfdEWQRtQ6k1gK MUS9o+2ie+0ZFeGzVRUWrPygmUBlJAcqS+v7L7IfsSHEV8nxaIxcG7Isq02X1ZaYrcmV 5g0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xbfYDP0azV/MzBGTFmKQxgxG2jD5+mrGuocrDPD2PUM=; b=c9Oh716BS721rYi8sivaJhM1IZ4+OzyfFQ9gFaWnr2GG4ya4dTmQG5jMlPuvWUcD5A eHRmukVzuBLmFge++b52tp2IXiwmvno/UzM6+/6YbhB3GOl582p4FdzwSYKTL4rtfs8t WGwBP/kihS7ursy8rLdMFGsC7y8usn+CcdT8gtvRPT4FFOa2w/qzWP7rU7HiFA9Q2Zko mSm/hVUDvDl+7I1rMoE3u9UJFwDZZGc+Un/gG7XJkUmw8IRyfQyKOUGbJnl3x3Qonp5m pDK66c/xGbZC0+sawBp9jdgc9GTOLOLoqqZWJcIYnfyHkjo64f4GS4QD2U/29spSptvm W7uQ==
X-Gm-Message-State: AKGB3mJGxdrzm1vfsee8d4s9TFzP1Z82D49AeV31WVlqfkF0F/7B4Inj CtnIodOkPrKpLURpAfdnQkPZ8+TZ3t0/nw==
X-Google-Smtp-Source: ACJfBovAdfqJNad67xGp1KI/OKcBpB/GzlyJQLdb1/fkyB/emXOa3d/Y71aW9s5w/TUZJdbokvwsiw==
X-Received: by 10.237.36.119 with SMTP id s52mr24450464qtc.199.1513381642651; Fri, 15 Dec 2017 15:47:22 -0800 (PST)
Received: from ?IPv6:2605:a601:3116:8400:5557:213a:958c:1162? ([2605:a601:3116:8400:5557:213a:958c:1162]) by smtp.gmail.com with ESMTPSA id w41sm4708320qtc.19.2017.12.15.15.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 15:47:21 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Bret Jordan <jordan.ietf@gmail.com>
In-Reply-To: <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com>
Date: Fri, 15 Dec 2017 16:47:17 -0700
Cc: "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEDDD615-D95E-4F31-AABB-6A3C33EDB2EB@gmail.com>
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> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com>
To: Brian Witten <brian_witten@symantec.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/SjPUq8M1Kw5luYxk1js1mifqv8c>
Subject: Re: [Patient] 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: Fri, 15 Dec 2017 23:47:26 -0000

Brian,

This is great.  Thanks for taking the time to spell it out a bit more.  The points you bring up are important and things we as a community need to remember.  

Bret


> On Dec 14, 2017, at 15:58, Brian Witten <brian_witten@symantec.com> wrote:
> 
> Thank you everyone for your comments!
> 
> The request in Singapore for an Internet Draft seemed focused on an ask for data, so I tried to keep the v00 focused on the data, and concise to be easily read quickly, and I thought that I might be going onto a limb beginning to present some of the logic, but it seems like many are hungry for more of the logic (or "at least some logic" as they might say) so I’ll present more of the logic.  Of course, much of the logic was presented in the near 40 slides sent earlier and roughly 5 pages of Q&A, but I agree with the merits of centralizing all of the logic in an Internet Draft, so I’ll aim to do that in the v01, and, perhaps more importantly, I also hear clearly some of the concerns on how the logic was organized (or unorganized or disorganized as some might say) in Singapore, so I’ll try to be more clearly structured both here and in more detail in the v01.  I’ll comment on the solutioning further below, but since so many seem so hungry for the logic, I’ll try present it relatively concisely here so that discussion here can best shape the v01 which will pull from the list, the slldes, and more.
>  
> The logic, in the short form of roughly five points would be:
> ** (1) ** Endpoints have vulnerabilities.  ( unfortunately lots of them.  For this part I believe there is overwhelming evidence, but please LMK if you disagree. )
> ** (2) ** These vulnerabilities are often difficult (sometimes nearly impossible) for device owners, users, etc, to mitigate “in” these endpoints. ( this is true today for countless devices, and increasingly true for increasingly closed devices, particularly in IOT and mobile. )
> ** (3) ** For that reason, those endpoint owners/users/etc often need to put some “thing” in the network to mitigate those endpoint vulnerabilities.
> ** (4) ** For that to be effective (against attacks in encrypted traffic), that “thing” needs keys to inspect the encrypted traffic.  ( This can be done any of many ways, as it’s done today. )
> ** (5) ** Where that’s done today, it can be done much more safely, therefore we should spec standards for how to do it more safely.  ( Lots of ideas have been published in research, and I include some details on that further below, but maturing the right ones and baking them into a standard is of course typically a “bigger group” effort. )
>  
> In that framework, I’d love to know which of these 5 points above (if any) are agreeable to you, and which specifically you believe are either simply dead wrong or the right-best focus of constructive discussion.  For some it seems that point (3) above is the most controversial, but others are already asking the details of (5) which is where the slides focused, but the v01 will of course cover both in depth, and, as promised, I'll give some points on (5) below.
>  
> On the solutioning, as mentioned at the side-meeting, lots of solutions have been proposed in research communities, but I believe it’s important to get aligned on the problems we’re solving as a community before picking a solution.  As mentioned at the side-meeting, solutions proposed by the research community include Stickler by Boneh & team at Stanford, plus the unfortunately named mcTLS and mbTLS efforts, and more, but I believe it’s important to get aligned on the problems we’re solving as a community before picking a solution.  Once we’re aligned on (1) through (5) above then it makes more sense to get into the specific problems with (4) which (5) tries to address, including (a) retaining end-to-end integrity, (b) giving endpoints more precise control over when, where, and how such protection is delivered from the network, in strong contrast today’s all-or-nothing just-install-a-root approach.
>  
> To address some of the other important questions and concerns raised over the past day…
>  
> Re, “does not specify a new protocol,” many of the potential/candidate protocols were mentioned at the side-meeting, in the notes of the side-meeting, in the slides presented at the side-meeting, and in the email to announce the side-meeting, but I’m happy to add them to the v01 to keep everything together in a single Internet Draft.  For context, as Stephen pointed out, his ask was not for an Internet Draft of a protocol, but for the data (and logic) of why it might help to spec a new and/or additional protocol.  Re, “It does not specify a concrete problem (use cases),” again these were mentioned at the side-meeting, in the notes of the side-meeting, in the slides presented at the side-meeting, and in the email to announce the side-meeting, but I’m happy to add them to the v01 to keep everything together in a single Internet Draft.
> 
> Re, “It does not specify any kind of architecture,” as above, covered before, but I’m happy to add it to the v01 of an Internet Draft to get everything together in a single Internet Draft.  These seem like constructive requests, even if the material was covered elsewhere already.  Thank You Again!
> 
> Similarly, if anything is missing from the notes, I’m eager to be sure this discussion fairly and deeply captures _all_ views, particularly opposing views, so where there are gaps in the 7 pages of notes we took, those gaps are absolutely not intentional.  I’m eager to see any omissions rectified, so please send any additions, corrections, etc, either to this list or to me personally.  Either way, I’m eager to be sure everyone sees all views and hears all concerns and that all of those concerns are included and/or addressed somehow in a v01.
> 
> Re, “pervasive monitoring should make way for network based monitoring,” I wasn’t trying to say that and in fact, from the slides you can clearly tell that PATIENT is aiming to more completely block pervasive monitoring.  Crypto helps block pervasive monitoring by listeners in the network.  Pervasive monitoring is also possible by hacking all the endpoints, and as presented in the side-meeting, we have ample evidence of nation-states attempting to do this.  PATIENT aims to make safer prevention of the latter approach to pervasive monitoring.
> 
> Re, “draft-mm-wg-effect-encrypt,” you’re absolutely right, and I’ll cite that work in the v01 for precisely those reasons.  In fact, my aim is to (eventually, after we get aligned on scope, etc,) design a protocol that allows network security appliances to yet more safely work hand-in-hand with pervasive encryption.  I’m not trying to push back against pervasive encryption at all.  I suspect I might have to keep repeating myself on that until people believe it?
> 
> Re, “So far, I am still not convinced that a SOCKS proxy … connected via a VPN, is not sufficient to filter out malicious data.”  I believe connecting proxies via VPN is a great way to help block malicious data.  I’m also not debating the type of proxy to be used.  As you know, and as the slides say, and as the v01 will say, I’m saying that when proxies change stuff, it would help for the endpoint to know which proxy changed what where.  Stickler helps with that.  I think it also helps for endpoints to know more about the proxy on the other side of the VPN, but I’d be happy for that to be in-scope or out-of-scope for a first WG on this. Re, “from your conversations and presentations (not from this document),” you raise a very fair point.  Although the original ask was not to put “everything” into a single Internet Draft, putting “everything” into a single Internet Draft seems like a great idea, so I’ll aim to do that with v01.
> 
> Regarding “months later,” this seems to be at least a mild exaggeration as the meeting was one month ago tomorrow.
> 
> Regarding “all in a non-verifiable manner,” I thought counting phishing websites would be easy enough for anyone who really wanted to test a hypothesis instead of standing on rhetoric.  PhishLabs seemed to manage that OK.  I haven’t counted all of the https sites in PhishTank yet, but at first glance the fraction seems substantial.  Admittedly, not all of the data is directly verifiable, nor did I ever promised that _all_ of the data would be directly verifiable, but counting phishing sites seemed easy enough.  Please LMK if I’m wrong on that point.  The other sources seem to corroborate each other.
> 
> Regarding posting to the “Threat Response Blog,” we’ll consider that, but the ask to us was to share more data here so we brought the data here as requested.
> 
> As a side comment, I’d also note the use of pejorative phrasing.  “argues for the mitm attacks on https,” … It seems that you’re calling “network based blocking of malicious webpages” an “attack” when the blocking is actually blocking the server's _attack_ against the client.  Where I choose to have a network proxy protect from evil on the net, I don’t consider that proxy to be attacking me.  I consider that proxy to be protecting me, and many organizations manage keys accordingly.  We see more and more people needing network help in protecting themselves from such attacks, as laid out in (1) through (5) above.  I look forward to your feedback there.
>  
> Thank you again -
> 
> Cheers,
> Brian
> 
> 
> From: Brian Witten
> Sent: Wednesday, December 13, 2017 3:55 PM
> To: patient@ietf.org
> Subject: Internet Draft posted as requested -
>   
> 
> Hi Everyone,
> 
> With the Wired article last week (  https://www.wired.com/story/phishing-schemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the Internet Draft ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) posted publicly for others to comment sooner rather than later.  Of course, feel free to comment here on the list  or just me comments 1:1 at bwitten@symantec.com.  Thank You Either Way!
> 
> https://media.wired.com/photos/5a25b22aa587381053b48abb/191:100/pass/PhishingHTTPs-FeatureArt.jpg 
> 
> Phishing Schemes Are Using Encrypted Sites to Seem Legit
> www.wired.com
> A green padlock might make it seem like a site is secure, but increasingly phishers are using it to lure victims into giving up sensitive info.
> 
> Looking Forward,
> Brian
>                              
> _______________________________________________
> PATIENT mailing list
> PATIENT@ietf.org
> https://www.ietf.org/mailman/listinfo/patient