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

[Stephen Farrell <[e-mail]>]

On 14/12/17 22:58, Brian Witten wrote:
> 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