Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -
Tero Kivinen <kivinen@iki.fi> Tue, 19 December 2017 10:43 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55926127873; Tue, 19 Dec 2017 02:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SG7aLRJHVb8; Tue, 19 Dec 2017 02:43:05 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072B5127869; Tue, 19 Dec 2017 02:43:04 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBJAgtTB008354 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Dec 2017 12:42:55 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBJAgqwp018010; Tue, 19 Dec 2017 12:42:52 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23096.60715.827133.431108@fireball.acr.fi>
Date: Tue, 19 Dec 2017 12:42:51 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Brian Witten <brian_witten@symantec.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Diego R. Lopez" <diego.r.lopez@telefonica.com>, "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <MWHPR16MB14889F9F1671437D969B83D8930E0@MWHPR16MB1488.namprd16.prod.outlook.com>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <dfdb52ca-81ae-50b7-cd5f-e256b5cb047d@cs.tcd.ie> <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com> <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie> <MWHPR16MB14889F9F1671437D969B83D8930E0@MWHPR16MB1488.namprd16.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 44 min
X-Total-Time: 49 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/ufe-6j1LLt6lyFJvKr7O04zRI7Q>
X-Mailman-Approved-At: Tue, 19 Dec 2017 10:22:15 -0800
Subject: Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Dec 2017 10:43:06 -0000
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... -- kivinen@iki.fi
- [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] [EXT] Internet Draft posted as requ… Mingliang Pei
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] Internet Draft posted as requested … Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Peter Gutmann
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] Internet Draft posted as requested - Paul Wouters
- Re: [Patient] [EXT] Re: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Black, David
- Re: [Patient] [EXT] RE: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Mark Kennedy
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [saag] Internet Draft posted as req… Roland Zink
- Re: [Patient] Internet Draft posted as requested - Roland Zink
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Stephen Farrell
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Peter Gutmann
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Benjamin Kaduk
- Re: [Patient] the IETF participant choice Eggert, Lars
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Kathleen Moriarty