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

["Black, David" <[e-mail]>]

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. 

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

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.

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

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.

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

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

> -----Original Message-----
> From: saag [mailto:[e-mail]] On Behalf Of Tero Kivinen
> Sent: Tuesday, December 19, 2017 5:43 AM
> To: Brian Witten <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested -
> 
> 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]
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag