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

Roland Zink <roland@zinks.de> Tue, 19 December 2017 11:30 UTC

Return-Path: <roland@zinks.de>
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 47AF212DA51 for <patient@ietfa.amsl.com>; Tue, 19 Dec 2017 03:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 TfQpoI6Y66t8 for <patient@ietfa.amsl.com>; Tue, 19 Dec 2017 03:30:44 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 A7CC912D95E for <patient@ietf.org>; Tue, 19 Dec 2017 03:30:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513683040; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Date:Message-ID: From:References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject; bh=6S4pj2BPtb3P2Oz2O5ggWUEV9wL/uThx8e3mksnrKFY=; b=U4ssVtG4X8If/sEjBAQuGE8NrQtATTkZullt/PY6GvobxgR6bYB+1VP+zNJqESDWEW mrPYSj7oC1Nkpowf/3W2injMeQCA4Jcbx8Rb6+iBhMi6OqdLlV9whbRZ6Kq7ubUVHkeD LBt3mXmjK8atgU0zmwjcgS6Q/CJTLtue7fwHY=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr8+BJk08DewNKUfU3E4jne94TokXG+zKOVlCUr9g==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2003:f4:73c0:c300:1db0:ea01:31b5:12f1] (p200300F473C0C3001DB0EA0131B512F1.dip0.t-ipconnect.de [IPv6:2003:f4:73c0:c300:1db0:ea01:31b5:12f1]) by smtp.strato.de (RZmta 42.14 AUTH) with ESMTPSA id j0221etBJBUe5TZ (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <patient@ietf.org>; Tue, 19 Dec 2017 12:30:40 +0100 (CET)
To: patient@ietf.org
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>
From: Roland Zink <roland@zinks.de>
Message-ID: <c917474b-6c89-a763-8359-bbd200abce52@zinks.de>
Date: Tue, 19 Dec 2017 12:30:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/B3XJrkppsKKjM7kBpBdmH799Y7o>
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: Tue, 19 Dec 2017 11:30:47 -0000

Hi Stephen,


Am 18.12.2017 um 18:08 schrieb Stephen Farrell:
> Even with supposed "knowledge" (see the number 269 below),
> cookies and other bearer tokens mean that so-called visibility
> is the same as allowing impersonation unless one doesn't
> actually ever apply the mitm technology to the web. The chances
> of that seem to be zero to me.
Impersonation is what is done on the server side for example in CDNs. 
Your data may end in a different country than you think. Do you propose 
to stop such things only on the client side?

> And of course, many of the so-called "visibility" schemes,
> immediately do allow for endpoint impersonation for everything
> and not just bearer-token situations, whenever the middlebox
> so chooses, regardless of the language used to describe those
> schemes. Which brings us back to them being no better than the
> current ickky corporate mitm root-ca stuff.
>
And the server is even allowed to instruct my browser to tell 3rd 
parties what I'm doing. The referer header is used for pervasive 
monitoring. There is not only a end-to-end connection instead there 
could be many. The end user should have control over them but is not 
even notified.


Regards,
Roland