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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 07 December 2015 17:04 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 94AF51A9113 for <shutup@ietfa.amsl.com>; Mon, 7 Dec 2015 09:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 s3P49pY3mPGZ for <shutup@ietfa.amsl.com>; Mon, 7 Dec 2015 09:04:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73871A9084 for <shutup@ietf.org>; Mon, 7 Dec 2015 09:04:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DFA8EBE39; Mon, 7 Dec 2015 17:04:40 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gfxhyMkZagS; Mon, 7 Dec 2015 17:04:40 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EE56BE38; Mon, 7 Dec 2015 17:04:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449507880; bh=lEBlFZeU0mj4qkOX+Oe2pE1foxdWFoR1JJk4a2vEwps=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XLvuTbF9374c7fiaHMsp2T65j0vUE8qTWzXjLddyA+55Bwjyl0vkp3tbc+ew8WYSn ZAYQYgNO3NP62kjw1QfF6oc6yD19aj0ynv/dLtfjmEP1Z7atcyiMWrRN/mKWnTd9e/ g32/nI0elKQTO6ndnjX5+mqX9CB7nR5/7FeXf+tE=
To: Ned Freed <ned.freed@mrochek.com>, Christian Huitema <huitema@huitema.net>
References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com> <05b301d1304c$bf6f3880$3e4da980$@huitema.net> <01PTZNYA1SXY018EYG@mauve.mrochek.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <5665BC27.3090402@cs.tcd.ie>
Date: Mon, 7 Dec 2015 17:04:39 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <01PTZNYA1SXY018EYG@mauve.mrochek.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/iEtcUILQihKETO0C_4bQH9TjZdA>
Cc: 'SM' <sm@resistor.net>, shutup@ietf.org
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 17:04:48 -0000

Hiya,

On 06/12/15 19:31, Ned Freed wrote:
> The claim has been made - and still is made in the draft under consideration - 
> that IP addresses in  Received: field are of significant value to state actors
> and should be removed for that reason alone. But that claims fails because
> state actors have the ability to get a better version of that information from
> transaction logs.

I don't think I've seen substantiation of "significant value" to
state actors for the specific case of message author's IP addresses in
Received: fields.

OTOH, access to transaction logs should depend on the jurisdiction in
which those are located though whereas if SMTP is not (or badly)
protected via STARTTLS then those fields will be visible to monitoring
devices. And it also seems likely that that data will be stored if it
can be stored [1] as one real pattern seems to be that those doing PM
will attempt to get data via every possible avenue, even when they have
a way to convince or force service providers to co-operate.

   [1]
http://leaksource.info/2015/02/25/pony-express-cse-spying-on-canadians-emails-to-government/

So while I've not seen specific information that these fields have
been used after e.g. having been recorded via tempora or similar,
it seems credible to assume that that can be done (and hence is
being done).

> Unless you can demonstrate that state actors have an easier time going after
> message content - and that's demonstratably false in the United States and
> probably most of other jurisdictions - the specifics of what restrictions apply
> to state actors overall are entirely irrelevant.
> 
> And once again, this does *not* constitute an argument that there aren't
> *other* privacy implications for IP addresses in Received: fields that are
> worth considering. It's an argument against a specific claim that has been and
> continues to be made.

Right. There's also the case of leaked data, e.g. in the hacking team
leak case, ([2] search down the page for "homing pigeon"), those fields
in that tranche of stolen/leaked data did expose specific information
that might otherwise not have been extractable. I'm not sure if I'd call
that additional information significant or not, given all the rest of
the things the folks who did [2] could deduce from the data.

   [2] http://labs.rs/en/metadata/

(Note that I'm assuming that when [2] says "email headers reveal the
IP address of the sender" they mean from Received: fields, and not
something else.)

And to be clear, none of the above is meant to contradict the arguments
folks have made about using this information for reasonable purposes.
I figure this is just a part of the analysis of the trade offs that a
WG would have to do. (Or that someone could just go and do now before
there's a WG.)

Cheers,
S.