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

[Stephen Farrell <[e-mail]>]

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
> protect them. 

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.