Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

Chris Lewis <ietf@mustelids.ca> Thu, 03 December 2015 00:21 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 9576B1B2EDE; Wed, 2 Dec 2015 16:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.343
X-Spam-Level:
X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QVy54Lxloe9q; Wed, 2 Dec 2015 16:21:39 -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 EACBD1B2EE5; Wed, 2 Dec 2015 16:21:38 -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 tB30LZxJ027608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Dec 2015 19:21:36 -0500
References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <01PTPUIP3IUK01729W@mauve.mrochek.com> <11d014e5-9a6a-4b78-92a1-8e0a1e0a905d@gulbrandsen.priv.no> <lGTaHvC8ygXWFAuu@highwayman.com> <565EBD82.2030600@pscs.co.uk> <1449065151122-b9505bf5-be5f0e83-f9cdd79b@fugue.com> <565EFD93.2060507@pscs.co.uk> <1449070095816-c64690a8-829c0c47-fd944ab9@fugue.com> <565F162F.7010109@dcrocker.net> <565F1D1F.6080307@megacity.org> <565F1FCE.9040702@cs.tcd.ie> <565F2262.9080002@dcrocker.net> <565F236A.8060609@megacity.org> <565F2959.2080606@dcrocker.net> <565F2B73.3000407@megacity.org> <s0K4btEabzXWFA88@highwayman.com> <1449083877251-a6f03969-939ef4b3-cfd12dcd@fugue.com>
To: shutup@ietf.org
From: Chris Lewis <ietf@mustelids.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <565F8B0F.6080006@mustelids.ca>
Date: Wed, 2 Dec 2015 19:21:35 -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: <1449083877251-a6f03969-939ef4b3-cfd12dcd@fugue.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/_fq-oEouiHW_npEGxYU-ato9GPU>
Cc: ietf-smtp@ietf.org
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)
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: Thu, 03 Dec 2015 00:21:40 -0000

On 12/02/2015 02:17 PM, Ted Lemon wrote:
> Wednesday, Dec 2, 2015 1:22 PM Richard Clayton wrote:

>> <https://www.lightbluetouchpaper.org/2015/11/20/the-emotional-cost-of-
>> cybercrime/>

> Does the linked article say anything to support the point you made above?   It's a study about the emotional impact of fraud, which I can tell you from personal experience, without reading the study, is pretty overwhelming, for many of the reasons cited in the study.

The linked article does support why it's so important to prevent things 
like this happening, and why people like Richard (and myself and many 
others here) use items of information like we're talking about here to 
do just that.  Prevent it where we can, stop it getting through when we 
can, and help LE catch the guys doing it.  This is (part of) what many 
of us do for a living.

> This is why I don't want 419 scammers to be able to scrape identifying info about my elderly relatives off of their email.

Do you have any evidence that 419 scammers have any email from your 
elderly relatives that's amenable to scrape such info off of, let alone, 
have any use for such identifying information?  All they need is an 
email address and a trickable recipient.  Your elderly relatives have 
probably already put their street address, phone numbers, and photos of 
their pets (complete with geolocation in the JPGs) into the emails.

The perceived threat presented by archived mailing lists isn't so much 
about received lines (archives often don't contain much header detail 
anyway), but the addresses themselves.  That is what is of interest to 
419 scammers (and the spammer that spammed me less than 3 hours after 
creating this address for the sole purpose of this discussion!). 
Shouldn't this RFC be about obfuscating email addresses in mailing list 
archives?  It'd have more effect on 419 scammers.

> As for the cops to whom you refer, who aren't mentioned in the article you mentioned, they would probably benefit from reading the RFC we've been talking about writing, since I suspect some of the information they need would be captured in it.

Here's the draft in question:

[This is brief draft critique, which you can ignore, except for the fact 
that it indicates why a WG is necessary]

https://tools.ietf.org/html/draft-josefsson-email-received-privacy-01

The only operative content is:

    The purpose of this document is to propose a mechanism that
    implementers and operators of SMTP agents may adopt to mitigate the
    privacy violation.

Note the "may adopt" - sounds optional right?

and then:

    The "from clause" of the Received header MUST NOT be added by SMTP
    entities concerned with the privacy of their clients.

1) Is there anybody out there dumb enough to assert that they're NOT 
concerned with the privacy of their customers? This is therefore 
tantamount to an absolute requirement, not an option, and could be 
treated as such and potentially enforced through the courts, as well as 
by providers using this as an easy-out to do nothing whatsoever when 
abuse is reported to them.

2) I don't see anything in there that would mitigate the loss of this 
information in either the descriptive text nor the example given - since 
the from clause is simply omitted rather than, for example, translated 
into a interpretable-only-by-the-provider identifier blob.

3) It entirely begs the question of when the information of potential 
privacy concern isn't in a "from" clause.  Such as providers who issue 
X-Originating-IP headers, "authenticated as x on y" clauses in Received 
or other headers, and perhaps even details of personal crypto key 
identifiers.  Protocol specifications are intended to be taken 
literally, a protocol specification that doesn't effectively do what you 
want is useless.

4) The security section has nothing about the downsides of removing this 
information or even hint at less-privacy invasive alternatives.

How much of this is really a social issue that has to be addressed with 
societal action compared to a technical bandaid that only helps in rare 
circumstances?  If you're concerned about, say, governmental 
surveillance, I'm thinking that fixing your government is better than 
(only occasionally) hiding just this teensy bit of information from them.