Subject: [Patient] Internet Draft posted as requested -

From: Brian Witten <[email-masked]>
Date: Wed, 13 Dec 2017 23:55:40 +0000

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 [email-masked].  Thank You Either Way!

Looking Forward,
Brian

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 14 Dec 2017 01:45:57 +0000

Great to see the IETF draft published, and glad to see the discussion.
Thanks, Ming

On 12/13/17, 3:55 PM, "PATIENT on behalf of Brian Witten"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Everyone,
>
>With the Wired article last week (
>https://clicktime.symantec.com/a/1/yzhHpiZ39XulP281FK1a6aOQV41o5ZgZLnE7p_q
>o-_4=?d=AY_tp4ez08U08-0M_KmYnCpXVrHgETMsN5AMYOT74GR_xPdvBh5DSu4Ht_KiK_8kME
>4TomDarcHdbpBuMLsTpJxd45CrQhWRwIpdU29IGAKuakGeUuB70m08HFjCrFRLL2SDORVioqKa
>AKKs_p-X4-KvV7kyRJgnYb37GT7GBiEFfUWuOlBxrUiqOjpSeSZPu8wekqthN60hBsla9kNvmK
>KSBQhkNYSFFqTpqzATKOgo8vFNEyfnQPl9RHM3T11n-xRxT4JHyPZRxsstcIi88i8lzpVPxI9j
>HNBzUce2yf77LsGs877LrWhoyGLaj_aqRnqivAzWCCS2m-IYUbdlU9x6PE2wRRsgIQPLXWzJO1
>C4OFme03GdYfHH64fNIglGVE1JFPKxfBESOni5mdkEm6fIt0IRWgzgojj8VTQz1t6xn7Cm4jmC
>5g%3D%3D&u=https%3A%2F%2Fwww.wired.com%2Fstory%2Fphishing-schemes-use-encr
>ypted-sites-to-seem-legit%2F ) ... I wanted to get the Internet Draft (
>https://clicktime.symantec.com/a/1/sICbe6E5A66m3RCgLuysqQiC-v4v7rIeIQM_Ux7
>rDEg=?d=AY_tp4ez08U08-0M_KmYnCpXVrHgETMsN5AMYOT74GR_xPdvBh5DSu4Ht_KiK_8kME
>4TomDarcHdbpBuMLsTpJxd45CrQhWRwIpdU29IGAKuakGeUuB70m08HFjCrFRLL2SDORVioqKa
>AKKs_p-X4-KvV7kyRJgnYb37GT7GBiEFfUWuOlBxrUiqOjpSeSZPu8wekqthN60hBsla9kNvmK
>KSBQhkNYSFFqTpqzATKOgo8vFNEyfnQPl9RHM3T11n-xRxT4JHyPZRxsstcIi88i8lzpVPxI9j
>HNBzUce2yf77LsGs877LrWhoyGLaj_aqRnqivAzWCCS2m-IYUbdlU9x6PE2wRRsgIQPLXWzJO1
>C4OFme03GdYfHH64fNIglGVE1JFPKxfBESOni5mdkEm6fIt0IRWgzgojj8VTQz1t6xn7Cm4jmC
>5g%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-witten-protectingendpoi
>nts-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 [email-masked].  Thank You Either Way!
>
>Looking Forward,
>Brian
>                  
>_______________________________________________
>PATIENT mailing list
>[email-masked]
>https://clicktime.symantec.com/a/1/5AckQpUG6V1i_-5SJXJtbU9bR_Z2liLgg_Ce9T1
>GVos=?d=AY_tp4ez08U08-0M_KmYnCpXVrHgETMsN5AMYOT74GR_xPdvBh5DSu4Ht_KiK_8kME
>4TomDarcHdbpBuMLsTpJxd45CrQhWRwIpdU29IGAKuakGeUuB70m08HFjCrFRLL2SDORVioqKa
>AKKs_p-X4-KvV7kyRJgnYb37GT7GBiEFfUWuOlBxrUiqOjpSeSZPu8wekqthN60hBsla9kNvmK
>KSBQhkNYSFFqTpqzATKOgo8vFNEyfnQPl9RHM3T11n-xRxT4JHyPZRxsstcIi88i8lzpVPxI9j
>HNBzUce2yf77LsGs877LrWhoyGLaj_aqRnqivAzWCCS2m-IYUbdlU9x6PE2wRRsgIQPLXWzJO1
>C4OFme03GdYfHH64fNIglGVE1JFPKxfBESOni5mdkEm6fIt0IRWgzgojj8VTQz1t6xn7Cm4jmC
>5g%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient

---

From: Bret Jordan <[email-masked]>
Date: Wed, 13 Dec 2017 19:10:38 -0700

Thanks for sharing Brian.  This is good stuff, glad to see this moving forward.

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Dec 13, 2017, at 4:55 PM, Brian Witten <[email-masked]> wrote:
> 
> Hi Everyone,
> 
> https://www.ietf.org/mailman/listinfo/patient

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Dec 2017 21:21:16 -0500 (EST)

On Wed, 13 Dec 2017, Brian Witten wrote:

[ Adding [email-masked] 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

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Dec 2017 02:30:45 +0000

>- It does not specify any kind of architecture

It reads like a blog post.

In fact, why not post it to the Symantec Security Response blog?

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Dec 2017 02:51:32 +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:
>> I wanted to get the Internet Draft (
>> https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt )
> 
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Brian Witten <[email-masked]>
Date: Thu, 14 Dec 2017 22:58:41 +0000

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: [email-masked]
Subject: Internet Draft posted as requested -

Hi Everyone,

 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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Dec 2017 18:10:53 -0500 (EST)

> 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” w…

Some call it that because you are actively trying to circumvent protection
that https offers.

If you let the client decrypt the data and then sent that data (encrypted)
to the network agent, no one would call it mitm attack.

But your proposal is to give private (session) keys from endpoint to
the network agent, basically giving it the full power to impersonate
the endpoint. That is a dangerous and needlessly insecure compromise.

Similarly, an email message can be received over TLS, and then forwarded
to the network agent for scanning without giving the network agent the
key material to sit in between network agent and remote mail server.

Paul

---

From: Brian Witten <[email-masked]>
Date: Thu, 14 Dec 2017 23:16:29 +0000

Hi Paul,

Thanks!  I'm not against true end2end client-auth.  That would help the server know for sure to whom they are talking, including both an endpoint that couldn't be impersonated, and the middlebox which the client wants helping with security.  Sending data "back" into the network just often has a too-ugly bandwidth cost.  Doing things in-flow is far better from a bandwidth perspective, and I'm happy to make these middleboxes (currently impersonating) more explicitly accountable for their presence in the communications...

I hope that helps!  Thanks Again!!

Brian

________________________________
From: Paul Wouters <[email-masked]>
Sent: Thursday, December 14, 2017 3:10:53 PM
To: Brian Witten
Cc: [email-masked]; [email-masked]
Subject: [EXT] Re: [Patient] Internet Draft posted as requested -

Paul

---

From: "Black, David" <[email-masked]>
Date: Fri, 15 Dec 2017 17:07:31 +0000

> ** (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,

Particularly when the "thing" is inserted without any form of knowledge or authorization by the endpoint.

The discussion should be qualitatively different when the endpoint owner/user/etc. is required to do something in order to authorize the "thing" to access the endpoint's encrypted traffic.  A deployed example that may help in thinking about this is insertion of firewall decryption root certs into a browser's trust store to enable a firewall to inspect all encrypted web traffic that enters or exits a corporate network.  This is only an example - these three sentences are *NOT* a proposal to standardize anything ... but they are a report on current "running code" ...

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]
----------------------------------------------------------------

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Brian Witten
> Sent: Thursday, December 14, 2017 5:59 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [saag] Internet Draft posted as requested -
> 
> 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.
> 
> ** (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
> 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
> [email-masked].  Thank You Either Way!
> 
> 
> 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
>

---

From: Brian Witten <[email-masked]>
Date: Fri, 15 Dec 2017 17:31:24 +0000

Many Thanks!

Re, "inserted without any form of knowledge or authorization by the endpoint," in fact, PATIENT aims to establish a protocol whereby end-users get visibility into ALL of the "things" (middleboxes) monitoring the communications.

Re "root certs into a browser's trust store," you're absolutely right that this is common practice today.  This practice (without any additional protocols such as what PATIENT could enable) breaks end2end Integrity protection.

As a community, we can do much better.  We can make this much safer, both on end2end cryptographic integrity protection a la Stickler, and giving endpoints/users more visibility into the number of MB's monitoring their communications!

Thank You Again!!

________________________________
From: Black, David <[email-masked]>
Sent: Friday, December 15, 2017 9:07 AM
To: Brian Witten; [email-masked]; [email-masked]
Subject: [EXT] RE: Internet Draft posted as requested -

Thanks, --David

> With the Wired article last week (  https://clicktime.symantec.com/a/1/rIiJXLn_RcL6DO1kshrfRFngO-jzXx2qnw5My1Gmx-4=?d=acDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=https%3A%2F%2Fwww.wired.com%2Fstory%2Fphishing-
> Internet Draft ( https://clicktime.symantec.com/a/1/1E0rtJCkJI3RRVQJh91qEecCADHsunsL3_elUVceQ0k=?d=acDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-witten-protectingendpoints-
> https://clicktime.symantec.com/a/1/EZreXTnVcH4VO_SfwFt5e40fv5Kya02XGSioz4HgSnQ=?d=acDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=https%3A%2F%2Fmedia.wired.com%2Fphotos%2F5a25b22aa587381053b48abb%2F191%3A100%2Fpass
> /PhishingHTTPs-FeatureArt.jpg
>
> www.wired.com<http://www.wired.com>
> https://clicktime.symantec.com/a/1/8r1dfpQVPaT0ym4x10d1AoBGkiwLzbkySDbKaq-1M2Q=?d=acDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsaag

---

From: Bret Jordan <[email-masked]>
Date: Fri, 15 Dec 2017 16:47:17 -0700

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 <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Dec 2017 15:27:31 +0000

> The logic, in the short form of roughly five points would be:

Let's see if there is or is not logic to be found...

> ** (1)
> ** Endpoints have vulnerabilities.  ( unfortunately lots of them.
> For this part I believe there is overwhelming evidence, but please
> LMK if you disagree. ) 

That's incomplete to the point of being misleading. Middleboxes
are as likely to have bugs. And if those are mitm'ing many https
connections the impact of a problem is higher than for the client
side. Probably also higher impact for most instances of servers
too. And the mitms are certainly in a position to mitm connections
to high-value servers (if they can do one they can do all) so all
mitm code bugs could argued to be worse than endpoint bugs.

> ** (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. ) 

Where's the evidence for that? What percentage is "often"?
(Speaking about "countless" devices, is pure rhetorical
noise and not useful if you are honestly trying to provide
verifiable evidence.)

Why would middleboxes be easier to patch? It seems from many
anecdotes (I'd love to see real numbers), that at least browsers
and web servers these days are managed much better in terms of
updates.

> ** (3) ** For that reason,
> those endpoint owners/users/etc often need to put some “thing” in the
> network to mitigate those endpoint vulnerabilities. ** 

That's simply false. Even if I accepted your stated and flawed
premises, the above still doesn't follow at all. Just to call
out your flawed logic in one way: buggy difficult to fix clients
*could* be fixed or replaced over time, so your claim that
a mitm middlebox is *needed* is obviously false.

> (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. ) 

Also clearly incorrect. See [1] (recently quoted by Martin T on some
other list) for a proof that your claim that this is *needed* is also
just false.

[1] https://arxiv.org/abs/1607.01639

> ** (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. )

Afaics all of those approaches are inherently flawed and consider
it someone reasonable that a human can decide when to trust a
random name/address that claims to be "good." None (i.e. zero) of
the approaches proposed would improve the overall environment and
therefore none (i.e. zero) of those ought be standardised.

So overall it seems flawed premises, incorrect logic, and your
-00's lack of relevant data leave us right back where we started
having to deal with risible claims such as this:

> Re, "inserted without any form of knowledge or authorization by
> the endpoint," in fact, PATIENT aims to establish a protocol whereby
> end-users get visibility into ALL of the "things" (middleboxes)
> monitoring the communications.

Just for a laugh, I loaded [2] in a default setup browser (chromium).
Among the 269 http requests that caused was [3]. Are you (Brian)
seriously trying to claim that you actually believe that a random
person can sensibly decide 269 times if 2001:db8::bad:1dea ought
be allowed to mitm that connection?

That is not something I find a credible assertion, so I'm left with
the belief that the quoted text above aims to be a snow-job of some
kind. And while a snow-job may be seasonal for the next few weeks, it
is not a basis on which the IETF ought do anything except brush the
snow-job aside.

S

[2] https://www.symantec.com/
[3]
https://fei.pro-market.net/engine?du=24;csync=8A149905A638355A509A770D02460917;mimetype=img;sr

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 17 Dec 2017 23:19:12 +0000

Hi,

First of all, let me say I am glad to see this discussion reopened, and glad to see as well some proposals that sound more constructive than the usual religious entrenchments that are so common in this front, especially when I see certain acknowledgement we are not necessarily talking of mitm-ing, and we are not only talking about HTTPS and/or web access. It is about exploring the solution space for network-hosted device protection in a network with widespread (OK, let's not use "pervasive") use of end-to-end encryption.

This said, there a few points I'd like to make in response to Stephen's comments...

On 16/12/2017, 16:27, "PATIENT on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

Is not here a flaw in your logic? Nobody has mentioned middleboxes (or “things”, as they have called below) yet…

    verifiable evidence.)

The most recent I have found is here: https://danluu.com/android-updates/ . It only refers to Android devices, though it mentions other systems as Windows XP. And it does not take into account IoT devices, to name another category. May be all of those are not “countless”, but it makes the use of the word a reasonably accurate figure of speech anyway.

    updates.

I cannot speak for other people supporting this, but we have not in mind only web browsers or web access use cases. I remember constrained devices were mentioned a couple of times in Singapore.

OK. May be “need” is a too strong word here, at least in the general case (not sure about some kinds of devices…). But my own experience as user is that “can require” is, again, reasonably accurate

    just false.

This is an interesting reference. Thanks for sending it. I guess this kind of solutions is in the minds of many, and recommendations on them (including a sound base of datasets for training and validation, as I have mentioned elsewhere) could be an interesting result of an effort like PATIENT. But the paper acknowledges limitations and ways for further improvement, and it has been applied to a particular case: distinguishing legitimate from malware-originated encrypted traffic. Nothing is said about malware payload detection to prevent infection, as an example of a key feature.

I am afraid I don’t follow you here… What do you mean by “random name/address that claims to be “good””? Given there are appropriate roots of trust, how is this “random” trust different from the certificate verification process in TLS?

Be goode,

--

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Telefonica I+D

https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]

Tel:         +34 913 129 041

Mobile:  +34 682 051 091

----------------------------------

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Dec 2017 00:23:52 +0000

Diego,

I generally disagree with some of your earlier points where
you disagree with me:-) I do agree that there are hard
problems with updates and bugs in general for endpoints and
devices in the middle. I don't agree that breaking TLS or
HTTPs is a viable way to improve that, It'd make it worse.
But rather than repeat things I've said to you in person
before, for this threat, maybe it is work saying that the
proponent here claimed to be interested in a new multiparty
security protocol (in the mailing list description) which
could have been a worthy, if unlikely to succeed endeavour.
In Singapore, I concluded that they are primarily or maybe
only interested in the web as used by people and in mitm'ing
that. So personally I think the separate mailing list would
be better closed down as it seems to have been started on
the basis of some confusion wrt folks' goals.

On 17/12/17 23:19, Diego R. Lopez wrote:
> 
> I am afraid I don’t follow you here… What do you mean by “random
> name/address that claims to be “good””? Given there are appropriate
> roots of trust, how is this “random” trust different from the
> certificate verification process in TLS?
The difference in the above context is the the proponents
here want TTPs that tell lies all the time, and that are
so wide-spread and not well-known that they appear to the
endpoints indistinguishable from a random router. The public
Web PKI TTPs we have are far from perfect but at least they
don't do that so far.

There also appears to be some magical thinking that allows
some proponents to say that they think these new lies can
benefit the user and give the user more control. I have no
clue how that can reflect a genuine technical opinion.

S.

---

From: "Black, David" <[email-masked]>
Date: Mon, 18 Dec 2017 16:18:47 +0000

> HTTPs is a viable way to improve that, It'd make it worse.

If "breaking" is defined as "MITM-ing connections without any form of knowledge or authorization by the endpoint," then I would agree that "breaking TLS or HTTPS" is a bad idea.

> could have been a worthy, if unlikely to succeed endeavour.

+1 on worthy, no comment on likelihood of success.

> the basis of some confusion wrt folks' goals.

Also, no comment on people's intents, but I do want to respond to one of Stephen's earlier remarks ...

> be allowed to mitm that connection?

A person (random or otherwise) - of course not ... however ... a community or otherwise maintained blacklist or whitelist is plausible, although that does require both that the involved middleboxes to have stable visible identities, and that there be a viable community or other maintenance organization for the list or lists.

A blacklist approach seems reasonably effective in other domains - for examples, try these links:
	https://adblockplus.org/subscriptions
	https://filterlists.com/

Thanks, --David

> From: saag [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Sunday, December 17, 2017 7:24 PM
> To: Diego R. Lopez <[email-masked]>; Brian Witten
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [saag] [Patient] Internet Draft posted as requested -
> 
> 
> Diego,
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Dec 2017 17:08:03 +0000

Hi David,

On 18/12/17 16:18, Black, David wrote:
>> I generally disagree with some of your earlier points where you
>> disagree with me:-) I do agree that there are hard problems with
>> updates and bugs in general for endpoints and devices in the
>> middle. I don't agree that breaking TLS or HTTPs is a viable way to
>> improve that, It'd make it worse.
> 
> If "breaking" is defined as "MITM-ing connections without any form of
> knowledge or authorization by the endpoint," then I would agree that
> "breaking TLS or HTTPS" is a bad idea.

Even with supposed "knowledge" (see the number 269 below),
cookies and other bearer tokens mean that so-called visibility
is the same as allowing impersonation unless one doesn't
actually ever apply the mitm technology to the web. The chances
of that seem to be zero to me.

And of course, many of the so-called "visibility" schemes,
immediately do allow for endpoint impersonation for everything
and not just bearer-token situations, whenever the middlebox
so chooses, regardless of the language used to describe those
schemes. Which brings us back to them being no better than the
current ickky corporate mitm root-ca stuff.

> 
>> But rather than repeat things I've said to you in person before,
>> for this threat, maybe it is work saying that the proponent here
>> claimed to be interested in a new multiparty security protocol (in
>> the mailing list description) which could have been a worthy, if
>> unlikely to succeed endeavour.
> 

My guess is that success would require there being some application
that wanted to use the putative multiparty protocol. I'm sure there
might be some such application but I've no idea if there's one that
would justify the effort.

And of course, it'd be a first-order requirement that that putative
new protocol not be confusable with https or tls, or else it'd
inherit all the downsides and reasons to not use that protocol for
any application that can use https or tls, and that ever needs to
be secure against mitm attack. (Which is why I think success there
isn't really likely.)

> 
>> In Singapore, I concluded that they are primarily or maybe only
>> interested in the web as used by people and in mitm'ing that. So
>> personally I think the separate mailing list would be better closed
>> down as it seems to have been started on the basis of some
>> confusion wrt folks' goals.
> 
> Also, no comment on people's intents, 

My comment was about my own conclusion.

> but I do want to respond to one
> of Stephen's earlier remarks ..>
>> Just for a laugh, I loaded [2] in a default setup browser
>> (chromium). Among the 269 http requests that caused was [3]. Are
>> you (Brian) seriously trying to claim that you actually believe
>> that a random person can sensibly decide 269 times if
>> 2001:db8::bad:1dea ought be allowed to mitm that connection?
> 
> A person (random or otherwise) - of course not 

That is the exact claim to which I was responding and is,
as you note, nonsense. None of this mitm stuff is really
about giving users control of anything.

> ... however ... a
> community or otherwise maintained blacklist or whitelist is
> plausible, although that does require both that the involved
> middleboxes to have stable visible identities, and that there be a
> viable community or other maintenance organization for the list or
> lists.
> 
> A blacklist approach seems reasonably effective in other domains -
> for examples, try these links: https://adblockplus.org/subscriptions 
> https://filterlists.com/

IIUC, those kinds of service are aimed at allowing endpoints
to decide to just not send http requests. I don't see that they
are particularly relevant to this discussion, but I don't know
details of any middlebox-oriented services like that. (That's
one reason I asked for evidence of efficacy.)

It's also worth noting that for mail, where MTAs are a good
example of known and fairly well-identified servers, we have
decades of history of MTA inspection of cleartext missing
lots of "bad" content, and of variously good and less good
blocklists.

If the proponents of these mitm schemes honestly and openly
faced up to such issues and argued for another decades-long
arms-race and acknowledged the downsides (e.g. assisting
censorship, breaking all sorts of application assumptions,
and enabling pervasive monitoring) of mitm'ing https and/or
tls then that at least would be credible. It'd still be a bad
plan, but at least one for which we could discuss the technical
(de)merits and not have to deal with the nonsense claims such
at the one we both noted above.

Cheers,
S.

> 
> Thanks, --David
> 
>> -----Original Message----- From: saag
>> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
>> Sunday, December 17, 2017 7:24 PM To: Diego R. Lopez
>> <[email-masked]>; Brian Witten 
>> I generally disagree with some of your earlier points where you
>> disagree with me:-) I do agree that there are hard problems with
>> updates and bugs in general for endpoints and devices in the
>> middle. I don't agree that breaking TLS or HTTPs is a viable way to
>> improve that, It'd make it worse. But rather than repeat things
>> I've said to you in person before, for this threat, maybe it is
>> work saying that the proponent here claimed to be interested in a
>> new multiparty security protocol (in the mailing list description)
>> which could have been a worthy, if unlikely to succeed endeavour. 
>> In Singapore, I concluded that they are primarily or maybe only
>> interested in the web as used by people and in mitm'ing that. So
>> personally I think the separate mailing list would be better closed
>> down as it seems to have been started on the basis of some
>> confusion wrt folks' goals.
>> 
>>> name/address that claims to be “good””? Given there are
>>> appropriate roots of trust, how is this “random” trust different
>>> from the certificate verification process in TLS?
>> The difference in the above context is the the proponents here want
>> TTPs that tell lies all the time, and that are so wide-spread and
>> not well-known that they appear to the endpoints indistinguishable
>> from a random router. The public Web PKI TTPs we have are far from
>> perfect but at least they don't do that so far.
>> 
>> There also appears to be some magical thinking that allows some
>> proponents to say that they think these new lies can benefit the
>> user and give the user more control. I have no clue how that can
>> reflect a genuine technical opinion.
>> 
>> S.
>> 
>

---

From: Brian Witten <[email-masked]>
Date: Mon, 18 Dec 2017 17:39:45 +0000

Hi Stephen,
 
Thank you for taking time to reply over a weekend.  The extra effort is appreciated.
 
Where you say, “Middleboxes are as likely to have bugs,” this is of course completely consistent with my emphasis in Singapore that “all software has bugs & vulnerabilities,” including both endpoints and network appliances, virtual and physical.  One of my points that you might’ve missed in Singapore was that “when something goes wrong,” such as a vulnerability being exploited, I’d much rather have that "blow up" in some remote (and easily reset) network thing (virtual appliance, container, or lambda) rather than in the endpoint.  Why?  Network “things” can be dedicated to flows that are specific to a remote endpoint, like a client running a set of proxies in a cloud based infrastructure that they and millions of others trust, with each software instance of the proxy dedicated to mediating communication with a different server.  In this context, if the server hacks the middlebox, it only hears it’s own conversation with the client.  In contrast, if the server manages to hack a client, it can hear all that client is doing, including today lots of location based information, as well as seeing state accumulated from past conversations with other servers.  So, I’ll stand by my two assertions: “All software has vulnerabilities,” and “When things go wrong, I’d rather have them go wrong in an easily reset network thing, much rather than having things go wrong in the endpoint.”
 
Back to the thought that “all software has vulnerabilities,” taking the discussion further, in fact, just as some endpoints have more vulnerabilities than others, some network appliances have more vulnerabilities than others. That’s of course among the reasons I believe it’s good for endpoints to know as much as possible about the network appliances which they are considering trusting with cleartext.  Some people in this discussion have proposed narrowing the scope so that endpoints only trust a set of well-known, manually pre-configured set of such appliances, but still tackle challenges like end2end integrity.  Others see value in tackling the more flexible, more SDN/NFV like aspects.  I’d be happy with either scope. Either scope would be better than trying to pretend that network appliances aren’t needed for security, or trying to pretend that network appliances never need to see cleartext to be effective.

Re, “That's incomplete to the point of being misleading,” it would have been incomplete if I hadn’t already said much of what I’d said above, but I’m happy to repeat myself here to be sure all is captured electronically for everyone, and, as promised, I’ll try to similarly consolidate all of these points into the v01 of the Internet Draft.
 
On your reference to analysis of encrypted traffic without decryption, that can be great for detecting “command and control” communications after an infection, and maybe sometimes even for blocking later stages of a multi-stage attack, but of course it’s not always very effective against blocking initial infection.
 
Re Diego’s points I agree with him completely on all the points he mentioned yesterday, including changing the phrasing of point (3) to “may require.”  Some endpoints are easily updated, others are not.  Even for “easily updated” endpoints, people operating many endpoints often find that network protection is an efficient way to quickly protect many, many devices, all at once, while endpoints individually update their protection.
 
Re “random person can sensibly decide 269 times,” um, no.  I’ve repeated myself here on this a few times, but I’m happy to do it at least one more time.  Power users might choose to run their own protection in their own cloud based infrastructure, but that’s not a random person.  Many people choose to have someone or something help protect them.  Many employees choose to let their employer help protect them.  Many people often choose to have security companies help protect them.  Some people choose to have network providers help protect them.  I believe people have a right to choose who protects from them from potentially malicious servers.  I believe people have a right to choose protection from someone other than the endpoint maker and someone other than the remote server.  Maybe we differ on this.
 
Re shutting down the dedicated list for this discussion, we all recognize that has been your desire from the start.  In contrast, some of us see value in the discussion.  Where you concluded PATIENT was started for only watching what people do on the web, and not helping protect IOT “things,” that view is of course surprising to me as one of my earlier notes highlighted “particulary for … IOT devices,” and I continue emphasizing “increasingly closed” endpoints including both mobile & IOT.  Of course, like TLS, PATIENT would be most valuable well-covering a broad range of settings, including Web, Mobile Apps, and IOT.
 
Re, “no clue how that can reflect a genuine technical opinion,” I’m happy to talk by phone if that’s more convenient for you.  I’m hoping that you are willing to grow past your (actually quite famous) a priori biases on this topic.  Re, “magical thinking … new lies … and …snow job,” I find your choice of such words simply insulting and not constructive, but I’m willing to look past that here.  It’s an important discussion, and I have a thick skin.  I’m sure there’s a joke somewhere near that re thick headed.  More importantly though, as I was saying, “how we (as a community) protect increasingly closed endpoints, at scale, now that we are beginning to enjoy the fruits of pervasive encryption,” is an important topic.  I’m obviously eager to continue the discussion.  Thank You Again.

Brian

From: Stephen Farrell <[email-masked]>
Sent: Sunday, December 17, 2017 4:23 PM
To: Diego R. Lopez; Brian Witten; [email-masked]; [email-masked]
Subject: [EXT] Re: [Patient] [saag] Internet Draft posted as requested -

Diego,

S.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Dec 2017 14:15:07 -0500 (EST)

> at the one we both noted above.

If we did an use-cases document for this, to seperate the technical
aspects from the business aspects, the first item I would insist on
would be:

- Protection service MUST NOT be in the possession of any private
   key material that will allow it to impersonate the client identity
   to a remove server. If a client wants to delegate this responsibility,
   it MUST be able to communicate this to the server and the server MUST
   be able to deny such a request (upon which the client may decide to
   close the connection)

The problem here is that providers of these services don't want to double
the traffic load where the client decrypts then forwards for blessing.
But simply insisting that decryption has to move to the network service
isn't going to work.

Another way to accomplish this would be to have signed web pages,
so clients could send hashes for verification. But in today's dynamic
web that is also pretty problematic and would require major changes.
Of course it has the benefit of the provider not even being able to
read the users content.

The IETF discussion should not center around the business model, but
should center around designing (or not) a useful new protocol or
existing protocol modification that addresses a well defined issue.
Instead, I hear about desires and potential business models and how
some of our new technology has affected existing business models.

I also detect a culture clash where I see a lot of praise to proponents
and opponents without technical backing. At the IETF, we try to
reach consensus based on technical merit, for example by stating you
agree or disagree with certain items and why, and don't do "me too"
messages to get a count.

Paul

---

From: Melinda Shore <[email-masked]>
Date: Mon, 18 Dec 2017 10:32:43 -0900

> agree or disagree with certain items and why, and don't do "me too"

Right, this is not how we do consensus.  Consensus is not voting
without formal votes.

At any rate I'm not sure that business models and technical decisions
are that cleanly separable.  We've decided, for example, that the
IETF is not going to develop "walled garden" technologies, and so
on.

This particular discussion is one we've been having for several
decades.  When the problem of getting encrypted session signaling
(i.e. VoIP) protocols through firewalls and NATs came up there
was a similar tension between what people concerned about application
security wanted and what middlebox vendors wanted, since middlebox
vendors had established a lot of value in their products and
were concerned that moving application logic outside of the
middlebox (through a middlebox signaling protocol) would undermine
that value.  There were proposals for session key sharing at that
time but the IETF made the decision that this was terrible security
practice and instead took an approach that ultimately didn't get
any traction because middlebox vendors wouldn't implement it.

So, we've been here before.  That said, I think the decision not
to share session keys was a sound one at that time and remains
a sound one today.  We can't avoid having business model impacts,
and the work being brought to the IETF typically reflects someone's
business needs, but I do think we can continue to draw firm lines
around clearly unsound security practices.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
                 AB36 FE18 57E9 6B9D A293

---

From: Brian Witten <[email-masked]>
Date: Mon, 18 Dec 2017 23:01:17 +0000

Hi Paul,

Thanks Again.

Re, "...NOT be in the possession of any private key material that will allow it to impersonate the client identity to a remove (sic, remote) server," I believe this could be achieved through "mutual authentication leveraging client-side certs," where the client-side certs are provisioned either through in-factory credential-provisioning, which is quite common in IOT today, or through some other provisioning mechanism, such as Enterprise PKI or how some banks do "out-of-band" (OOB) credential provisioning to client devices.  Of course, the keys & roots need to be set up properly so that the server can verify the client-side credentials and the Protection Service can't forge such credentials, but that's straight forward.  That would seem to prevent impersonation.  Also, the client could then also it use it's Private Key to sign anything it sends back to the server, "akin to Stickler, but providing end2end integrity protection from the client back to the server."  Please LMK if you disagree?

Either Way, Thank You Again!

Brian

From: saag <[email-masked]> on behalf of Paul Wouters <[email-masked]>
Sent: Monday, December 18, 2017 11:15 AM
To: Stephen Farrell
Cc: [email-masked]; [email-masked]
Subject: [EXT] Re: [saag] [Patient] Internet Draft posted as requested -

Paul

_______________________________________________
saag mailing list
[email-masked]
https://clicktime.symantec.com/a/1/fiazdLFK3QUq7FT-i8r9StLrGbk9GfOa_1goF9ohiHM=?d=pDpEfizpaOoyRJu2SzY3dci6RLYb38UoHcO56rWd_Waa-XH4XaU_PbZEq2F_Ots1eFq9hFcrLyPIEy48XVNkNuVNaOs-hoRY9sYCvwwTKpc4f-YKEqzZth1bnGLIzloRCg-0QnQdNv56mIQtGktlHz8TajPdmMikqWjbs6jf4VPYjcczDAj9jNyaxcx2IKQYHLloy8tT3EpQiziv7EBh2XdL0QhQnkkhSzCFPg_DkAVAp0nHRv2IKkK8evQNjlGIG5n4l5H7ZK-c5O7bxd8T5NvfXPwX_fA1aXxbKcyxcBBCAsuxquW-NErNyP3CsvoqB9y33t-tWDXxs9RHYaIEEdCZpVKVj6nws46A-ieYJWuMViPN3fvhBKGW1VS3xyIUDcLeTBbhiy_-WdDGzGvoxW-BueESNFM%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsaag

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 19 Dec 2017 00:18:51 +0000

Hi Stephen,

I agree we should not bore the list (and ourselves) repeating the disagreements we have. Those are the kind of discussions for the third or fourth beers...

Just let me remark a couple of things I have seen when reviewing today's messages that I think are worth noting:

1) You do not need to break TLS or HTTPS, as there are potential alternatives that could be applicable, depending on the case. For IoT environments I foresee multiparty security could be a reasonable choice. For personal environments, I think Paul's idea of decrypt-and-bless could be something interesting to explore. And replying to Melinda, those proposals do not imply sharing session keys (though there is a draft on enterprise datacenters arguing for a related approach that I think has a solid case behind...) In summary: there are options on the table that deserve some attention, and do not imply breaking TLS

2) What I had in mind when replying to you was not arbitrary routers, or WiFi Aps, or any other network box being authorized to inspect encrypted traffic. I foresee a single (or very few) edge devices that are properly authenticated, authorized (in a PoC we have we even attest their software...) using the same kind of TTPs you mention.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------
On 18/12/2017, 01:23, "Stephen Farrell" <[email-masked]> wrote:

    Diego,

    S.

---

From: Bret Jordan <[email-masked]>
Date: Mon, 18 Dec 2017 22:41:55 -0700

Diego, I agree with you and your points are valid.

I think there is a fundamental element that many are overlooking...  Whether you like network based protections or not, they are not going away.  TLS 1.3 does not prevent or restrict network based security solutions at all. In fact, many large organizations are rolling out new ways of using network based protections to protect their clients and data, just look at Google's BeyondCorp for an example of a new and innovative solution.

Given that network based protections are going to exist, and some percentage of the population will elect to use them. It would be nice if there was a better way for clients to:
1) know more about what was being done to their session
2) know if there are additional upstream solutions that they can not see
3) know for sure what was changed or defanged to protect them

