From nobody Tue Oct 20 11:28:42 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC071ABD3F for ; Tue, 20 Oct 2015 11:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 a1NQAKnxG2th for ; Tue, 20 Oct 2015 11:28:38 -0700 (PDT) Received: from smtp.adb-centralen.se (smtp.adb-centralen.se [193.10.5.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4B11A9234 for ; Tue, 20 Oct 2015 11:28:37 -0700 (PDT) Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.adb-centralen.se (Postfix) with ESMTPSA id B6201A1FD2D for ; Tue, 20 Oct 2015 20:28:35 +0200 (CEST) From: Linus Nordberg To: perpass@ietf.org Date: Tue, 20 Oct 2015 20:28:34 +0200 Message-ID: <87r3kpmm25.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 18:28:40 -0000 Hi, draft-josefsson-email-received-privacy-00 has been submitted, see https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ I'd be interested in hearing what people on the perpass list think of this. From nobody Tue Oct 20 13:30:49 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9A01B2C61 for ; Tue, 20 Oct 2015 13:30:48 -0700 (PDT) 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 XBpxF6NSqRGh for ; Tue, 20 Oct 2015 13:30:47 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D081A1A50 for ; Tue, 20 Oct 2015 13:29:08 -0700 (PDT) Received: from internal.xmail10.myhosting.com ([10.5.2.35] helo=xmail10.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZodWL-0007Lx-CC for perpass@ietf.org; Tue, 20 Oct 2015 16:29:08 -0400 Received: (qmail 2616 invoked from network); 20 Oct 2015 20:28:30 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[167.220.100.17]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Oct 2015 20:28:29 -0000 From: "Christian Huitema" To: "'Linus Nordberg'" , References: <87r3kpmm25.fsf@nordberg.se> In-Reply-To: <87r3kpmm25.fsf@nordberg.se> Date: Tue, 20 Oct 2015 13:28:28 -0700 Message-ID: <011301d10b75$e1f19480$a5d4bd80$@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: AQEoZXbaREMHg/nZR5OmC2Ru2GkqLp/GHwow Content-Language: en-us Archived-At: Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 20:30:48 -0000 Sent: Tuesday, October 20, 2015 11:29 AM, Linus Nordberg wrote: > ... > draft-josefsson-email-received-privacy-00 has been submitted, see > https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ > > I'd be interested in hearing what people on the perpass list think of > this. Happy to see this! The text about email's Received field metadata has been in drafts leading to RFC 7624 for more than a year, and it is very good that someone active in the email working groups actually proposes a solution. Now for a suggestion. Maybe that's a difference in personal writing styles, but I found the draft a bit dry. I would have appreciated a discussion of the scenarios, and a bit of emphasis on the "submission" part, which is the most concerning for privacy. -- Christian Huitema From nobody Tue Oct 20 15:10:54 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90F1B3551 for ; Tue, 20 Oct 2015 15:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 h5_f07YjSSE9 for ; Tue, 20 Oct 2015 15:10:51 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (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 344231ACEB7 for ; Tue, 20 Oct 2015 15:10:51 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so34418469pac.3 for ; Tue, 20 Oct 2015 15:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/xvddCmGjkYCo4QFX4C8NZlYvXIlZZkYo3Gq3Xefc3Q=; b=DuyBDT+K057U8HyoHojiRI4RK7NxVoKFrSk0OYniXwMfO8y83oa67uyzCSVVGdU39J b2QXsTwEDStQHGCcKL7jr13wsZHj9SDJyTyXWacQV6U6hQsmL/iQhTttnrMaoQ6sKFYu Tot8G8EvzKf4lq7FBrzQWBCJqxhyryJ6g7RC9GCPqGgVJ0P3PKDurcmE0Glm3uiPzF/s wIVuNDteV8HmU0W8k3wGpmdJ3oHJQZhRx2E9BKJFui2uGa8Ol1koHzWNClF/vcmfmXXC +vgrXug1nvk/vFQ02Af0FK6d9qdRnhOz5QyU+FeytanRYkUvKXTmGWXMRTfgsUKwkvDU zWFA== X-Received: by 10.66.233.70 with SMTP id tu6mr6519469pac.83.1445379050497; Tue, 20 Oct 2015 15:10:50 -0700 (PDT) Received: from ?IPv6:2607:f140:400:a000:60ef:fc44:db3b:6349? ([2607:f140:400:a000:60ef:fc44:db3b:6349]) by smtp.gmail.com with ESMTPSA id qn5sm5530869pac.41.2015.10.20.15.10.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Oct 2015 15:10:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1A83534C-B12A-409C-96B1-AF8C2708E769"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Nick Doty In-Reply-To: <87r3kpmm25.fsf@nordberg.se> Date: Tue, 20 Oct 2015 15:10:44 -0700 Message-Id: References: <87r3kpmm25.fsf@nordberg.se> To: Linus Nordberg X-Mailer: Apple Mail (2.3094) Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 22:10:53 -0000 --Apple-Mail=_1A83534C-B12A-409C-96B1-AF8C2708E769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for writing this up and for sharing! > On Oct 20, 2015, at 11:28 AM, Linus Nordberg = wrote: >=20 > Hi, >=20 > draft-josefsson-email-received-privacy-00 has been submitted, see > = https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ >=20 > I'd be interested in hearing what people on the perpass list think of > this. I believe the introduction is trying to provide the use cases, but I = think it would be worth elaborating in Section 2 as to why or when an = operator should not add the Received header. If the use cases are reasonably broad, then what would be the = implications of recommending that all agents should not add a Received = header unless engaged in debugging relay problems? If that were = feasible, it seems like it would be more useful to those interested in = privacy of this header if removing the header were common, rather than a = positive indicator of the agent's choosing to maintain a special level = of privacy. Regarding the security considerations section, I don't think we should = rely on a specification note that systems should be robust. In terms of = implementations, do spam or abuse-filtering systems currently use the = Received header in practice to identify and mitigate against email spam? = What would be the security implications if widespread implementations = removed the Received header? Hope this helps, Nick --Apple-Mail=_1A83534C-B12A-409C-96B1-AF8C2708E769 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWJrvoAAoJEEAgPukLurMGzYgH/10Kdk4Fc18QOBSWHszA1UsR /DrO6D9FNXibKfJscBJRl42Svre0v0TDkZzKHyueOBLgxPbAxy8pQXWC8DGaCRKr PdN8iAWnTuTyYQs+xAaEL4S3U6zNcKv5ZfF32+LajWm1IWv1WSM36deYR/yUZg1Q g99O3ORhaXfCTFQQag+ZoI34e5WtRpRqotK9+9/Tkiv17z9DbAmPGNzplsZEwWj5 HqQIedD2+cUORDfZ/1HdYY9O5R4nlNkhwD1UPpITCviN3jE/K1Pr2V/FM9DTYITU rvysza9LFT9xAOOw/y+YtQoouyNWGTzTQS2Fh7djytLpIGyrW5bXwsDnmQOGTs8= =eR/w -----END PGP SIGNATURE----- --Apple-Mail=_1A83534C-B12A-409C-96B1-AF8C2708E769-- From nobody Tue Oct 20 23:02:32 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7121B2F61 for ; Tue, 20 Oct 2015 23:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 Yq5DbemhYsMf for ; Tue, 20 Oct 2015 23:02:29 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CA5A01B2F6F for ; Tue, 20 Oct 2015 23:02:28 -0700 (PDT) Received: from [10.0.27.109] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 10EB61A023E; Wed, 21 Oct 2015 08:02:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_75ADC41B-57CD-497C-823B-E213556E4327"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <87r3kpmm25.fsf@nordberg.se> Date: Wed, 21 Oct 2015 08:02:26 +0200 Message-Id: References: <87r3kpmm25.fsf@nordberg.se> To: Linus Nordberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 06:02:31 -0000 --Apple-Mail=_75ADC41B-57CD-497C-823B-E213556E4327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Linus, +1 to the chorus of "thanks for writing this up". I can't believe I'm going to pick 2119 nits on a -00, but here goes: "If you care about X, MUST NOT" is a weird construct. MUST is "an = absolute prohibition", so putting it next to a conditional isn't quite = right. What I think you mean is covered exactly by SHOULD NOT: "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." Of course, this sounds weaker than the nice hefty MUST NOT. But unless = we want to deprecate the Received header completely and replace it with = a less privacy-odious method to achieve operational debugging of SMTP = (which i'd be fully in favor of, though I'm not an SMTP geek so I'm not = sure what would be involved), this is as good as it gets. What is unconditional, and can be specified as such for implementations, = is that operators need a knob. So I'd suggest splitting this out, = replacing section 2 in its entirety with: SMTP protocol entities, including transfer agents and submission agents, = MUST provide operators with a mechanism to configure whether a Received = header will be added to the messages they handle. Operators of these = protocol entities SHOULD disable the Received header using this = mechanism in order to reduce risks to the privacy of the submitting = entity. Thanks again, cheers, Brian > On 20 Oct 2015, at 20:28, Linus Nordberg wrote: >=20 > Hi, >=20 > draft-josefsson-email-received-privacy-00 has been submitted, see > = https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ >=20 > I'd be interested in hearing what people on the perpass list think of > this. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_75ADC41B-57CD-497C-823B-E213556E4327 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWJypyAAoJEIoSt78L6kaj+8gP/07C802wpud/9wvIEatCBSpm NEQPdnqvn4EFHgwshlDHJZNOrc0MJ7ZXfA0RGmRaBrDf8NleH3/LYGDBrdEGaCoj SoD5h/FJ0tpAs9wJh40Vm5gE6CIceppF9oapu2QGI3wwV/VAf5GtSPOMdDXfPXrV mqK2C+WatXf0T2Rc2Kc8428AudxAuhoroH0tYu2ZUra6w5Ji1UgOZ886v3kPb4CH ZpNlM3E73tTWFwVgdStuuYlCOuXXzQcZyoV1yx8DkybZWtl7D8d3qOVT5JtuWV62 VZLX346titJfmEmCz5TqVAMTKBmahkUqRN+k9t7fU6aOVULvz0bJCYlohn0C69Kt CMEh+BgziK8V6UwsVEljLG1lFb1uiDTGvkjTYdzL/xfzhkYeLVgiDPmdOWc/Mtg5 i04dEmWdnjH9IHSIGgQJr+2G+Rz7g3Uh6g+ms4jxX5MzT2uJ1yobpn0eefwrAm+q 5BCRgXCMsbVjS9W8KC4XWRV7pBL3RvAEjYNqcDotMko/q74qrqIMKI+5Y+6q7Tlt 04IRfV+k9D/VbaTnmEmntMVOkRhGlUitHgJgu0TnJ4+9gYe/v7hifYO594xu9Pjn iQXY2PwCAMGjQ14OTOCmth5o9YhS7e+nefdmjnjUUPeTV8LsdgidPIco2WZ4kgFE 8pdI/JfOQ28QjbwBq1d7 =O9zb -----END PGP SIGNATURE----- --Apple-Mail=_75ADC41B-57CD-497C-823B-E213556E4327-- From nobody Wed Oct 21 22:49:48 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27F1B2E7E for ; Wed, 21 Oct 2015 22:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 T4f7xwNJWrms for ; Wed, 21 Oct 2015 22:49:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9141B1B2E7D for ; Wed, 21 Oct 2015 22:49:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PS6UMJAI1C000PWF@mauve.mrochek.com> for perpass@ietf.org; Wed, 21 Oct 2015 22:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1445492682; bh=U9SSMHziNo9XmmOyD62Sse4UxVxxyU6zCIPAjHbcQz8=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=MV0Kz4Bup1zVugVns8wv1eCrj2QiPBcU6VmKj1gT+jzWBUl7OOztXf00XuIGkYmhh qo6Sv6QaFujZ8oZiskvoLRtF3wrjwf0jRyzeYi5Jdq/ivB/QkcxDPjOQBoa39nT8Cd Y/N2fTe+eav/YVnhKidTKUOFd4/ERO8qVggvTg+w= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PS0CK0G5IO01729W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Wed, 21 Oct 2015 22:44:40 -0700 (PDT) From: ned+perpass@mrochek.com Message-id: <01PS6UMHPA8S01729W@mauve.mrochek.com> Date: Wed, 21 Oct 2015 21:27:02 -0700 (PDT) In-reply-to: "Your message dated Tue, 20 Oct 2015 20:28:34 +0200" <87r3kpmm25.fsf@nordberg.se> References: <87r3kpmm25.fsf@nordberg.se> To: Linus Nordberg Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 05:49:46 -0000 > Hi, > draft-josefsson-email-received-privacy-00 has been submitted, see > https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ > I'd be interested in hearing what people on the perpass list think of > this. It looks to me like the IETF is belatedly coming up to speed on a problem that the email community - the large scale providers at least - is already in the process of solving. And while it would be nice to write down some best practices here so everyone knows what to do, the method described in this draft is *not* that best practice in any way, shape or form. In fact its adoption would cause widespread damage to the email infrastructure. Getting down to specifics: This proposal effectively makes the addition of Received: fields optional: You only do it when you feel like it. The obstensible purpose of this change is to prevent exposure of the sender's IP address in the context of pervasive surveillance. However, this removal, were it to occur, is not terribly effective in achieving this specific goal. Why? Because this does nothing prevent the IP address from being logged elsewhere. And those logs often enjoy far less legal protection - in some cases no protection at all - than actual message content. And good luck convincing ISPs and MSPs not to collect this information. If anything the removal of this information from messages for this claimed result may create a false sense of security in regards to persuasive surveilance. All that said, there is a real privacy gain in not including this information in messages. State actors with subpeona powers may have easy access to ISP/MSP logs, but other players, including legitimate message recipients, do not. And my location at the time I send a piece of mail really isn't the concern of any of the message's recipients unless I choose to reveal it. So where is the information stored and how can eliminate it safely? It's in the from clause of the Receved: field generated by the SUBMIT server. The from clause is mandatory, but there's noting that says the clause has to actualy contain anything meaninful. So the obvious solution is to dummy information. (My personal preference would be to define a well known name or names for this purpose and use that without any IP address information at all, which the ABNF in RFC 5321 explicitly allows.) And this approach has already been deployed, successfully AFAICT. (To be fair, gmail appears to have done it by dropping from clauses entirely - a syntax violation.) We added an option to override the from clause to our product a few months ago. (And I'm told we're fairly late to this particular party.) Now, received fields are, as the draft notes, generated at other times, and the name/address information in them can reveal internal network topology to some extent. This concern is, IMNSHO, considerably overblown, but sanitizing from clauses generated by internal relay steps may make sense in some specific cases. And what about other aspects of the Received: field? The remainder of the (all optional) clauses that Received: fields support also reveal information to some extent and a detailed security analysis of all of them should be undertaken as part of any work undertaken in this area. That leaves the presence of the Received: field itself and the timestamp. The former is critical to the proper functioning of the email transport infrastructure: Received: field counting is the primary mechanism used to prevent mail loops. And there's ample operational experience in the field with the bad things that happen when the requirement to add Received: fields is ignored or agents remove them willy-nilly. The timestamp is quite useful in tracking routing delays after the fact. It also doesn't reveal all that much given how it's going to be brackted by the Date: field and the IMAP internaldate. In summary, the present proposal as presently written is a nonstarter because it breaks critical email functionality: The ability to detect and block mail loops. In also unnecessarily causes the removal of highly useful timing and trace information. An approach based on current inductry practices should be considered instead and specific guidance on when the mechanism should be employed needs to be given. Ned From nobody Thu Oct 22 02:27:52 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5CE1B2F66 for ; Thu, 22 Oct 2015 02:27:50 -0700 (PDT) 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 SZM6GdZpiX3B for ; Thu, 22 Oct 2015 02:27:48 -0700 (PDT) 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 9D62B1B2F6E for ; Thu, 22 Oct 2015 02:27:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ACC69BE50; Thu, 22 Oct 2015 10:27:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 ZhW224mMcwl8; Thu, 22 Oct 2015 10:27:45 +0100 (IST) Received: from [10.87.48.91] (unknown [86.42.31.61]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A8ACBE4D; Thu, 22 Oct 2015 10:27:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445506065; bh=xQZXyIqTPmMuAllzPCsWua7wXOJbWMwslco8+6p2+JI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ATKye4sPJI/h8pRJh1LmvH5RTPUaZTjCrx+pybBbNpShYnj+w36iFD3olnCqd8qUy 7YV0POTq0Ul1Pd1ppy3QK2zL3IvUweR9jyi/9xOCsVkcKTinmhoySq5Ig9VhfYYzWL Le+m7z5iNGsb/ouMMp9XdiL3aZ6cPMMcyfb8kEyE= To: ned+perpass@mrochek.com, Linus Nordberg References: <87r3kpmm25.fsf@nordberg.se> <01PS6UMHPA8S01729W@mauve.mrochek.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5628AC0E.3030400@cs.tcd.ie> Date: Thu, 22 Oct 2015 10:27:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <01PS6UMHPA8S01729W@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 09:27:50 -0000 Ned, On 22/10/15 05:27, ned+perpass@mrochek.com wrote: > In summary, the present proposal as presently written is a nonstarter because > it breaks critical email functionality: The ability to detect and block mail > loops. In also unnecessarily causes the removal of highly useful timing and > trace information. An approach based on current inductry practices should be > considered instead and specific guidance on when the mechanism should be > employed needs to be given. I have to say that conclusion, or something like it, seems reasonable even if the presentation of the argument leading up to it read to me as being quite needlessly aggressive. Ned - Is that an offer to help the authors e.g. by offering new text or describing to them in more detail what others have done (maybe via pointers) so the authors can document that better? S. PS: I would assume this draft will end up being processed via dispatch (or however the art area continue handling small-new-work) so that it will definitely get review from appropriate folks before being done. From nobody Thu Oct 22 03:56:05 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4C1A1A7F for ; Thu, 22 Oct 2015 03:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 DJZJWzXxOvOR for ; Thu, 22 Oct 2015 03:56:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id F25671A1A80 for ; Thu, 22 Oct 2015 03:56:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PS75B9HYOW0025Z9@mauve.mrochek.com> for perpass@ietf.org; Thu, 22 Oct 2015 03:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1445511059; bh=ek5ZaUbmY9MbLmVfLl3VwAyjBprtokTWRtSG4Hzi388=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=Pinkg8Q6R6TTDpTBwkeok7o2LPRzgx7vv4uk5T8qRsm5gi3opUPxUOVYad3zDAHuw ck9aJDEn3IEC3/NycYdq+n4K4uI2PdA1jBGD1Yj03BNb5eXvErKh+LY1qRB/ZcP5wS 1pcoRLd03Lo2njJ7piVLM3gXW7iPURwa9BOseUoQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PS6U7ZGVV400HE89@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Thu, 22 Oct 2015 03:50:55 -0700 (PDT) From: ned+perpass@mrochek.com Message-id: <01PS75B6KR1W00HE89@mauve.mrochek.com> Date: Thu, 22 Oct 2015 03:47:41 -0700 (PDT) In-reply-to: "Your message dated Wed, 21 Oct 2015 21:27:02 -0700 (PDT)" <01PS6UMHPA8S01729W@mauve.mrochek.com> References: <87r3kpmm25.fsf@nordberg.se> <01PS6UMHPA8S01729W@mauve.mrochek.com> To: ned+perpass@mrochek.com Archived-At: Cc: Linus Nordberg , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 10:56:04 -0000 Correction to my previous posting: The by clause is also mandatory in Received: fields, and contains a domain and optionally an IP address. To the extent it represents a privacy exposure, it can be handled in the same fashion as the from clause. Ned From nobody Fri Oct 23 05:39:39 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C91B303B for ; Fri, 23 Oct 2015 05:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 NbsauWyRg5VF for ; Fri, 23 Oct 2015 05:39:37 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 E59451B35B0 for ; Fri, 23 Oct 2015 05:39:36 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9NCdG3E030905 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Oct 2015 14:39:17 +0200 From: Simon Josefsson To: "Christian Huitema" References: <87r3kpmm25.fsf@nordberg.se> <011301d10b75$e1f19480$a5d4bd80$@huitema.net> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151023:perpass@ietf.org::9vq6Abev83K2V5Gx:101 X-Hashcash: 1:22:151023:huitema@huitema.net::F2Ra9y4FFd8YkxxG:6yXh X-Hashcash: 1:22:151023:linus@nordberg.se::6LpI7imz5yc/cIAO:k/gY Date: Fri, 23 Oct 2015 14:39:15 +0200 In-Reply-To: <011301d10b75$e1f19480$a5d4bd80$@huitema.net> (Christian Huitema's message of "Tue, 20 Oct 2015 13:28:28 -0700") Message-ID: <878u6t3gjw.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: 'Linus Nordberg' , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 12:39:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable "Christian Huitema" writes: > Sent: Tuesday, October 20, 2015 11:29 AM, Linus Nordberg wrote: >> ... >> draft-josefsson-email-received-privacy-00 has been submitted, see >> https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ >>=20 >> I'd be interested in hearing what people on the perpass list think of >> this. > > Happy to see this! The text about email's Received field metadata has been > in drafts leading to RFC 7624 for more than a year, and it is very good t= hat > someone active in the email working groups actually proposes a solution. Thank you. > Now for a suggestion. Maybe that's a difference in personal writing style= s, > but I found the draft a bit dry. I would have appreciated a discussion of > the scenarios, and a bit of emphasis on the "submission" part, which is t= he > most concerning for privacy. Agreed -- the draft was written hastily before the IETF -00 cut-off date and could surely benefit from a better introduction of the problem. If you have concrete suggestions on what to (or not) focus on in more detail, that would be appreciated. We will make a stab at improving this section shortly. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWKipzAAoJEIYLf7sy+BGdyKAH/RrcI6IjIgrRK39ix0V1M9RP p37Fe/CA1Z3ne0pkeHL4antoTTx+PKJk9VE6WLpRPW8IyCc/Fk8WF5m6980khz8N vAOqFlufKVLVbXjPumw+jlAehL8PN02TUrmfXLHIvPWXoboXv8k+3W3vUusCG6Yi LWok0e+CHyoymhTlA14ewc4OkYKJDP6qm8plyyGMpOQqFMQEl5cPfmry9LYRHiDX eKW0XRhFGRLEZAX1d8auCGLBhU2SScPHA+OgCRs9k01pehOjdNuvwB8/lEjUilWe fSH4H9x0/97ra2TBE7XB4UGDHRCiIRFaoK1fqPflKMYBHkXGm+dbbzvfkvAiyCI= =82pN -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 23 06:13:05 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908531A0022 for ; Fri, 23 Oct 2015 06:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 D7HoXtn6zXpp for ; Fri, 23 Oct 2015 06:13:02 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 5127E1A0024 for ; Fri, 23 Oct 2015 06:13:00 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9NDCjFq001787 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Oct 2015 15:12:46 +0200 From: Simon Josefsson To: ned+perpass@mrochek.com References: <87r3kpmm25.fsf@nordberg.se> <01PS6UMHPA8S01729W@mauve.mrochek.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151023:linus@nordberg.se::7/CcNvUBQ0kLWn7v:/7X X-Hashcash: 1:22:151023:perpass@ietf.org::S3JzFhbgR50/o6kr:0SQO X-Hashcash: 1:22:151023:ned@mrochek.com::jDGiPO5CPZVezv4e:DSBM Date: Fri, 23 Oct 2015 15:12:44 +0200 In-Reply-To: <01PS6UMHPA8S01729W@mauve.mrochek.com> (ned's message of "Wed, 21 Oct 2015 21:27:02 -0700 (PDT)") Message-ID: <871tcl3f03.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Linus Nordberg , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 13:13:03 -0000 --=-=-= Content-Type: text/plain Hi Ned, Thanks for looking at the document! We are happy to make this more inline with what you and others are doing or suggest to do. With the -00 we wanted to get the ball rolling, to be able to discuss what to do about the problem. We don't care strongly what the particlar approach is as long is it does its job. Given the responses so far, I believe we even have some work to do on getting the problem statement itself right, let alone the proposed solution. I agree with you about the problem related to loop detection (RFC 5321 section 6.1), so agree that it is a valid argument for not making the header optional. Jacob Appelbaum brought up that the trace information about what authentication parameters were used can be interesting and does not appear to be a significant privacy violation. So that's another argument for retaining the header. He also mentioned that timestamp information are problematic due to netflow related data. I agree with your recommendation to retain the Received header but modify what to put in it. I believe the FROM clause should be removed completely, or we put in a "magic" (syntactically valid but semantically invalid) IPv4 or IPv6 address in it. Similarily, implementations could put a magic time-stamp value in the field if they don't want to reveal when they received a particular message. When I look at the ABNF for Received in RFC 5322 I'm confused as I don't see how the normally used Received: headers on the Internet (i.e., with 'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token or the 'obs-received' token. Is this a RFC 5322 bug? The BNF in RFC 822 and RFC 2822 appears to work. We could use your help here :-) /Simon ned+perpass@mrochek.com writes: >> Hi, > >> draft-josefsson-email-received-privacy-00 has been submitted, see >> https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/ > >> I'd be interested in hearing what people on the perpass list think of >> this. > > It looks to me like the IETF is belatedly coming up to speed on a problem that > the email community - the large scale providers at least - is already in the > process of solving. And while it would be nice to write down some best > practices here so everyone knows what to do, the method described in this > draft is *not* that best practice in any way, shape or form. > > In fact its adoption would cause widespread damage to the email infrastructure. > > Getting down to specifics: This proposal effectively makes the addition of > Received: fields optional: You only do it when you feel like it. The > obstensible purpose of this change is to prevent exposure of the sender's IP > address in the context of pervasive surveillance. > > However, this removal, were it to occur, is not terribly effective in achieving > this specific goal. Why? Because this does nothing prevent the IP address from > being logged elsewhere. And those logs often enjoy far less legal protection - > in some cases no protection at all - than actual message content. And good luck > convincing ISPs and MSPs not to collect this information. > > If anything the removal of this information from messages for this claimed > result may create a false sense of security in regards to persuasive > surveilance. > > All that said, there is a real privacy gain in not including this information > in messages. State actors with subpeona powers may have easy access to ISP/MSP > logs, but other players, including legitimate message recipients, do not. And > my location at the time I send a piece of mail really isn't the concern of any > of the message's recipients unless I choose to reveal it. > > So where is the information stored and how can eliminate it safely? It's in the > from clause of the Receved: field generated by the SUBMIT server. The from > clause is mandatory, but there's noting that says the clause has to actualy > contain anything meaninful. So the obvious solution is to dummy information. > (My personal preference would be to define a well known name or names for this > purpose and use that without any IP address information at all, which the ABNF > in RFC 5321 explicitly allows.) > > And this approach has already been deployed, successfully AFAICT. (To be fair, > gmail appears to have done it by dropping from clauses entirely - a syntax > violation.) We added an option to override the from clause to our product a few > months ago. (And I'm told we're fairly late to this particular party.) > > Now, received fields are, as the draft notes, generated at other times, and the > name/address information in them can reveal internal network topology to some > extent. This concern is, IMNSHO, considerably overblown, but sanitizing from > clauses generated by internal relay steps may make sense in some specific cases. > > And what about other aspects of the Received: field? The remainder of the (all > optional) clauses that Received: fields support also reveal information to some > extent and a detailed security analysis of all of them should be undertaken as > part of any work undertaken in this area. > > That leaves the presence of the Received: field itself and the timestamp. The > former is critical to the proper functioning of the email transport > infrastructure: Received: field counting is the primary mechanism used to > prevent mail loops. And there's ample operational experience in the field with > the bad things that happen when the requirement to add Received: fields is > ignored or agents remove them willy-nilly. > > The timestamp is quite useful in tracking routing delays after the fact. It > also doesn't reveal all that much given how it's going to be brackted by the > Date: field and the IMAP internaldate. > > In summary, the present proposal as presently written is a nonstarter because > it breaks critical email functionality: The ability to detect and block mail > loops. In also unnecessarily causes the removal of highly useful timing and > trace information. An approach based on current inductry practices should be > considered instead and specific guidance on when the mechanism should be > employed needs to be given. > > Ned > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWKjJMAAoJEIYLf7sy+BGdhWcH/2iB6hFP7rBgnrTMuCTv/hdF Y57I7Bphhq3NGsnBmf87wEWeefynP/2ufQKclf3YBLA9mh0FaPU7q4kUtUJRBLTw XnNj6TaYvxk6nEeO5otW4GlEbccJoENIyvBqwPoU6wGhjpoGVi8lF8aFNdq3gC+s 4Xx5CpSS8OB2DyJFSb3qBA9xg9dPQndtn7vHRdJpfry/0/X2vbvmj2RQpk5V6KLa thJbPt6QMlgoxf09K04EuWbBQoHTEjEIBsQfF1EdMnQDczHpbymP0H1FA2WjB5ER THWjW9o+zzr3KHQub1FbdZ5q1D6C1ggnkUdZ/Y1Y20uSjlW1W9evGCDXLKacvo4= =m83V -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 23 06:17:37 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D71A004D for ; Fri, 23 Oct 2015 06:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 uxQ3wEKqBMxy for ; Fri, 23 Oct 2015 06:17:34 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 2642B1A0040 for ; Fri, 23 Oct 2015 06:17:33 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9NDHQFg002290 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 23 Oct 2015 15:17:27 +0200 From: Simon Josefsson To: ned+perpass@mrochek.com References: <87r3kpmm25.fsf@nordberg.se> <01PS6UMHPA8S01729W@mauve.mrochek.com> <01PS75B6KR1W00HE89@mauve.mrochek.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151023:perpass@ietf.org::tGy7sRNOSPdLVNYj:Fxky X-Hashcash: 1:22:151023:linus@nordberg.se::tICy+TlsmZgXxmq3:IlIo X-Hashcash: 1:22:151023:ned@mrochek.com::SON/1tA1m2OC0Q5D:eFAC Date: Fri, 23 Oct 2015 15:17:25 +0200 In-Reply-To: <01PS75B6KR1W00HE89@mauve.mrochek.com> (ned's message of "Thu, 22 Oct 2015 03:47:41 -0700 (PDT)") Message-ID: <87wpud207u.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Linus Nordberg , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 13:17:35 -0000 --=-=-= Content-Type: text/plain ned+perpass@mrochek.com writes: > Correction to my previous posting: The by clause is also mandatory in > Received: fields, and contains a domain and optionally an IP address. > To the extent it represents a privacy exposure, it can be handled in the > same fashion as the from clause. Thanks for pointing this out. We didn't see the BY clause IP/hostname as serious of a problem, since it is the entity who owns that IP address who puts the line in there. If that entity doesn't want its own IP address in there, it could lie. The FROM clause contains the IP address of someone else, who the entity isn't necessarily authorized to store and forward IP address information about, so it is more problematic. But I agree that both concerns are relevant and that the document should allow, and probably encourage, not leaking any of the IP addresses. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWKjNlAAoJEIYLf7sy+BGdlV0IAIfBSgP9voSd/lgvLuI2amTW igaFDdpgp8Juavoo1j8LVPc8Nxsn6AUgxZRcA670myYFeHaJWJBB5gQIrDPwoEOc Z/crV2Xywmr6ff5LoST8bkl7ijQNcBE4SeHa3Hfs0cGS/Zt3adEGqciuPJ0RRvOZ hzbOL3d+/GGAAaayRZ3QGiVztjPx3p10QeLfG6Q416bX+Rch9I3I1Beocj5RKjO4 Na0gbu8laLvQYc3lcGVjFIwyAF69B4528H/J6nPExm7tFdaE9b4BviI7vVZ1Mt+y ZxpuAz2EAqlW9DV4TSEWxvtSjQcUew6BmDn4t3bV+jaq9BNdVDdiiIIwPS4kP4U= =6XPX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 24 14:12:20 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305A61A1BA2 for ; Sat, 24 Oct 2015 14:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ELYtMXMFnfQv for ; Sat, 24 Oct 2015 14:12:16 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 7F55C1A1AB8 for ; Sat, 24 Oct 2015 14:12:16 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so70900167wic.0 for ; Sat, 24 Oct 2015 14:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WwaqWOsSJFy/MVbz7ytpOpXJ2yDUb9ntJPKYdqVukq8=; b=hj2DLPozAboY/GG33QgS5AKUqUPqMDBv4ABcY7uxQ50w4LHDXGczaiSf+KOAKseQmo pbhqVWIPKt2OLofogvDNu/VqJt7j1uiQNeU+b7ZzeB/GE2oGqXJY5d6+WiKcPlVDQOlP Dg7ioEuUYcqx3Jn650RqmSdWjZH2omAXc656RcTFa2YWaukww6pWm7Jq5eCiI6dfhSBd OyM6IXBjV7STfGGPcpnM+te61TAC0MSx5ercu8InjpyONMGhOpJZG02xXmdbnOoEDUsA A0dawOkP5TOsOWV4BafnD8CCWvy06qf3MiKoVpPbSJzjT3qMya/pSIrtvFQU2wJVvAVc 8MZA== X-Gm-Message-State: ALoCoQnBS90ZC7VQFi7+M9/ePz1xVRd+tqD+uHiDemEH2geVLkBNhMOIorrb/uiw+AvC30SELQhH MIME-Version: 1.0 X-Received: by 10.194.9.233 with SMTP id d9mr11479187wjb.129.1445721134989; Sat, 24 Oct 2015 14:12:14 -0700 (PDT) Received: by 10.28.173.17 with HTTP; Sat, 24 Oct 2015 14:12:14 -0700 (PDT) X-Originating-IP: [171.25.193.25] In-Reply-To: <871tcl3f03.fsf@latte.josefsson.org> References: <87r3kpmm25.fsf@nordberg.se> <01PS6UMHPA8S01729W@mauve.mrochek.com> <871tcl3f03.fsf@latte.josefsson.org> Date: Sat, 24 Oct 2015 21:12:14 +0000 Message-ID: From: Jacob Appelbaum To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ned+perpass@mrochek.com, perpass@ietf.org, Linus Nordberg Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 21:12:18 -0000 On 10/23/15, Simon Josefsson wrote: > Hi Ned, > > Thanks for looking at the document! > > We are happy to make this more inline with what you and others are doing > or suggest to do. With the -00 we wanted to get the ball rolling, to be > able to discuss what to do about the problem. We don't care strongly > what the particlar approach is as long is it does its job. Given the > responses so far, I believe we even have some work to do on getting the > problem statement itself right, let alone the proposed solution. > > I agree with you about the problem related to loop detection (RFC 5321 > section 6.1), so agree that it is a valid argument for not making the > header optional. > > Jacob Appelbaum brought up that the trace information about what > authentication parameters were used can be interesting and does not > appear to be a significant privacy violation. So that's another > argument for retaining the header. He also mentioned that timestamp > information are problematic due to netflow related data. > I think it should be possible to produce a general timing and to state the crypto (or lack of crypto) used for transmission. > I agree with your recommendation to retain the Received header but > modify what to put in it. I believe the FROM clause should be removed > completely, or we put in a "magic" (syntactically valid but semantically > invalid) IPv4 or IPv6 address in it. Similarily, implementations could > put a magic time-stamp value in the field if they don't want to reveal > when they received a particular message. > Those both seem reasonable. > When I look at the ABNF for Received in RFC 5322 I'm confused as I don't > see how the normally used Received: headers on the Internet (i.e., with > 'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token > or the 'obs-received' token. Is this a RFC 5322 bug? The BNF in RFC > 822 and RFC 2822 appears to work. A feature!. ;-) All the best, Jacob From nobody Sat Oct 24 15:46:48 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D749A1A877E for ; Sat, 24 Oct 2015 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 2GTBi1haPkzV for ; Sat, 24 Oct 2015 15:46:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3401A877A for ; Sat, 24 Oct 2015 15:46:45 -0700 (PDT) Received: (qmail 25997 invoked from network); 24 Oct 2015 22:46:45 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Oct 2015 22:46:45 -0000 Date: 24 Oct 2015 22:46:21 -0000 Message-ID: <20151024224621.15562.qmail@ary.lan> From: "John Levine" To: perpass@ietf.org In-Reply-To: <871tcl3f03.fsf@latte.josefsson.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: simon@josefsson.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 22:46:47 -0000 >I agree with your recommendation to retain the Received header but >modify what to put in it. I believe the FROM clause should be removed >completely, or we put in a "magic" (syntactically valid but semantically >invalid) IPv4 or IPv6 address in it. Similarily, implementations could >put a magic time-stamp value in the field if they don't want to reveal >when they received a particular message. I was going to say it would make it impossible for me to send spam reports, since I would have to way to tell who sent it, but then I realized it would make no difference, since each received header my system adds has a sequence number I can look up in the mail logs and find out the connecting IP and time and a lot of other stuff. But I'd like to back up a little. You know how crypto people feel when someone shows up with a wonderful new crypto scheme? And then when the someone says well, just tell me what's wrong with it? Mail is a lot like that. It's much more complex and subtle than it appears, even to people who've used it casually for a long time. There are lots and lots of ways that a mail system can leak PII that are unrelated to Received headers. For example, MTAs look up the connecting IP of each message in DNSBLs, they check SPF records, they look up DKIM key records (which in my mail are unique for every message), they look up DMARC records, they swap checksums with bulk counting systems, they put stuff in Authentication-Results: headers, and that's just what I can think of in two minutes. When a mail system is large enough that it has to spread the load across multiple MTAs, there's more traffic among them to keep things in sync. My suggestion would be to start by finding people who have experience in large mail systems (Ned would be a good start if he has the time), and then state clearly what you're trying to do. It looks like it's identifying and minimizing the amount of PII collected, reported (to downstream consumers), and logged (for internal users) for incoming mail. Once you've done that, it'd be quite interesting to try and see what gets collected, and what the tradeoffs are if you don't collect it or don't report or log it. R's, John From nobody Sun Oct 25 18:42:19 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89C01B34BD for ; Sun, 25 Oct 2015 18:42:18 -0700 (PDT) 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 dX0ZbOB4ryCL for ; Sun, 25 Oct 2015 18:42:17 -0700 (PDT) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E511B34BC for ; Sun, 25 Oct 2015 18:42:17 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ZqWnf-0005qj-4z for perpass@ietf.org; Sun, 25 Oct 2015 21:42:15 -0400 Received: (qmail 11895 invoked from network); 26 Oct 2015 01:42:14 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Oct 2015 01:42:13 -0000 From: "Christian Huitema" To: "'John Levine'" , References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> In-Reply-To: <20151024224621.15562.qmail@ary.lan> Date: Sun, 25 Oct 2015 18:42:09 -0700 Message-ID: <0c5701d10f8f$882e4a10$988ade30$@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: AQH36Hh0YWG0tWsa7GeCo3UFI7WppJ4vTNRw Content-Language: en-us Archived-At: Cc: simon@josefsson.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 01:42:18 -0000 On Saturday, October 24, 2015 3:46 PM, John Levine wrote: > ... > My suggestion would be to start by finding people who have experience > in large mail systems (Ned would be a good start if he has the time), > and then state clearly what you're trying to do. It looks like it's > identifying and minimizing the amount of PII collected, reported (to > downstream consumers), and logged (for internal users) for incoming > mail. Once you've done that, it'd be quite interesting to try and see > what gets collected, and what the tradeoffs are if you don't collect > it or don't report or log it. That sounds like a reasonable plan. Let's start, then. What about having interested parties meet at a bar in Yokohama, say Monday evening, and start drafting the first solution? I would be happy to pay the first round of drinks, if that speeds up consensus... -- Christian Huitema From nobody Sun Oct 25 19:01:10 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495231B34D4 for ; Sun, 25 Oct 2015 19:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 TcU_1M1ChTZm for ; Sun, 25 Oct 2015 19:01:07 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1671A1B34D2 for ; Sun, 25 Oct 2015 19:01:06 -0700 (PDT) Received: (qmail 26795 invoked from network); 26 Oct 2015 02:01:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=68aa.562d8963.k1510; bh=KXWArfXBfSPi066mtwttQNV5WZJCDkNWYPjY5mv6W/c=; b=oM7hkjz5Za9tXGGn1d7mCyjmP9QuO1aGqkrsjcR+Y4+PY/leSd2/jkPQ/uPBFRWYH47BxPW+LAdhs8zJJgleURBEPL5s4j41ojKdzp/Um2STnJmQ1BwvwTSqCA0T3IqcPcrQHWLgq8A/ngOXzZtQkaEgtvIMUebWMYXsWnee4Gz/OsjEqHw+uVWSnOe7yrvQbir+PaSzhEWwWc/VTVBDxdtv1lKpxqpXwg+pkSZwAXwhOmTmKJk4YIZPYkD+GlEg DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=68aa.562d8963.k1510; bh=KXWArfXBfSPi066mtwttQNV5WZJCDkNWYPjY5mv6W/c=; b=JpX6lKQGJ92gOZrDMNURvH8SVkgdkTTBYAwx8/06FjyEIsinnOfhboVGF+U41+VAqSwWiFD6lFF5AWBcdMZiXAp+xuAem9MEQMsMgmtWOlWK41DF3TEXRCAOw/ibC2Z5hP0rpb/aAmqVRymXHkEASO6bN+/asPi1dUWp+FKa1Q1cFdY5v1RS101vVypFJY06z2kryakaDtpKuZekhPBa4jiJMrb61qTko07QVb91AAU3OYj5GMkTtcv+Vj4M2cvg Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Oct 2015 02:01:07 -0000 Date: 25 Oct 2015 22:01:05 -0400 Message-ID: From: "John R Levine" To: "Christian Huitema" In-Reply-To: <0c5701d10f8f$882e4a10$988ade30$@huitema.net> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 02:01:08 -0000 > That sounds like a reasonable plan. Let's start, then. What about having > interested parties meet at a bar in Yokohama, say Monday evening, and start > drafting the first solution? I would be happy to pay the first round of > drinks, if that speeds up consensus... Sounds good to me. See you there. Be warned, consensus may be expensive. R's, John From nobody Sun Oct 25 19:31:48 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9D1B3522 for ; Sun, 25 Oct 2015 19:31:47 -0700 (PDT) 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 FjFKiPn8sxMU for ; Sun, 25 Oct 2015 19:31:44 -0700 (PDT) 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 4071C1B3525 for ; Sun, 25 Oct 2015 19:31:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20D8BBE47; Mon, 26 Oct 2015 02:31:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 TIZg3N2tv-G6; Mon, 26 Oct 2015 02:31:40 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.30.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 28FC9BE3F; Mon, 26 Oct 2015 02:31:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445826699; bh=8I3UnYdfcB1FqOYoJ4DGzFZDXPd8kmRvD9+xrM3q3Wg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=zMW3kuMtlpxd+JeEZvK0Ehz6eY7u6goqUHLpK7a3PGerwXwZ5VyGHMdkcIpLGELma natFDXQsELn01iNEHWpkawIbvofDOzjBI9p/ZqwtpKd9Aq+ueIa6KAAi/CNjoeeprl cc4YIflMJSKbtlm3Z+oI0sT9/g/WX9ToiVnpf4oA= To: John R Levine , Christian Huitema References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <562D9089.4060709@cs.tcd.ie> Date: Mon, 26 Oct 2015 02:31:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 02:31:47 -0000 On 26/10/15 02:01, John R Levine wrote: >> That sounds like a reasonable plan. Let's start, then. What about having >> interested parties meet at a bar in Yokohama, say Monday evening, and >> start >> drafting the first solution? I would be happy to pay the first round of >> drinks, if that speeds up consensus... > > Sounds good to me. See you there. Be warned, consensus may be expensive. We don't yet need to establish consensus, progress identifying issues and possible paths forward is all that's needed for now. And while that could also require N beers, that'd be an entirely reasonable cost for us all to share;-) S > > R's, > John > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From nobody Mon Oct 26 01:35:39 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723BC1B38E1 for ; Mon, 26 Oct 2015 01:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 T2UH-mnz3CkS for ; Mon, 26 Oct 2015 01:35:35 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 8826D1B38E0 for ; Mon, 26 Oct 2015 01:35:35 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9Q8ZNoP015061 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 26 Oct 2015 09:35:24 +0100 From: Simon Josefsson To: "Christian Huitema" References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151026:johnl@taugh.com::Srlxb2NuE/MclTSp:3DQl X-Hashcash: 1:22:151026:perpass@ietf.org::d9eUJRmLgDMWooAt:9q+C X-Hashcash: 1:22:151026:huitema@huitema.net::Pyl/KNT90XO/v/3o:MF5C Date: Mon, 26 Oct 2015 09:35:22 +0100 In-Reply-To: <0c5701d10f8f$882e4a10$988ade30$@huitema.net> (Christian Huitema's message of "Sun, 25 Oct 2015 18:42:09 -0700") Message-ID: <87pp02rprp.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: perpass@ietf.org, 'John Levine' Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 08:35:37 -0000 --=-=-= Content-Type: text/plain "Christian Huitema" writes: > On Saturday, October 24, 2015 3:46 PM, John Levine wrote: >> ... >> My suggestion would be to start by finding people who have experience >> in large mail systems (Ned would be a good start if he has the time), >> and then state clearly what you're trying to do. It looks like it's >> identifying and minimizing the amount of PII collected, reported (to >> downstream consumers), and logged (for internal users) for incoming >> mail. Once you've done that, it'd be quite interesting to try and see >> what gets collected, and what the tradeoffs are if you don't collect >> it or don't report or log it. > > That sounds like a reasonable plan. Let's start, then. What about having > interested parties meet at a bar in Yokohama, say Monday evening, and start > drafting the first solution? I would be happy to pay the first round of > drinks, if that speeds up consensus... Sounds like a good idea, thanks for suggesting it. I'm hoping Linus will be able to make it since I won't be there. I am concerned about taking on a too wide scope. I think it may be possible to reach closure on improving the Received header wrt privacy. I'm not against taking on the larger problems mentioned above, however I feel that it should not stand in the way of progress of fixing some identified problems of the Received header, and I worry that a wider task may not reach closure. To have a starting point for a problem statement for what I'd like to focus on, the Received header, I would propose: 1) The Problem: SMTP agents add IP addresses and timestamp information about its clients in the Received header, in a way that clients aren't able to influence. 2) Deployment Consideration: Received headers are useful for mail loop detection and debugging by humans, and must continue to serve that purpose as good possible, so as long as it doesn't violate the privacy problem identified in 1). 3) Work-together Consideration: If there are deployment of related ideas already, we want to follow and describe them as long as it solves the problem in 1) and retain the useful properties in 2). 4) Simplicity: Pick the simplest solution that meets the requirements. I'd like to get away from the focus on SMTP submissions, the privacy violation affects all SMTP relaying. Submission may be the most critical part, but there are other situations when you don't want your client's IP address or time of communication to leak. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWLeXKAAoJEIYLf7sy+BGdohEIALi4z0CnSv1N+HjmZLMtBaQp pJUcgHinWe75Dny0KC/LJ84rvjRjZsvzvmnhQFPWL8ghlu76/hgeA2XEdvDh9pa8 oWMwaru5BZY87gUNHxggOkzwZMK4pKIVJh853EcyRJof9LvTH7yzk2sjO6t/Oe63 48b9UcT+nyRK1l+7OgwlroHDFo1g4w9FYVhqZlKbJjJSWqmaGbpY+J+pfXN0YjDU HciBdXMzNwoHjgpE7Nz0wz11BtNJN7zCg6kT7xlQBkgawlQADZtZkENMHqiWoMu/ w8zxkm8uOtZAUIugiyw+acl09c43d14P3yqXyCHFleTDKAq8jbuxboBcC0Y0Nuc= =VJf5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 26 07:31:36 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABEF1B43D8 for ; Mon, 26 Oct 2015 07:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 ZCjbSeOcH40X for ; Mon, 26 Oct 2015 07:31:34 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C2A1B43D6 for ; Mon, 26 Oct 2015 07:31:33 -0700 (PDT) Received: (qmail 26195 invoked from network); 26 Oct 2015 14:31:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6652.562e3946.k1510; bh=c8lDOj2uX81DMgNagGGt+oAVDrf2uZi//PkWa2zpD98=; b=SyUOC280jbDLRfQea9dZ7EYOT3OlYxi3nEWPYYGpS88d8WcksNocIpMh1PPBiPKIBuojEPFMTekdj9PaC42pOj/k4p0XoNj1N5qUekS2AZYEgDS5V+XFZmzAfmbw6QHqAqjKbIKjtD+FGf58sJkQB8KZQ5TkP6omBaFNy+5fbsZj3YVk5lgNVtYL3SFAyobkCpXKnJSvuNJ4NjiLeiRMrAJBV1DYuGpbaP/feObXzRJv7MswMr3m5S9h3ScMlSHZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6652.562e3946.k1510; bh=c8lDOj2uX81DMgNagGGt+oAVDrf2uZi//PkWa2zpD98=; b=JeTQTW3Fg9at9M0eNaPkF1fZb9XtDnAOQjGp6a1O8DfskDRjNEFEdCAw9pjjagwWEOd/a/L3/6wqFWPSeSmQeYoerCmladfz2oVGxF/UL+lNHC60Ug3XHPdRb6dwboSCJ1MrMDqiMo51B6Wz7bkTS2J1rzbdZzPuswkm9iiW7Vt7o3mGk/PcRmHA4k/+xheIiC/WIgD7QaPmNUAfy45vTvZ/9kv2BMhxpLyj/RzbT4lRNEkfOJ+EhnJO+dC1JK5L Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Oct 2015 14:31:34 -0000 Date: 26 Oct 2015 10:31:32 -0400 Message-ID: From: "John R Levine" To: "Simon Josefsson" In-Reply-To: <87pp02rprp.fsf@latte.josefsson.org> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 14:31:35 -0000 > I am concerned about taking on a too wide scope. I think it may be > possible to reach closure on improving the Received header wrt privacy. Perhaps, although all of that stuff is also useful for identifying sources of malware, phishing, and other online evils. Assuming you agree that having someone's bank account credentials stolen is a privacy problem, this is not a simple question, and any simple answer is wrong. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Oct 26 07:39:40 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84C91B2F88 for ; Mon, 26 Oct 2015 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] 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 ZDzXnIah9-ph for ; Mon, 26 Oct 2015 07:39:37 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3713E1B2F86 for ; Mon, 26 Oct 2015 07:39:37 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CD3C4280346 for ; Mon, 26 Oct 2015 15:39:34 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id C91AF280325 for ; Mon, 26 Oct 2015 15:39:34 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id BDD5AB3805C for ; Mon, 26 Oct 2015 15:39:04 +0100 (CET) Date: Mon, 26 Oct 2015 15:39:04 +0100 From: Stephane Bortzmeyer To: perpass@ietf.org Message-ID: <20151026143904.GA15790@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux stretch/sid X-Kernel: Linux 4.2.0-1-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [perpass] "The WHOIS privacy industry would not exist if not for criminals" X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 14:39:39 -0000 Indeed, Paul Vixie is blunt (but don't worry, he does not attack only privacy but also many other things) http://www.zdnet.com/article/new-top-level-domains-a-money-grab-and-a-mistake-paul-vixie/ From nobody Mon Oct 26 08:33:02 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096901B4AA1 for ; Mon, 26 Oct 2015 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 1GP4pMJgbMO7 for ; Mon, 26 Oct 2015 08:32:59 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 F03A31B49DB for ; Mon, 26 Oct 2015 08:32:58 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9QFWqNO022103 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 26 Oct 2015 16:32:53 +0100 From: Simon Josefsson To: "John R Levine" References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151026:perpass@ietf.org::gDtcWvjdiJ0HvVtF:1nd9 X-Hashcash: 1:22:151026:johnl@taugh.com::xHqSLVXOUwwz7rZB:GSP1 Date: Mon, 26 Oct 2015 16:32:51 +0100 In-Reply-To: (John R. Levine's message of "26 Oct 2015 10:31:32 -0400") Message-ID: <87h9ldsl0c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 15:33:00 -0000 --=-=-= Content-Type: text/plain "John R Levine" writes: >> I am concerned about taking on a too wide scope. I think it may be >> possible to reach closure on improving the Received header wrt privacy. > > Perhaps, although all of that stuff is also useful for identifying > sources of malware, phishing, and other online evils. > > Assuming you agree that having someone's bank account credentials > stolen is a privacy problem, this is not a simple question, and any > simple answer is wrong. Agreed. I'm merely concerned that if we can't come up with a solution to having someone's bank account credentials stolen, we shouldn't stall attempting to resolve smaller problems that we can identify, such as a privacy violation in the Received header. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWLkejAAoJEIYLf7sy+BGdUMYH/Rl6R5HzsO83oTmFlynhYwEn mFftCrkqZnu/TKrSOTehjXi8LztSRXNx68nyGq++0f8zyjHxMBGwpW51hN3VyXnh H+WHl79n41WJRDFA3jNwqk9AwVYd/h7ekI85D3bYX/8czoIYDDH49W0hAplxeyKC nRh9FI/piZ09xvz0dHtfFl+btk2tOYQrRMvvp04/avGiAnxZIrOlbOvkOWhIJ/ax K9ruvaq13OquEPWotYb2F/7VIb1WmOylUoKdQBdJozP0TFCc9dNpQ0aSj6PAPWog 1xHlRtNx5pO0kYQ3GuTw7neFil/CgZ7YLJLpcElvFTgvQ3ZIEgnXG3ri7ppdpwk= =LTCo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 26 09:51:43 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497FA1B4EEB for ; Mon, 26 Oct 2015 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 SnjTn6Kw7n9z for ; Mon, 26 Oct 2015 09:51:37 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DF01A014B for ; Mon, 26 Oct 2015 09:51:27 -0700 (PDT) Received: (qmail 50582 invoked from network); 26 Oct 2015 16:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c595.562e5a0f.k1510; bh=8ZYj0QlyNdZPZCOTPQHecOjDHSXV+t1SU4aWSZjhvaE=; b=j5mMqFYeqChnL/A63Z30qTY9+5WdBt6PNmwamPqS9lp+ncP3+9mZNq/zGIfOvEBNLsQ5VMxDgYnJj/tGcSojGk6uZ44Qn0nn+SdpISFnkMPeKxhHOpI2LB4fxxtvJh+SLF2wze9X4V7N47D1s+f3dyeGZuysacczA+RJWZi9DEy+WpK5I+SjOypOPPe3HKRIc2Cv4VOO3wLZfB8JpixkQ5XyXP5xwZnzLNsAu1XI2MIsYWSRc0oVcySAiOvD89rW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c595.562e5a0f.k1510; bh=8ZYj0QlyNdZPZCOTPQHecOjDHSXV+t1SU4aWSZjhvaE=; b=Qjo+UENLE5dZHx6N/spWEDox9U7buTNtDASZ+RImNh5m0/oK/4ztSGH7gLB8gFzUn0YPdZoZ+deEWlmOogqJLGodmm9R1vu57KBMc/zxgemFFKdlU5xcUlH7m2g/pqF69jA+Bk76x8TTLkcENDLbG1xYnD1bH7kqR3S2wdQrRKjRplNwkFWWm8B8RefVxEJxHZ9rw8jxpPA5I0ikBYIyqK1aKYThnMKbs0JPRPoxbfe08LDrIh0+GQIXRC7wda3w Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Oct 2015 16:51:27 -0000 Date: 26 Oct 2015 12:51:25 -0400 Message-ID: From: "John R Levine" To: "Simon Josefsson" In-Reply-To: <87h9ldsl0c.fsf@latte.josefsson.org> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> <87h9ldsl0c.fsf@latte.josefsson.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 16:51:38 -0000 >> stolen is a privacy problem, this is not a simple question, and any >> simple answer is wrong. > > Agreed. I'm merely concerned that if we can't come up with a solution > to having someone's bank account credentials stolen, we shouldn't stall > attempting to resolve smaller problems that we can identify, such as a > privacy violation in the Received header. I hope you agree with the part where I said that any simple answer is wrong. On my system, most real mail comes from the three gorillas, from ISPs such as T-W and Comcast, and from local schools or businesses. Since we are weenies, a certain amount comes through mailing lists. In every one of those cases, the IP address in the received header is the address of the server at the mail system, the institution, or the mailing list. It tells you nothing you didn't already know if you looked at the bounce address in the SMTP envelope, or the From: or List-ID: in the message body. The spam mostly comes from compromised servers and botnets, where the IP tells you who the legitmate operator is (not the botnet operator) and indirectly where to send abuse reports. Since that mail isn't sent by the party legitimately associated with the IP, and the only place the mail goes is back to the operator in a spam report, it's hard to see any privacy issues there, either. If you were talking about Received headers added in submission rather than SMTP, there are plausible PII issues, but there you will find that as often than not the sending MTA already obscures the location of the user, particularly when messages are submitted via webmail. On the other hand, for abuse management it's essential that it be there in some form so the sending system can figure out which of its users is misbehaving or has been compromised. So I think it is fine to look at the issues and see where we might make improvements, but it is a bad idea to rush to naive changes that don't address real privacy issues but do cause real problems for operations and security. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Oct 27 07:57:15 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E231A8BBD for ; Tue, 27 Oct 2015 07:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 O--q3Wwzm7bI for ; Tue, 27 Oct 2015 07:57:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5F331A8BB3 for ; Tue, 27 Oct 2015 07:57:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSED70TPN40017MJ@mauve.mrochek.com> for perpass@ietf.org; Tue, 27 Oct 2015 07:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1445957530; bh=m6YtYSyD6XLB81nRCkaxNZy1GexSyqPphbEqIoM8z8Y=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=fNIrunbNdD491JxxWpqhYfPIePKq3T0Jx+2DU6e2ECBcQ040GSW/2f9ADy+aNOc6n pik1L6wzKY7ZADV1I13NeXHCOBSZiTTuk8TXXkIJGzdAtNf48ii8wHY09yoH6Y5yIS BVhX71wAKx5HLLpDqPyz/0WbFH9YR103LbP344zo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSBQV60EIO00HE89@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Tue, 27 Oct 2015 07:52:07 -0700 (PDT) From: ned+perpass@mrochek.com Message-id: <01PSED6Z1V9S00HE89@mauve.mrochek.com> Date: Tue, 27 Oct 2015 07:36:33 -0700 (PDT) In-reply-to: "Your message dated Mon, 26 Oct 2015 12:51:25 -0400" References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> <87h9ldsl0c.fsf@latte.josefsson.org> To: John R Levine Archived-At: Cc: Simon Josefsson , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:57:13 -0000 > >> stolen is a privacy problem, this is not a simple question, and any > >> simple answer is wrong. > > > > Agreed. I'm merely concerned that if we can't come up with a solution > > to having someone's bank account credentials stolen, we shouldn't stall > > attempting to resolve smaller problems that we can identify, such as a > > privacy violation in the Received header. > I hope you agree with the part where I said that any simple answer is > wrong. I certainly do. > On my system, most real mail comes from the three gorillas, from ISPs such > as T-W and Comcast, and from local schools or businesses. Since we are > weenies, a certain amount comes through mailing lists. In every one of > those cases, the IP address in the received header is the address of the > server at the mail system, the institution, or the mailing list. It tells > you nothing you didn't already know if you looked at the bounce address in > the SMTP envelope, or the From: or List-ID: in the message body. As I understand it the argument here is that these IP addresses may expose internal network topology - IMO even if a legitimate concern not a personal privacy issue and hence out of scope - or perhaps might be usable in some sort of correlation attack aimed at determining the user's general location. The latter, even if it's in the remote realm of possibility, is not something that's going to come close to passing cost/benefit muster. > The spam mostly comes from compromised servers and botnets, where the IP > tells you who the legitmate operator is (not the botnet operator) and > indirectly where to send abuse reports. Since that mail isn't sent by the > party legitimately associated with the IP, and the only place the mail > goes is back to the operator in a spam report, it's hard to see any > privacy issues there, either. Agreed. > If you were talking about Received headers added in submission rather than > SMTP, there are plausible PII issues, but there you will find that as > often than not the sending MTA already obscures the location of the user, > particularly when messages are submitted via webmail. On the other hand, > for abuse management it's essential that it be there in some form so the > sending system can figure out which of its users is misbehaving or has > been compromised. I actually did a little checking of this the other day, and found the following: Gmail: webmail does not disclose originating client IP, apparently using invalid Received: field to avoid doing so submit discloses originating IP Yahoo: Neither webmail nor submit disclose originating IP, some Received: fields are invalid but this looks like an unrelated issue Outlook: Neither webmail nor submit disclose originating IP, valid Received: fields AOL: webmail discloses originating client IP, can't test submit due to AOL brokenness GMX: Both webmail and submit dislose originating client IP I'm fairly sure that in the past there were more cases where original client IPs were exposed. So what we're seeing is an industry that looks to already on the way to addressing this concern, albeit in a fairly haphazard manner. > So I think it is fine to look at the issues and see where we might make > improvements, but it is a bad idea to rush to naive changes that don't > address real privacy issues but do cause real problems for operations and > security. Agreed again. Ned From nobody Tue Oct 27 08:16:50 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06821A9059 for ; Tue, 27 Oct 2015 08:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 L-irAUwS4pbp for ; Tue, 27 Oct 2015 08:16:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9421A9055 for ; Tue, 27 Oct 2015 08:16:47 -0700 (PDT) Received: (qmail 78223 invoked from network); 27 Oct 2015 15:16:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1318e.562f955f.k1510; bh=Pgaxa3oKA2sh51vflCX5Dq49Zevy0aSi0CtlDdEW6mE=; b=iTKr7hjSlDrTW2XiWDo+8ZixM4pkL8Dmao9LqilNJaeNsXsdRARkHxxqAyBRLoW5rYPCm/4j87O72cWPP8MevBm6sXVkm5uCprYPVciKdj8f5JeoNLtol7nKAGjJLuWQYTOffnmdBNSrFVtKF7/AqEFFQh9JMt/n/LuIEpACHFbF2ANpOOSLk4C+rZUfYb3DOot+7BcxbKw7oBOv08LWy0MRiNpaTv1jA+0sk5B5ydlDfL67zNAeJTwtS0+VnIcj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1318e.562f955f.k1510; bh=Pgaxa3oKA2sh51vflCX5Dq49Zevy0aSi0CtlDdEW6mE=; b=aR0oy54QRSCSut1Mo8gniBRYJSLGuHzuU+F2oxg2Hc3Vm08rHB4wvbJfaKWm5JCxyMCR86m6YqSMwavwsm64BCozzbxq+2zVW7MYBNCIBHsg5BoyuUUTad21jyOtpVlDz8+u0rFKPtlfBMyFjJNLVhAvvGeUpVtwjHt5kLOtkoH1a17PSI/b0v9PKVwgPFHI2FoDB9eRu2W8fGWooPJH6bpk8yDdA96QG2qeGNZLGOU2hUACueIFnzPrlsva2mMW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 27 Oct 2015 15:16:47 -0000 Date: 27 Oct 2015 11:16:45 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01PSED6Z1V9S00HE89@mauve.mrochek.com> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> <87h9ldsl0c.fsf@latte.josefsson.org> <01PSED6Z1V9S00HE89@mauve.mrochek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: Simon Josefsson , perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 15:16:48 -0000 > As I understand it the argument here is that these IP addresses may expose > internal network topology - Actually, at this point I don't understand what the IP address is supposed to expose beyond the location of a server which generally tells you nothing new about the location of the user. Perhaps Simon can clarify. > AOL: webmail discloses originating client IP, can't test submit due to > AOL brokenness I managed to configure Pine to send AOL mail, it logs the IP in both the Received: and X-AOL-IP headers. But it uses TLS both on submit and outbound. >> So I think it is fine to look at the issues and see where we might make >> improvements, but it is a bad idea to rush to naive changes that don't >> address real privacy issues but do cause real problems for operations and >> security. > > Agreed again. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Oct 27 18:24:44 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0EE1B3D1E for ; Tue, 27 Oct 2015 18:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CIGEOOc9N0_Z for ; Tue, 27 Oct 2015 18:24:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 309B61B3D1C for ; Tue, 27 Oct 2015 18:24:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSEZ3YUHK000NWRH@mauve.mrochek.com> for perpass@ietf.org; Tue, 27 Oct 2015 18:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1445995178; bh=ad0Vfu7mjbAiugA2r8Wf64nUspzJwnBevo/JHpdPZ5Y=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=DBj2tABWdgBPTfNQZz/U0hzAba66zLFdKKxzWs3fArbAc+kFqMOVRPBpEHtAI15zp q7Ip6RL71QOZzgphXSPnHa3Yv4iotYToG16GzEgXN2mzNkqoTbEvKBV5hVz6jMXB0X fKR5Qx4i3CLjo1TWBD7MOAHbhxTOI9C8q2m9DUYE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSEDAO0O8000HE89@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Tue, 27 Oct 2015 18:19:35 -0700 (PDT) From: ned+perpass@mrochek.com Message-id: <01PSEZ3X9I8000HE89@mauve.mrochek.com> Date: Tue, 27 Oct 2015 09:31:36 -0700 (PDT) In-reply-to: "Your message dated Mon, 26 Oct 2015 09:35:22 +0100" <87pp02rprp.fsf@latte.josefsson.org> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> To: Simon Josefsson Archived-At: Cc: 'John Levine' , perpass@ietf.org, Christian Huitema Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 01:24:42 -0000 > "Christian Huitema" writes: > > On Saturday, October 24, 2015 3:46 PM, John Levine wrote: > >> ... > >> My suggestion would be to start by finding people who have experience > >> in large mail systems (Ned would be a good start if he has the time), > >> and then state clearly what you're trying to do. It looks like it's > >> identifying and minimizing the amount of PII collected, reported (to > >> downstream consumers), and logged (for internal users) for incoming > >> mail. Once you've done that, it'd be quite interesting to try and see > >> what gets collected, and what the tradeoffs are if you don't collect > >> it or don't report or log it. > > > > That sounds like a reasonable plan. Let's start, then. What about having > > interested parties meet at a bar in Yokohama, say Monday evening, and start > > drafting the first solution? I would be happy to pay the first round of > > drinks, if that speeds up consensus... > Sounds like a good idea, thanks for suggesting it. I'm hoping Linus > will be able to make it since I won't be there. > I am concerned about taking on a too wide scope. There are possible issues either way. On the one hand, a wider scope has the potential of getting too wide and losing focus on what can be accomplished. But on the other hand, Received: fields do not exist in isolation, and if you don't understand their context you're not going to be able to craft viable privacy considerations recommendations for them. > I think it may be > possible to reach closure on improving the Received header wrt privacy. > I'm not against taking on the larger problems mentioned above, however I > feel that it should not stand in the way of progress of fixing some > identified problems of the Received header, and I worry that a wider > task may not reach closure. Not to put too fine a point on it, but you're a ways away from pinning down the actual problem you want to solve here. I already pointed out that Received: fields are, to a large extent, irrelevant as far as state actors with access to transaction logs are concerned. This leaves a rather different set of privacy concerns than the ones cited in the current draft. There's also the issue of submit versus relay. As far as I'm concerned you have yet to elaborate a meaningful privacy case for routine suppression of information in Received: fields generated by relay operations. > To have a starting point for a problem statement for what I'd like to > focus on, the Received header, I would propose: > 1) The Problem: SMTP agents add IP addresses and timestamp information > about its clients in the Received header, in a way that clients > aren't able to influence. First, you continue to fail to distinguish between SMTP (relay) and SUBMIT (submission) here. These are separate protocols for a lot of very good reasons, and you need to deal with them separately. Second, the inability of of clients to influence the generation of Received: fields is actually a feature, not a bug. And unless you are prepared to substantiate a claim based on actual evidence of widely deployed email clients acting in the interest of their user's privacy, it's almost certainly going to be a privacy win as well. Or, to put this another way, which do you think is easier to change: The behavior of thousands of different clients currently in the hands of billions of users, or the behavior of a handful of service providers? > 2) Deployment Consideration: Received headers are useful for mail loop > detection and debugging by humans, and must continue to serve that > purpose as good possible, so as long as it doesn't violate the > privacy problem identified in 1). This list is far from complete - the obvious omission is the use of Received: fields for spam checks. Another is identifying sources of delays - transaction logs are better for this but they only work within an administrative domain. It's also the case that nobody - including all the email exports in the IETF - are going to be able to create anything like a complete list of the uses of Received: header fields out there. Like it or not, this is what happens when something has been widely deployed for over 25 years. And despite the huge variability of the Received: fields that are generated, it's entirely possible to write robust processing software for them. (The assorted tricks for doing this are well known in the community.) > 3) Work-together Consideration: If there are deployment of related ideas > already, we want to follow and describe them as long as it solves the > problem in 1) and retain the useful properties in 2). The problem you're going to run into here is that ISPs/MSPs are generally not very sharing about their plans. And folks like me that work with various different ISPs /MSPs can't talk about the specifics of what's going on due to nondisclosure arrangements. > 4) Simplicity: Pick the simplest solution that meets the requirements. Extensibility often trumps simplicity in the email space. It certainly does/did in the design of Received: fields, and that's another thing that's going to have to be dealt with by any specification that's written. > I'd like to get away from the focus on SMTP submissions, the privacy > violation affects all SMTP relaying. You *really* need to substantiante this claim. > Submission may be the most > critical part, but there are other situations when you don't want your > client's IP address or time of communication to leak. Before I get into the timestamp issue, I want to reiterate John's excellent point: You know how crypto people feel when someone shows up with a wonderful new crypto scheme? And then when the someone says well, just tell me what's wrong with it? Mail is a lot like that. It's much more complex and subtle than it appears, even to people who've used it casually for a long time. There was a time when email was truly a heterogeneous store and forward system spanning many protocols, message formats, gateways, and lots of other junk. Messages were often delayed, sometimes by substantial amounts of time, and routinely transited multiple administrative domains before being delivered. And there were probably some things that could be discovered by looking at Received: field timestamps at that point. Those days are long gone. These days the majority of email messages are handled in their entirely by a small number of large service providers. Of the remainder, most are intra-domain business email handled by enterprise mail systems like Microsoft Exchange. Tied to that is the inter-domain email from those enterprise email systems. The vast majority of messages now only transit one or two administrative domains. All of these systems employ sophisticated queuing systems and storage technologies and are highly optimized to transfer massive amounts of email with exceptionally low latency. (Low latency is not just a user experience win, it's also a win in terms of not needing as much queue storage.) And by massive I mean tens of thousands of messages a second or more, delivering to millions of users (or more), scattered across data centers all over the world. And even the tiny fraction of systems that are left are typically using high quality open source like Exim, Postfix, or sendmail. These packages also offer very good perfomance. The result is that typical email delivery times have been driven down into the tens of seconds range; a couple of minutes at most. And if there's more of a delay, it's usually at the point of final delivery, which has no privacy implications that I can see. And when the times are higher than this, it's usually deliberate. For example, I noticed when I did the testing I reported in a previous message that Yahoo seems to consistently insert a three minute delay. (It's probably part of their spam checks.) And since the Received: fields are, modulo clock skew (now usually a nonissue due to the widespread use of NTP) and coding errors, going to be bracketed by the Date: field and the delivery timestamp, the amount of information conveyed by the timestamps in normal operation is quite low, especially in terms of privacy. (Their utility arises when things aren't normal, e.g., when you want to know the reason for an abnormal delay or you use mistakes in their construction as a spam indicator.) The possible exception to this is the time zone. I'm having trouble coming up with a scenario where the time zone of the Received: field provides more insight than the one in the Date: field, but I suppose it's possible. But if there's actually reason to care about this it can be dealt with simply by saying "use UTC". Now, this begs the question of what, if anything, to do about the Date: field. It's required, and if the client doesn't insert it the submit server will. (Or the message may be rejected as spam. And sending out bogus Date: field values is *very* likely to trigger spam detectors.) This makes it impossible to use regular email to send messages with an indeterminate submission time, but with all due respect, that's not something the regular email service is designed to provide, and given the low standard deviation of end-to-end message tranfer with the use of extensions like FUTURERELEASE, it's not something the regular email service can provide in any meaningful way anyhow. If you want to build such a service on top of regular email, it would have to be done as some sort of remailer. Which is entirely possible to do, but is entirely out of scope of what's being proposed here. tl;dr Unless I'm missing something, timestamps are not a privacy concern. Ned From nobody Thu Oct 29 00:20:20 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75B41A1BCA for ; Thu, 29 Oct 2015 00:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 FMPWYZwUyCFw for ; Thu, 29 Oct 2015 00:20:17 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 28B991A1A02 for ; Thu, 29 Oct 2015 00:20:16 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9T7KE1P002537 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Oct 2015 08:20:14 +0100 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t9T7KBH7000437 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Oct 2015 07:20:14 GMT X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for perpass@ietf.org; Thu, 29 Oct 2015 08:20:11 +0100 From: Linus Nordberg To: perpass@ietf.org References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> Date: Thu, 29 Oct 2015 08:20:08 +0100 In-Reply-To: <87pp02rprp.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 26 Oct 2015 09:35:22 +0100") Message-ID: <87si4uw387.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aPyTke08 - 0a9287340fea - 20151029 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordberg.se) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 07:20:18 -0000 Simon Josefsson wrote Mon, 26 Oct 2015 09:35:22 +0100: | "Christian Huitema" writes: [...] | > That sounds like a reasonable plan. Let's start, then. What about having | > interested parties meet at a bar in Yokohama, say Monday evening, and start | > drafting the first solution? I would be happy to pay the first round of | > drinks, if that speeds up consensus... | | Sounds like a good idea, thanks for suggesting it. I'm hoping Linus | will be able to make it since I won't be there. Meeting in person would be valuable. Monday is the only night I'm unavailable though. I'd like to suggest Tuesday but I realise that this might be a futile attempt. If you all go for Monday, I'll do my best to catch up during the week. Thanks, Linus From nobody Thu Oct 29 14:57:38 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334EF1B321F for ; Thu, 29 Oct 2015 14:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 j62LjVy95AwX for ; Thu, 29 Oct 2015 14:57:36 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063591B321E for ; Thu, 29 Oct 2015 14:57:35 -0700 (PDT) Received: (qmail 56623 invoked from network); 29 Oct 2015 21:57:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dd2e.5632964f.k1510; bh=zibm2zkI6kU/0ifGv6ypBXECtMzuoD/aqrAeB6xIcQw=; b=XE2J2bKZvowizV20hskvbk6nZRNFvpzELjSsDPcQZxxHBoIBnTXqlP3Xi5abNCbLlEupcuvRp/tYRanj3cD6WguW3zVrIHBr2PI39cX+x8qYgL2jvxUM9Y3vI1wIhnzYJbrqt9Hi519MZsgAbmFXfZqUV2TPGeJOhmWOHKhTzzITLNlLtdfaGML0hyml1SaYKko12HaCKHsOXsuaQ3rz1kF017y3dcAnQJUFF9B33uQi5jnky1OGTsUU2sq7hpNI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=dd2e.5632964f.k1510; bh=zibm2zkI6kU/0ifGv6ypBXECtMzuoD/aqrAeB6xIcQw=; b=aUVl9iFDHvMVVJZr6nznbMVSwcO2LPBQRx6cl3YrNnpOhKW1Y37wggemCpPdTHt6BHiWheSYnDjkr3HA9E9K8d1JZ10E0xhNJxzXYH/3wZPpx8d0OeV5lB3hkwvuVgaRudtLe0/z0+7h/SOJQkKSWOwYO6MLWYNaDP5HVcxCs5RpsoXUHLSETqHssSyh15jrzLkRaN84zA4N9UpEGWOFYnjBet6y+pwBxWT1r6fEnxMyIV77VBGyaCY2DphrjXV5 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 Oct 2015 21:57:34 -0000 Date: 30 Oct 2015 06:57:31 +0900 Message-ID: From: "John R Levine" To: "Linus Nordberg" In-Reply-To: <87wpu6w3eu.fsf@nordberg.se> References: <871tcl3f03.fsf@latte.josefsson.org> <20151024224621.15562.qmail@ary.lan> <0c5701d10f8f$882e4a10$988ade30$@huitema.net> <87pp02rprp.fsf@latte.josefsson.org> <87wpu6w3eu.fsf@nordberg.se> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] draft-josefsson-email-received-privacy X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 21:57:37 -0000 > | > interested parties meet at a bar in Yokohama, say Monday evening, and start > Meeting in person would be valuable. Monday is the only night I'm > unavailable though. Any evening Mon-Thu is OK for me. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.