Re: [secdir] Review of draft-hardie-privsec-metadata-insertion-05

Yoav Nir <ynir.ietf@gmail.com> Wed, 08 February 2017 18:45 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC83129D5F; Wed, 8 Feb 2017 10:45:25 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1IMlxQFGvj0c; Wed, 8 Feb 2017 10:45:22 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AC6129D5A; Wed, 8 Feb 2017 10:45:16 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id v186so58857156wmd.0; Wed, 08 Feb 2017 10:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OrUedj1qObAJC3HT2CAUKHthOOrhyJlWXWL7EpTCFVc=; b=KJasgwqvdrTCUd/jyLNl02dmKkF2Rr7rqwdEaLkFbUEX9LtEJkqyKLuPFnVQRRzOpO fM2xfhh8FTeXXLODFI5glG2Xakx7A4MgSnCObmX0zFTUuBLzdmNH/vP837ftmah8RF2i jWeme0vsKkeh6Cg6Onxi7H+hRYBHpY6/H29iqZoRFI66/42B5cmM3ELhAItLe3Uu9jHT +N206eYYsx7leqs/4Gey9dSAuErae0M51DoAhrZ3DQ5pZyr1QNrSx46YRLFysdovypYk AfaF3RqnXRlgwkLSgzx7zpWylI2ZM/AyvboAdIFe5u0hm/xkC5kIluKOWaYyV1Z3eL9o /uLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OrUedj1qObAJC3HT2CAUKHthOOrhyJlWXWL7EpTCFVc=; b=K17nB3iNJXv+Odf1lJ1Ryg0PYwV3qMaTk8cp3qiR9imHSVnQy0orWDs12nrM0HRS4o MoteVZDx2ptmzEjsSjExUuF0UAwSy2DCmCmiUGbrArpYfTBJplkiffSTGeoHDTPR7vOo w5u3xiFympoWMYUqokRQkAcsHpUNxJSkviScu1n/hvM9aos9sbJ/FdG3APqgytFSSNP2 W6AXNIRnVCDeY5/DWq6k6pkt6crMl+0Lf9GCnzzOb2nyFZvhoj9XJZu4iYU8oelspr8q LzHCGtexQouYbu/syksL8z61s91CClo9vCZMKD6hBWqb+m3WEI3nA6VLy/Uwa0oOAEF9 eV/A==
X-Gm-Message-State: AMke39m+jLPsjkgxBeT0J/RHDOkmWxsCAmexqGRkzygWDu++TG97FF4MWr/23YB3/vBgNQ==
X-Received: by 10.28.229.193 with SMTP id c184mr20865500wmh.83.1486579515165; Wed, 08 Feb 2017 10:45:15 -0800 (PST)
Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e6sm14416601wrc.30.2017.02.08.10.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 10:45:13 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <7375E069-469A-4799-821E-684EEF885217@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2FA23AA9-C782-4202-9200-714F7259474A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 8 Feb 2017 20:45:10 +0200
In-Reply-To: <CA+9kkMCss+V2uAC9CYEQpe9FAwh3-F8EbRRCCtsgZYGhUpu=Dg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
References: <148649922555.26656.10191520146576198408.idtracker@ietfa.amsl.com> <CA+9kkMCss+V2uAC9CYEQpe9FAwh3-F8EbRRCCtsgZYGhUpu=Dg@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8buJWINMRQmtN0Ls78yFAPjr3ug>
Cc: draft-hardie-privsec-metadata-insertion.all@ietf.org, IETF <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-hardie-privsec-metadata-insertion-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 18:45:25 -0000

> On 7 Feb 2017, at 23:24, Ted Hardie <ted.ietf@gmail.com>; wrote:
> 
> On Tue, Feb 7, 2017 at 12:27 PM, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> wrote:
> Reviewer: Yoav Nir
> Review result: Has Nits
> 
> Hi
> 
> The document is well-written and understandable, but a few things
> about it seem wrong:
> 
> Section 3 describes data minimization as "one of the core mitigations
> for the loss of confidentiality". However, the only example given
> where data minimization is used to mitigate confidentiality loss is
> when browsers suppress cookies in private mode. The rest of the
> examples given (HTTP proxies, recursive DNS, VPN) are such where the
> data minimization is incidental to some other function. Nobody
> deployed the HTTP proxy or the DNS server in order to enhance
> privacy.
> 
> So, I would challenge "nobody" on the HTTP proxy front, but that's not the important piece here.  The important piece is they generally do have a net privacy positive effect.  That privacy positive effect is eliminated when metadata that would be concealed by normal operation is added back in.  That's the converse of your statement:  no one built an HTTP proxy or recursive DNS server in order to supply metadata.
> 
> Is there a specific place in the doc where more text would make this point clearer?

Perhaps an explanation of the phrase “other actors within a protocol” in paragraph 2 of section 3. Is it just intermediaries (which according to the definition in RFC 6973 are necessary for the protocol) or are there any other entities? Is it existing middleboxes that new protocols seed to modify or entirely new middleboxes?

> 
> The HTTP proxy example in particular is not convincing. HTTP is
> designed to work without proxies. Any data minimization provided
> incidentally by a proxy is nothing that can be counted on,
> 
> I'm not sure what you mean by "counted on" here.  Do you mean that you can't know the pool of other users and thus the number of times you'll be served from cache rather than getting new data?

Just that I would never write a privacy considerations section that says “The source address of the client is obfuscated because NATs and proxies are everywhere”. I can’t count on a proxy (or NAT) always being present, so I can’t count on them as the solution to the data minimization need. I *can* generally assume that clients will use a recursive DNS resolver.

> so a
> prohibition on restoring said data (especially in the case of a
> server-side load balancer) is just not convincing. OTOH in DNS
> recursive resolvers that hide the origin IP of the client are the norm
> - Authoritative servers hardly ever get to see real addresses of
> clients. In that case exposing the real IP address of the client shows
> data that was not there before.
> 
> I believe the text should differentiate between cases where a network
> element is not part of the normal function of the protocol and works
> to undo the accidental data minimization that it causes,
> 
> So, I think "accidental" is a tricky word here. The use of a proxy or recursive resolver is generally speaking not "accidental".  Data minimization is a consequence of normal operation, and what we're talking about is changing operations in order to change that data minimization.  The core of the advice is that instead of changing the operation of the middlebox, change the operation of the device about which you desire data.
> 
> What would make that clearer?

Yes. Talking about changing the operation of the middlebox assumes that the middlebox already existed. So we already had a proxy, and now it’s adding new fields. Is the advice just about extending the functionality of existing intermediaries?

> and cases
> where the network element is expected in the protocol and thus the
> minimization is expected as well. I think the prescription in the text
> applies to the latter. I am not convinced about the former
> 
> The VPN example is a strange one. If the subject is a corporate VPN,
> then restoring the original IP addresses is the function of the VPN.
> If, OTOH, VPN is that service that allows people to watch Hulu outside
> of the US, then restoring the IP address would be counter-productive.
> It is also strange to see VPN used as an example of "systems whose
> primary function is not to provide confidentiality"
> 
> Well, it does two things:  shifts the network locality of the endpoint using the VPN and masks who is shifting.  I believe the first is the primary function and the second a common secondary property.  If you would like different language on this, though, please let me know.

To me VPN is mostly about providing confidentiality and data integrity while traversing the Internet.  How about

OLD
                            similarly a VPN system used to provide
   channel security may believe that origin IP should be restored.

NEW
                            similarly a VPN system restores all of
   the metadata associated with the IP packet at the tunnel egress.


Yoav