Re: [perpass] Another mail-related proposal

Jim Fenton <fenton@bluepopcorn.net> Sun, 18 August 2013 16:34 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E17111E8135 for <perpass@ietfa.amsl.com>; Sun, 18 Aug 2013 09:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek8cwMBLYnQT for <perpass@ietfa.amsl.com>; Sun, 18 Aug 2013 09:33:59 -0700 (PDT)
Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 683F211E8125 for <perpass@ietf.org>; Sun, 18 Aug 2013 09:33:59 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7IGXrSJ005457; Sun, 18 Aug 2013 09:33:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376843636; bh=mygwKvp770ZTBhYnMMK3zMwIzit1SGeg77qZhI1S0RE=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=N115A3KxOxvwhb0ksXsyEH+vjbNumLMicNr/tjx7K8QeyD768uC/1PX7FiYCgHm0c BG7IaM2FEp9sP5+DvssPpmKDJrwUUbrZ9lPWliSIHer1hLWx6A6liyL88r+wg/V++J DWFwFHGsvAQwhMJSfj7fBB6B88+qUd+n5zkkYams=
Message-ID: <5210F771.9090600@bluepopcorn.net>
Date: Sun, 18 Aug 2013 09:33:53 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Randy Bush <randy@psg.com>
References: <520FE08B.80005@bluepopcorn.net> <alpine.LFD.2.10.1308171723400.14413@bofh.nohats.ca> <5210643F.8030709@bluepopcorn.net> <m2bo4vcuup.wl%randy@psg.com>
In-Reply-To: <m2bo4vcuup.wl%randy@psg.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org
Subject: Re: [perpass] Another mail-related proposal
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Aug 2013 16:34:00 -0000

On 08/18/2013 12:37 AM, Randy Bush wrote:
>> I'm having more trouble coming up with use cases where I'd want to
>> reject messages that don't use PGP or S/MIME.
> visualize a future world where e2e message privacy is the default.  in
> that world, some parties could view an unencrypted message as an attack.

I'm curious what sort of attack you're envisioning here: what are the
motives of the attacker, and what is the harm to the attacked party? I
have one idea -- a bit of a stretch IMO -- see below. But I wonder if
there are others.

>
>> The originator of a message is in a better position to decide whether
>> it contains sensitive information. And as the receiver you can't
>> generally protect against the message traversing the network in the
>> clear -- SMTP is often more than one hop and an earlier hop (or
>> submission) could have been in the clear, even if you did require TLS
>> for the last hop.
> i do what is in my power to do.  just because there might be a weakness
> in the system n hops away does not mean i should indulge in weakness.

Here's a possible attack: someone sends you a message in the clear
falsely quoting you as conspiring criminally with them or some third
party. This might be part of a blackmail scheme, or simply from someone
who doesn't like you, analogous to the problems Brian Krebs has had with
some Russians
(http://www.onthemedia.org/2013/aug/02/russia-love-and-heroin/ ). The
attacker's intent would be to encourage some party doing passive
monitoring to subject you to additional (perhaps invasive) scrutiny.

But since email isn't necessarily directly from originating to recipient
MTA, your policy about requiring encrypted email doesn't necessarily
succeed. The attacker sends the message to the intermediate MTA in the
clear, the monitoring takes place, and your policy had no effect.

We're going down a very speculative path because we're nowhere near e2e
message privacy being the default. Personally, I'd rather focus on
improvements that we can make given the current situation, not some
possible future state of affairs.

-Jim