We as a community need to try and find ways to enable the network and clients to be more robust and more secure. Simply thinking that if the session is encrypted, then it is secure, is lacking. Threat actor groups and intrusion sets make good use of encrypted sessions, and if history is a guide, we can bet that all malware sites, phishing sites, droppers sites, and CnC sites will be fully encrypted with valid certs at some point in the near future. 

While some members of this community may philosophically not like network based protections or want all of the protections to reside on the client, it is not theirs to decide. Users, clients, organizations, businesses, grandmas, cats, and dogs should all have a choice of how they want to be protected. Further, the market should ultimately decide what solution or set of solutions is the best way to protect users, we just need to make sure the protocols works and are solid. 

I would ask that we focus on figuring out how we can make things better for everyone. Just like we do not get to say in the HTTP WG that everyone should use HTTP and no other protocol should be worked on by the IETF, we can not say that everyone should secure their networks the way I, you, or someone else secures their network.  We design protocols not policy or business plans.  

Bret

---

From: Mark Kennedy <[email-masked]>
Date: Tue, 19 Dec 2017 06:30:11 +0000

This might be a good place to inject the work from ICSG's Encrypted Traffic Inspection group.  Give this a read as a starting point for some very broad requirements.

Requirements
Definitions: 

An ETI middlebox is any device (physical or virtual) that is designed and deployed to inspect/modify encrypted traffic, including the encrypted payload. These devices include but are not limited to security devices, performance enhancing devices (caching), traffic shaping devices.

