Re: [Patient] Internet Draft posted as requested -

[Brian Witten <[e-mail]>]

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: [e-mail]
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 [e-mail].  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