IETF Logo Mail Archive

Re: [Patient] 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 D309C12D95E 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.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] 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 GQm3EFl-5GOy for <patient@ietfa.amsl.com>; Tue, 19 Dec 2017 03:30:45 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 43A9C12DA44 for <patient@ietf.org>; Tue, 19 Dec 2017 03:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513683043; 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=XtZCj1l+q43w+cQki4zVtDikBFfAEolVPrIvSZcAErU=; b=sZgJVUsYHWVyStvO8CSCofq+kDz0l3Jc6lOE/lcbZEn6WgoeuuhEBqDRFCKrYGJSyW z9HZJArhXmcrL5NAzDLymNF8tNdprQ3z9cMIooF0yzAWPGcR2cBO5t6hA++AcBQArmJQ YEWymUWtqLeCg/jPy/hqQMzCZQXY+hgAMrwSA=
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 j0221etBJBUh5Ta (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:43 +0100 (CET)
To: patient@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>
From: Roland Zink <roland@zinks.de>
Message-ID: <fb010ea6-1eaf-06a8-63cd-d0d9282b8706@zinks.de>
Date: Tue, 19 Dec 2017 12:30:44 +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: <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/XDjf9bIXDKsE8dreE_81nqpJ4Lk>
Subject: Re: [Patient] 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 Brian,


My two cents to this. When you are a endpoint you shouldn't trust the 
other endpoint or the network. When you are part of the network you 
shouldn't trust endpoints and probably other parts of the network. 
Especially TLS/HTTPS doesn't protect endpoints from malicous servers.


I even want to extend this from a end users point of view. In todays 
world the end user often can't control what the endpoint is doing. So 
instead of only protecting endpoints from incoming messages also the 
outgoing messages should be looked at if they break for example the 
users privacy. This can be something like removing the referer header or 
dropping audio recordings taken unnoticed by some phone, tv, tablet, 
laptop, digital assistant or whatever.


That said I'm not sure if a network element decrypting the transport 
encryption can really protect assuming that parties which want to talk 
secretely will use an additional level of encryption to prevent the 
decryption.


Regards,

Roland


Am 14.12.2017 um 00:55 schrieb Brian Witten:
> Hi Everyone,
>
> With the Wired article last week ( https://www.wired.com/story/phishing-schemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the Internet Draft ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) posted publicly for others to comment sooner rather than later.  Of course, feel free to comment here on the list or just me comments 1:1 at bwitten@symantec.com.  Thank You Either Way!
>
> Looking Forward,
> Brian
>                           
> _______________________________________________
> PATIENT mailing list
> PATIENT@ietf.org
> https://www.ietf.org/mailman/listinfo/patient

v2.23.0 | Report a Bug | By Email