A participant is an endpoint (terminator of the encrypted connection) or an ETI middlebox.

Requirements

1.	All ETI middleboxes must be visible to everyone in the communication.
2.	Participants must be able to set policies on which ETI middleboxes can decrypt which parts of their traffic. 
3.	Participants must be able to set policies on which ETI middleboxes can modify which parts of their traffic. 
4.	The protocol must produce a cryptographically strong audit trail of who changed, or inspected, what, when, where, and why whenever an ETI middlebox changes/inspects content.
5.	ETI middleboxes must provide an attestation of the degree to which they conform to the standard.
6.	ETI middleboxes must not negatively impact the strength of the encryption.

We feel these are minimal requirements to ensure that nothing is hidden, everyone knows who the players are and by what rules they are playing.  All the participants can then decide if they are satisfied with the landscape and whether or not to allow the conversation.

Mark 

Mark Kennedy
Distinguished Engineer
Security Technology And Response
Symantec Corporation
www.symantec.com
-----------------------------------------------------
Office: 424-750-7661
Interoffice: 6 [424] 7661
Mobile: 310-722-1934
Fax: 424-750-7001
Email: [email-masked]
-----------------------------------------------------

-----Original Message-----
From: PATIENT [mailto:[email-masked]] On Behalf Of Bret Jordan
Sent: Monday, December 18, 2017 9:42 PM
To: [email-masked]
Subject: [EXT] Re: [Patient] [saag] Internet Draft posted as requested -

