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

"Christian Huitema" <huitema@huitema.net> Sun, 06 December 2015 17:36 UTC

Return-Path: <huitema@huitema.net>
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 97B611A82E2 for <shutup@ietfa.amsl.com>; Sun, 6 Dec 2015 09:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 3_C57wcnOznf for <shutup@ietfa.amsl.com>; Sun, 6 Dec 2015 09:36:35 -0800 (PST)
Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E8D1A854D for <shutup@ietf.org>; Sun, 6 Dec 2015 09:36:35 -0800 (PST)
Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1a5dEc-00039B-DJ for shutup@ietf.org; Sun, 06 Dec 2015 12:36:34 -0500
Received: (qmail 7974 invoked from network); 6 Dec 2015 17:36:29 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ned.freed@mrochek.com>; 6 Dec 2015 17:36:29 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Ned Freed'" <ned.freed@mrochek.com>, "'SM'" <sm@resistor.net>
References: <6.2.5.6.2.20151205205343.0c75fed0@elandnews.com> <01PTXQAJ1Y2400HE89@mauve.mrochek.com>
In-Reply-To: <01PTXQAJ1Y2400HE89@mauve.mrochek.com>
Date: Sun, 6 Dec 2015 09:37:14 -0800
Message-ID: <05b301d1304c$bf6f3880$3e4da980$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKN73fyxiYngre5rqmJ3KfWLrx3QgKRxoaNnTAlxOA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/NNBRS7KHdNSPtDQ9E7taAUPum7w>
Cc: 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: Sun, 06 Dec 2015 17:36:37 -0000

On Saturday, December 5, 2015 10:52 PM, Ned Freed wrote:
> SM <sm@resistor.net> writes:
> 
> > An attack on organization is a security issue; it isn't a privacy
> > issue.  The privacy issue is about mail-related metadata which can be
> > collected by state surveillance agencies.  Will the proposed working
> > group attempt to fix that?
> 
> As I pointed out on the perpass list when the Received: field draft was
first
> posted, there are definitely privacy issues associated with Received:
fields,
> but metadata collection by state actors really isn't one of them. Why
bother
> with Received: fields when you can simply collect transaction logs from
> ISPs/MSPs.

Ned, you are basically saying, "why bother plugging one leak when the same
data can leak somewhere else." Well, I think it is actually important to
plug all the privacy leaks, much like in security it is important to plug
all the holes.

You are making the argument that authorities can commandeer data by imposing
on mail providers. They can, but in countries with decent rule of laws there
are limits, such as requesting probable cause and not going through fishing
expeditions. We have seen rogue agencies attempt to bypass these limits by
just taking the data whichever way they can, and we want to stop that. We
also worry that what these agencies can do today, organized gangs can do
tomorrow, and petty criminals after that.

The email traces are particular because they are carried to multiple places,
not just the submission site but also every relay and every mail recipient.
That multiplies the chances of compromise. My email provider has some reason
to try maintain my trust, but relays and recipients may not. For me, it
makes a great deal of difference whether the information can be obtained
from just one place or from many.

As I wrote in a previous message, we have a specific problem with the
correlation between IP address and user identity. Once that correlation is
established, it becomes possible to attribute 5-tuple traces to specific
individuals. You may think that the relation between someone's home IP
address and their identity is static, but in many case it is not. Some ISP
can provide you with addresses that deliberately vary over time. You can use
VPN. You can use Wi-Fi hot spots. That's exactly what privacy conscious
users do. And that's why I find the listing of submission IP in traces
problematic.

I understand that there are good use of the information, and that managing
email systems is hard. I also understand that the problem is complex. For
example, precise timestamp information can be used for debugging and
validation. But it can also be used to retrieve the IP address of a message
sender, by looking in the 5 tuple traces what addresses were sending packets
to the email provider at that time. We need to surface these issues, to
understand both the cost of the value of the information, and to propose
solutions.

-- Christian Huitema







> And unless I'm missing something, the generation and collection of
> transaction logs is far beyond the purview of the IETF.
> 
> 				Ned
> 
> _______________________________________________
> Shutup mailing list
> Shutup@ietf.org
> https://www.ietf.org/mailman/listinfo/shutup