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

Paul Wouters <paul@nohats.ca> Mon, 18 December 2017 19:15 UTC

Return-Path: <paul@nohats.ca>
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 661D412D848; Mon, 18 Dec 2017 11:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.11
X-Spam-Level:
X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 9LRgQeNIcNI5; Mon, 18 Dec 2017 11:15:13 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1621412D80F; Mon, 18 Dec 2017 11:15:13 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3z0rMg04BHz3DD; Mon, 18 Dec 2017 20:15:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513624511; bh=oD1+SFvd7QJNLAxrkZ50KfQhZ/WnuXg1qgv5YYGfapc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ldx3SvdsQBSQKRgaKPm58m2Z/71yTpiYyNxk8JuCZ5lFhXOf7j0B86SQUoX4T4klT W2rjprwyWYJDIl8Sd61D65OLbzbDTNcpppbIFstTCwL1LmJanwvNMclNQnnzNPFzeS jmO5H4WZ/B5D+mHv8N7D+BNX8HEVd6Ko1CuFJmx4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4Lkt3GJZ60CY; Mon, 18 Dec 2017 20:15:09 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 Dec 2017 20:15:09 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2640F70A3E7; Mon, 18 Dec 2017 14:15:08 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2640F70A3E7
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0F41A43A0D45; Mon, 18 Dec 2017 14:15:08 -0500 (EST)
Date: Mon, 18 Dec 2017 14:15:07 -0500
From: Paul Wouters <paul@nohats.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie>
Message-ID: <alpine.LRH.2.21.1712181354310.27010@bofh.nohats.ca>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@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> <CE03DB3D7B45C245BCA0D243277949362FE1ED76@MX307CL04.corp.emc.com> <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/gmkPtCukpim4WhSELTBQwlKrzac>
Subject: Re: [Patient] [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: Mon, 18 Dec 2017 19:15:14 -0000

On Mon, 18 Dec 2017, Stephen Farrell wrote:

> If the proponents of these mitm schemes honestly and openly
> faced up to such issues and argued for another decades-long
> arms-race and acknowledged the downsides (e.g. assisting
> censorship, breaking all sorts of application assumptions,
> and enabling pervasive monitoring) of mitm'ing https and/or
> tls then that at least would be credible. It'd still be a bad
> plan, but at least one for which we could discuss the technical
> (de)merits and not have to deal with the nonsense claims such
> at the one we both noted above.

If we did an use-cases document for this, to seperate the technical
aspects from the business aspects, the first item I would insist on
would be:

- Protection service MUST NOT be in the possession of any private
   key material that will allow it to impersonate the client identity
   to a remove server. If a client wants to delegate this responsibility,
   it MUST be able to communicate this to the server and the server MUST
   be able to deny such a request (upon which the client may decide to
   close the connection)

The problem here is that providers of these services don't want to double
the traffic load where the client decrypts then forwards for blessing.
But simply insisting that decryption has to move to the network service
isn't going to work.

Another way to accomplish this would be to have signed web pages,
so clients could send hashes for verification. But in today's dynamic
web that is also pretty problematic and would require major changes.
Of course it has the benefit of the provider not even being able to
read the users content.

The IETF discussion should not center around the business model, but
should center around designing (or not) a useful new protocol or
existing protocol modification that addresses a well defined issue.
Instead, I hear about desires and potential business models and how
some of our new technology has affected existing business models.

I also detect a culture clash where I see a lot of praise to proponents
and opponents without technical backing. At the IETF, we try to
reach consensus based on technical merit, for example by stating you
agree or disagree with certain items and why, and don't do "me too"
messages to get a count.

Paul