Bret
_______________________________________________
PATIENT mailing list
[email-masked]
https://clicktime.symantec.com/a/1/cDSVRFwNPy0Yz41-lsHsP0BgkS7znx9HGbYfCtQkgCg=?d=R72HnQP6upzIjCWnwQhbW-p60Le7-AcIkbdbnoh2s_f8Syjzm4rJmGZXLgJZjVMCW1gf-n2tpBkb6gaIn9xEi934vDdmK0vMt5JP4Vp1xlAr7QY6u6293eyVI0frq74G39zOx7VmBaFWCGUFpzlLNrt1gyqoLDeoSDytkHc2aAQ8MFzpcibtup1Ca29rv1Lw7_a25WVtZp9nU_J9eHuiMSZ82KGCA9VJjAbvGrDRfOAK8vtWNc6152nIKlRP80Xu68R9xZT9KIKCl3p3Oeoujmvj2rZRZKwW7aF2KzzoKexz43gzA6PyxxsDAcqb3ubyYZqgUFoo2XUyyetMjoaDRXvFbDJ2W7WRHIkui1svcU6wnaOL-Owt2dOfTDylvz6ISBPi7WODX4ZVYLUhrNAnOA8feJk%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpatient

---

From: Melinda Shore <[email-masked]>
Date: Mon, 18 Dec 2017 21:49:37 -0900

