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

[Tero Kivinen <[e-mail]>]

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