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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 19 December 2017 22:56 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 323DB12D878; Tue, 19 Dec 2017 14:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 7mJkeZjePQ3M; Tue, 19 Dec 2017 14:56:28 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4653612D86E; Tue, 19 Dec 2017 14:56:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91D28BE4C; Tue, 19 Dec 2017 22:56:25 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyGVEZGMyeor; Tue, 19 Dec 2017 22:56:23 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4DBE6BE2F; Tue, 19 Dec 2017 22:56:23 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513724183; bh=ZVksAc/jyUoyPb+no27+GIDfcZDY8/6kAaJfkZvv1Tw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=4JUb4HkttD6yAJMNd6HY0SR37k/stknc74hcMGmDi4vpRqKHz567nX7X8LjoGBx+K DRUZtY14t0LJUkvYNjcBRgFdL+DGhDnVUAlzjbA0BDk/pl86RPqQ8ZkOyxc+NmHQj0 jYmLtukmrI2zQbmSrIE5Fm5djbs6OdufM3pDef3Q=
To: Brian Witten <brian_witten@symantec.com>, "Diego R. Lopez" <diego.r.lopez@telefonica.com>, "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5d0b7ed5-7bef-2c09-6d89-4d841f230b9c@cs.tcd.ie>
Date: Tue, 19 Dec 2017 22:56:22 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <MWHPR16MB14889F9F1671437D969B83D8930E0@MWHPR16MB1488.namprd16.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gA9zsIkRqIHsylvHrsmPCkz2Cy1EaV1yI"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/eeoO2oUptHox3ukStPC3AHFtZ0I>
Subject: Re: [Patient] [EXT] Re: [saag] 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 22:56:31 -0000

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.