On 12/18/17 8:41 PM, Bret Jordan wrote:
> While some members of this community may philosophically not like
> network based protections or want all of the protections to reside on
> the client,  [ ... ]

I think it is fair to say that this is a mischaracterization of
the argument.  The issue here is with weakening application or
transport security in order to allow middleboxes to work their
magic.  That is to say, that's the tradeoff that's under discussion.

Melinda

---

From: Roland Zink <[email-masked]>
Date: Tue, 19 Dec 2017 12:30:41 +0100

Hi Stephen,

> of that seem to be zero to me.
Impersonation is what is done on the server side for example in CDNs. 
Your data may end in a different country than you think. Do you propose 
to stop such things only on the client side?

> current ickky corporate mitm root-ca stuff.
And the server is even allowed to instruct my browser to tell 3rd 
parties what I'm doing. The referer header is used for pervasive 
monitoring. There is not only a end-to-end connection instead there 
could be many. The end user should have control over them but is not 
even notified.

Regards,
Roland

---

From: Roland Zink <[email-masked]>
Date: Tue, 19 Dec 2017 12:30:44 +0100

Hi Brian,

My two cents to this. When you are a endpoint you shouldn't trust the 
other endpoint or the network. When you are part of the network you 
shouldn't trust endpoints and probably other parts of the network. 
Especially TLS/HTTPS doesn't protect endpoints from malicous servers.

