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