Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG

Chris Lewis <ietf@mustelids.ca> Mon, 07 December 2015 00:15 UTC

Return-Path: <ietf@mustelids.ca>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940BE1A8A76 for <shutup@ietfa.amsl.com>; Sun, 6 Dec 2015 16:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.043
X-Spam-Level: ***
X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
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 gV1rA0em_n2D for <shutup@ietfa.amsl.com>; Sun, 6 Dec 2015 16:15:33 -0800 (PST)
Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (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 1A9691A8A74 for <shutup@ietf.org>; Sun, 6 Dec 2015 16:15:31 -0800 (PST)
Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB70FThA027366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <shutup@ietf.org>; Sun, 6 Dec 2015 19:15:30 -0500
To: shutup@ietf.org
References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <566493BA.8050707@mustelids.ca> <20151206211039.GA9984@lapsedordinary.net>
From: Chris Lewis <ietf@mustelids.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <5664CFA1.6090408@mustelids.ca>
Date: Sun, 6 Dec 2015 19:15:29 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
In-Reply-To: <20151206211039.GA9984@lapsedordinary.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/9x3Em5BG26QtlML58pftubShCp8>
Subject: Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 00:15:34 -0000

On 12/06/2015 04:10 PM, Martijn Grooten wrote:
> On Sun, Dec 06, 2015 at 02:59:54PM -0500, Chris Lewis wrote:
>> I was never so glad as to see something as the wide-scale deployment
>> of callerid a few years later.
>
> But for Caller ID to work in cases like the one you describe, you
> wouldn't need to know the phone number (which often includes the
> location) of the caller; a "cryptographic blob" identifying their phone
> line would suffice.

The proper analog is "Call Trace".  You dial a * code, and the calling 
number gets recorded by the telco, but it can only be retrieved via a LE 
process (I do not believe it requires a full search warrant, but, 
joe-blow citizen certainly can't get it).  It cannot be disabled (but 
presumably spoofable) by the caller.

> I am not a lawyer, but I believe IP addresses are considered personal
> data in some countries; the European Court of Justice is currently
> looking into the issue. I don't think it's impossible for a court to
> decide that because of this, providers should strip (submission) IP
> addresses from emails.

Anything's possible.  What's also possible that when presented in its 
entirety, a court may still agree that the operational/other benefits of 
providing them in this case outweighs the potential risk.  Nothing is an 
absolute.  There are always edge cases where informed judgment is 
required, and you rely on courts and judges to provide guidance through 
precedent.

What I also know is that when asked, regulators over here in PIPEDA land 
are most emphatic in saying that IP addresses are not PII.  And this 
_includes_ the Privacy Commissioner.

> Or perhaps one of the many tracking companies is already using this to
> correlate emails sent to website visits. This could lead to outrage
> among privacy activists and a call for providers to strip submission IP
> addresses.

That's in part why we have governments - to prevent public panics of the 
uninformed driving public policy.

We had one when callerid happened.  Callerid got "fixed" not killed.

We had one when the newspaper stories about the leaks (that ultimately 
led to the Commission I was a member of).  They were (mostly) bogus. 
But we fixed the problems that were really there and weren't in the 
newspaper stories.

We have a panic _now_.  How would you feel about security/privacy policy 
being driven by Trump and his followers?  If that doesn't scare you, it 
should.

What would really be fascinating is to get one or more people highly 
respected in their knowledge of the law, public policy and privacy to 
take on the question of passing through SUBMIT addresses.  Bring out all 
the pros and cons.  Put it on trial as it were.

> I do think the proposed charter is a bit too strong on the need to
> remove headers which, given comments here, probably isn't very helpful.
> I would be in favour of a more open-minded charter, but I do think there
> is a need for a WG like this one.

I agree, but the WG charter is too strong on the mechanics of "how" and 
has nothing at all on the mechanics of "will it do anything?" and the 
real downsides.  The charter needs to be expanded, and the WG work begun.

Perhaps one of the most important things in the WG is to decide whether 
the output is a document, and whether the document is an informational, 
a BCP or standard or STD.  My current thinking is that we're going to 
hit BCP at best.

An alternate approach occured to me - rather than trying to defacto 
impose it everywhere (which is sorta what the existing documentation is 
pushing towards), what about some sort of informational/BCP or even full 
RFC defining a "privacy enhanced interface" and outline what it needs to 
do w.r.t. email, and other service privacy?  Existing environments could 
make it an option, makes an opportunity for niche providers, and 
describes in concrete terms what it needs to do?