I even want to extend this from a end users point of view. In todays 
world the end user often can't control what the endpoint is doing. So 
instead of only protecting endpoints from incoming messages also the 
outgoing messages should be looked at if they break for example the 
users privacy. This can be something like removing the referer header or 
dropping audio recordings taken unnoticed by some phone, tv, tablet, 
laptop, digital assistant or whatever.

That said I'm not sure if a network element decrypting the transport 
encryption can really protect assuming that parties which want to talk 
secretely will use an additional level of encryption to prevent the 
decryption.

Regards,

Roland

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Dec 2017 12:42:51 +0200

I have not followed this discussion in Singapore or in the patient
list, so my knowledge about this is what has been sent to here to the
saag list, so I am sorry if I misunderstood something.

Brian Witten writes:
> Where you say, “Middleboxes are as likely to have bugs,” this is of
> course completely consistent with my emphasis in Singapore that “all
> software has bugs & vulnerabilities,” including both endpoints and
> network appliances, virtual and physical.
>
> One of my points that you might’ve missed in Singapore was that
> “when something goes wrong,” such as a vulnerability being
> exploited, I’d much rather have that "blow up" in some remote (and
> easily reset) network thing (virtual appliance, container, or
> lambda) rather than in the endpoint.

I do not agree on that. I think it is better to have something to
"blow up" in some location that I can actually do something about. If
my laptop blows up, I can reboot it myself and install updates to it
when it boots up. If some remote cloud based system crashes, it will
most likely crash again when I try to do same thing again, and I have
no control on updating the software in there.

If my IoT device crashes when someone makes some new remote attack to
it, I will change configuration of my local "thing" called firewall
and block all access to IoT device, except to those few addresses it
will need to connect to.

IoT devices usually only require connection to the one of two
locations, i.e., their own cloud service, or to my local home are IoT
gateway. In both cases protecting the IoT device is best done by
limiting access to device using normal firewall rules. Installing
firewall rules does not require seeing the traffic inside the
encrypted flow.

I might also want to add rule to say that the IoT device is only
allowed to talk to the given IP address using some specific
certificate (i.e., perhaps implement certificate pinning on the
firewall), or even make separate TLS session from the firewall to the
vendors cloud and run tls inside tls to protect the IoT device.

> Why? Network “things” can be dedicated to flows that are specific to
> a remote endpoint, like a client running a set of proxies in a cloud
> based infrastructure that they and millions of others trust, with
> each software instance of the proxy dedicated to mediating
> communication with a different server.
>
> In this context, if the server hacks the middlebox, it only hears
> it’s own conversation with the client.
>
> In contrast, if the server manages to hack a client, it
> can hear all that client is doing, including today lots of location
> based information, as well as seeing state accumulated from past
> conversations with other servers.

My local endpoint can similarly be dedicated to the flows, i.e., I can
run separate hardware protected address space for every single web
page I am viewing (I.e., start separate unix process for each web
page). I think some browsers might actually do that, as it also means
that if that process dies, you only loose one tab not the whole
browser...

Then you say that there can be attacks which breaks out from the jail
and manages to attack my whole operating system, but same is possible
also with the network "thing". I.e., worst case is that someone
manages to make attack that will break out from the cloud based
network thing and manages to gain access the actual operating system
and then to perhaps even the virtualization system also. Note, that in
this case the attacker might be both the server and client using the
"thing". i.e., attacker can use the server it controls with the client
it control to attack the clould based network "thing" that millions of
people are trusting, and gain access to everything that goes through
that cloud based system. This kind of attack is much worse than
getting access to all traffic one user is sending / receiving.

There is no difference what kind of protections can be done on the
"things" in network or in the local end point. Both can be written
using secure methods, or they can be written in not so safe ways and
contain huge security vulnerabitilies.

Updating the local endpoint might be faster or slower than updating
the network "thing". Latest operating systems will automatically
install critical security updates, browsers already either install
updates automatically or inform you about new updates immediately when
they are available.

The problem with partially invisible "things" is that for end user do
not have good visibility to them, and end user might not even be able
to update it, but must wait for the vendor to put out update.

> So, I’ll stand by my two assertions: “All software has
> vulnerabilities,” and “When things go wrong, I’d rather have them go
> wrong in an easily reset network thing, much rather than having
> things go wrong in the endpoint.”

I rather have things go wrong in location which I control, and which I
can update so after the update everything works. I do not like to wait
for days or weeks (or months/years) to get vendor install update.

My laptop vendor has not yet published updates for the Intel ME
firmware bugs....

> Back to the thought that “all software has vulnerabilities,” taking
> the discussion further, in fact, just as some endpoints have more
> vulnerabilities than others, some network appliances have more
> vulnerabilities than others. That’s of course among the reasons I
> believe it’s good for endpoints to know as much as possible about
> the network appliances which they are considering trusting with
> cleartext.

Usually also the fewer features the software has, the fewer
vulnerabilities it also has. Basic firewall doing blocking based on
the TCP flows and IP/port numbers is much simplier than full stack
application gateway acting as man in the middle of my encrypted
communications. I would trust much more with the basic firewall
"thing" than much more compicated cloud based network "thing".

>  Some people in this discussion have proposed narrowing the scope so
>  that endpoints only trust a set of well-known, manually
>  pre-configured set of such appliances, but still tackle challenges
>  like end2end integrity.

I think set of well-known pre-configured set of device is good idea
for most of the IoT devices. IoT devices usually do not want to talk
to random devices in the internet, they will need to talk to the few
things pre-configured to them. And for that filtering basic firewall
is usually enough.

This does not work for laptops or similar, but works for most of the
IoT devices.

> Power users might choose to run their own protection in their own
> cloud based infrastructure, but that’s not a random person.
>
> Many people choose to have someone or something help protect them.
> 
> Many employees choose to let their employer help protect them.

Usually employees do not have choice, the employer will choose to
"help protect" them and employee cannot opt-out...

> Many people often choose to have security companies help protect
> them.

And quite often people do not choose that either, it is chosen for
them by their laptop vendor pre-installing all kind of junk on their
new laptop which is almost impossible to get rid of... 

> Some people choose to have network providers help protect them.

Again quite often there is no opt-in in that, the ISP will "protect"
its users regardless whether they want or not.

> I believe people have a right to choose who protects from them from
> potentially malicious servers.

Yes, they should have right to choose, but in most cases they do not.
The protection is done in a way they cannot choose not to do it or
even who does it. All this is done to protect the "normal" user, so
"normal" user cannot disable security "software/thing" installed on
path by laptop vendor / employer / ISP etc...

>  I believe people have a right to choose protection from someone
>  other than the endpoint maker and someone other than the remote
>  server.

Perhaps. I think the logical way of doing that is to install software
(agant) on their endpoint they want to protect and use that to do the
opt-in... 
-- 
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 19 Dec 2017 20:38:43 +0000

I have a few reactions to Tero's message, which may not be coherent or consistent taken as a whole.  I've excerpted the text of interest. 

> and block all access to IoT device, except to those few addresses it

Some of the people on this list are among the fraction of 1% of Internet users who can configure a firewall.

However, that's probably more of an argument for ISP/ISV/IHV firewall management as a security service that may or may not be bundled with other services than an argument for encrypted traffic access.

> firewall rules does not require seeing the traffic inside the

That's not as simple as one might like.   I recently had to request opening up the corporate firewall to allow a web conferencing service (name of service omitted to protect the innocent ... and the guilty).  That request involved two TCP ports (in addition to 443) plus a large UDP port range (for RTP) across seven IPv4 address blocks whose size ranges from /26 to /21.   That's quite a bit more than "two locations," and this is something that an IoT web conferencing system could require.

> This does not work for laptops or similar, but works for most of the

That suggests separation of those two classes of use cases in discussion and design applicability.  The above line of reasoning also appears to assume that it's acceptable to prohibit P2P functionality (i.e., "talk[ing] to random devices in the Internet") in IoT devices.  I'm not sure about that.

Thanks, --David

> From: saag [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Tuesday, December 19, 2017 5:43 AM
> To: Brian Witten <[email-masked]>
> Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested -
>

---

From: Bret Jordan <[email-masked]>
Date: Tue, 19 Dec 2017 13:53:13 -0700

I have not heard anyone ask for or talk about weakening application level security or TLS. What is being asked for and talked about is how does a client know and understand which network security devices are in line and what are they doing to their traffic.  

Bret

> On Dec 18, 2017, at 23:49, Melinda Shore <[email-masked]> wrote:
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Dec 2017 23:06:59 +0200

Black, David writes:
> Some of the people on this list are among the fraction of 1% of
> Internet users who can configure a firewall.

True. On the other hand most of the network access devices (ADSL
modems, LTE modems etc) already have firewall built in and the default
configuration quite commonly is, outbound traffic allowed, inbound
traffic forbidden.

This already protects quite a lot of devices...

On the other hand as that configuration is so common, lots of IoT
devices have "call home" protocol, i.e., they will periodically
connect to some home server and ask if there is anything they need to
do, and this allows attack vector for attacking those devices. 

> However, that's probably more of an argument for ISP/ISV/IHV
> firewall management as a security service that may or may not be
> bundled with other services than an argument for encrypted traffic
> access. 

Yep. Offloading firewall configuration to security service vendor
makes lots of sense, as they can then change configuration quickly
when some kind of new attack is found out.

> That's not as simple as one might like.   I recently had to request
> opening up the corporate firewall to allow a web conferencing
> service (name of service omitted to protect the innocent ... and the
> guilty).  That request involved two TCP ports (in addition to 443)
> plus a large UDP port range (for RTP) across seven IPv4 address
> blocks whose size ranges from /26 to /21.   That's quite a bit more
> than "two locations," and this is something that an IoT web
> conferencing system could require.

What, no /48 networks? Bad, bad system, you should require proper
software that actually works on the internet instead of those old
legacy systems :-)

> That suggests separation of those two classes of use cases in
> discussion and design applicability.  The above line of reasoning
> also appears to assume that it's acceptable to prohibit P2P
> functionality (i.e., "talk[ing] to random devices in the Internet")
> in IoT devices.  I'm not sure about that. 

Yes. They are different use cases. But even then there is multiple
different use cases in the IoT too.

IoT is quite often used to mean devices that do machine to machine
communications, i.e., where there is no user or user interface on the
device. I.e., the thermostat sending temperature, or fetching the
configuration from the cloud or local server.

For those devices connecting random IP-address in the world is not
usually needed. They only communicate with the machines they are
configured to communicate with and thats it. These devices have also
long lifetime, i.e., they might be installed once and assumed to work
for next decade or two. For those devices there might also be long
term support for them, including firmware updates.

Another class of IoT, is the cheap devices connected to the internet
doing something. Those devices can include toys, webcams etc. Those
devices might actually want to do peer to peer or similar systems as
they might want to create network of other people using same devices
etc. Protecting them is going to very difficult as their behavior can
be very random or unpredictable, thus making rules for them in
firewall etc can be hard.

Also those are quite often throw-away devices, meaning that if they
are broken, they are thrown away, and there is no point of repairing
them. Updating the firmware can be considered as repairing it, thus
vendors might even not make them so they can be updated, if something
goes wrong they just say throw it away and buy new one... 
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Dec 2017 22:56:22 +0000

I think Tero's answers to many of the points raised here
are good ones. Some additional points below...

On 18/12/17 17:39, Brian Witten wrote:
> In this context, if the
> server hacks the middlebox, it only hears it’s own conversation with
> the client. 

I don't think Tero sufficiently refuted that. It's nonsense.

When a web site is breached, pretty much all database records
accessible to the breached box are considered to have been at
risk. The same is true of middleboxes, whatever that middlebox
could have seen in the relevant timeframe needs to be considered
at risk. The concept of a server attacking a single endpoint's
traffic via a middlebox is not even vaguely realistic as a way
to think about the risks of middlebox vs. endpoint vulns.

> Either scope would be better than trying to pretend that network
> appliances aren’t needed for security, 

Sorry - you already said that "needed" isn't correct. Why do you now
go back on that? Do we have to correct every single mail you send?

> Re Diego’s points I agree with him completely on all the points he
> mentioned yesterday, including changing the phrasing of point (3) to
> “may require.”  

And yet just above you accuse others on the basis that they say
these things aren't needed? Please try be consistent.

Also - "may require" is just silly. There's no reason why
middlebox security services are needed, so they are optional.

> Re “random person can sensibly decide 269 times,” um, no.  

Um yes. You specifically said this was about giving users more
control and visibility. If you're going to say such things you
ought expect to be called out for doing that.

> Many employees choose to let their employer help

That's just funny. In 30 years in this business over a range of
companies and academic engagements, I have never heard anyone
say that they chose to let their IT dept do anything like
that.

>  I believe people have
> a right to choose protection from someone other than the endpoint
> maker and someone other than the remote server.  Maybe we differ on
> this.

You'd be better off just admitting that you want to sell product
and services TBH. Miscasting that as some kind of effort aimed
at better user control and visibility is just not credible.
> Re shutting down the dedicated list for this discussion, we all
> recognize that has been your desire from the start. 

I didn't know you could speak for everyone. Thanks for clearing
that up;-)

As I said before, if this had actually been about a new multi-party
security protocol as stated in the list description then I'd have
been fine with that. But it is not about that, it's about yet another
mitm https and/or tls effort. That was my conclusion from ietf-100.
Feel free to try convince folks otherwise.

> In contrast,
> some of us see value in the discussion.  Where you concluded PATIENT
> was started for only watching what people do on the web, and not
> helping protect IOT “things,” that view is of course surprising to me
> as one of my earlier notes highlighted “particulary for … IOT
> devices,” and I continue emphasizing “increasingly closed” endpoints
> including both mobile & IOT.  Of course, like TLS, PATIENT would be
> most valuable well-covering a broad range of settings, including Web,
> Mobile Apps, and IOT.

The so-called IoT argument here isn't convincing at all.

You have classes of device that'll never do tls (e.g. lpwan stuff
as described in [1]) for layer 1/2 reasons, there are cases where
something needs to poll the device, there are cases where the
applications need to deal in vendor-independent messages and
various others all of which mean that there are many points where
you can try sell your security services without impacting on
encryption at all.

   [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview

In addition, devices need to be secured against local attack,
whether that's a drone outside the office window taking over
the lights [2], or because the device is more capable and runs
lighttpd or similar. So you cannot get away from endpoint
security actually being necessary on the devices.

   [2]
https://www.pcmag.com/news/349323/philips-smart-lights-hacked-using-a-drone

And of course, your putative mitm-modified https or tls is going
to be more complex than https or tls and those are already too
complex for many small device developers.

So no, your so-called IoT argument doesn't stack up at all.

> 
> I’m hoping
> that you are willing to grow past your (actually quite famous) a
> priori biases on this topic.  

That's rubbish. My position here reflects conclusions having
thought about these issues for years. A-prori bias my arse.

> Re, “magical thinking … new lies … and
> …snow job,” I find your choice of such words simply insulting and not
> constructive, but I’m willing to look past that here.

Good, you'll need that if you keep making such bad arguments.

I think the IETF should be a welcoming place for newcomers and a
cold and hard place for terrible ideas. I have no problem myself in
balancing those two things, esp when a terrible idea is presented
in a wildly inept manner.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Dec 2017 01:46:51 +0000

Tero Kivinen <[email-masked]> writes:

>On the other hand as that configuration is so common, lots of IoT devices
>have "call home" protocol, i.e., they will periodically connect to some home
>server and ask if there is anything they need to do, and this allows attack
>vector for attacking those devices.

Implementation of the equivalent of RFC 3093 is so widespread that I don't
know why it wasn't issued as standards-track...

The near-universal use of rendezvous servers as an extension of 3093 may
actually be worse than leaving the things exposed on the Internet [0]. Instead
of having to locate and compromise thousands or millions of individual
devices, all an attacker needs to do is get the rendezvous server and they own
all of them at once.

Peter.

[0] Comment based on no evidence whatsoever.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Dec 2017 20:21:29 -0500

Black, David <[email-masked]> wrote:
    > I have a few reactions to Tero's message, which may not be coherent or
    > consistent taken as a whole.  I've excerpted the text of interest.  

    > Internet users who can configure a firewall.

But, MUD will let us automate it this configuration.

    > However, that's probably more of an argument for ISP/ISV/IHV firewall
    > management as a security service that may or may not be bundled with
    > other services than an argument for encrypted traffic access.

Agreed.  We don't need to see the traffic to authorize it.
If we had some better home-router/desktop/phone integration, end users could
get requests and might authorize things sensibly.  Or not, but at least, they
would realize what's going on.  Again, MUD.

    > opening up the corporate firewall to allow a web conferencing service
    > (name of service omitted to protect the innocent ... and the guilty).
    > That request involved two TCP ports (in addition to 443) plus a large
    > UDP port range (for RTP) across seven IPv4 address blocks whose size
    > ranges from /26 to /21.   That's quite a bit more than "two locations,"
    > and this is something that an IoT web conferencing system could
    > require.

It would be interesting if applications could emit a cooked (JSON or maybe
XML format) file that users could forward to corporate IT that made the
request precise and exact.    Well,  really we could reuse MUD format for
that, along with the signature format, it's just that the statement would
come out of a browser rather than via https from MUD URL.

    > discussion and design applicability.  The above line of reasoning also
    > appears to assume that it's acceptable to prohibit P2P functionality
    > (i.e., "talk[ing] to random devices in the Internet") in IoT devices.
    > I'm not sure about that.

Given that we have no real technical definition of IoT (I've proposed some,
btw), it's hard to make categories.  95% of devices that currently are called
IoT are really in my definition, "Web Connected Devices", because they never
talk to anything other than the "cloud", and sometimes they want to open a
port-80 equivalent.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Dec 2017 20:31:00 -0500

> configured to communicate with and thats it. These devices have also
    
Thermostat sending temperature to furnace would be IoT.

Thermostat sending temperature to cloud so that furnace can retrieve it is
Web Connected Device.