IETF Logo Mail Archive

[perpass] Another mail-related proposal

Jim Fenton <fenton@bluepopcorn.net> Sat, 17 August 2013 20:43 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 C0DE911E816D for <perpass@ietfa.amsl.com>; Sat, 17 Aug 2013 13:43:57 -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 QLz+ZBSw-kRm for <perpass@ietfa.amsl.com>; Sat, 17 Aug 2013 13:43:56 -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 B673D11E8156 for <perpass@ietf.org>; Sat, 17 Aug 2013 13:43:56 -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 r7HKhtl7000871 for <perpass@ietf.org>; Sat, 17 Aug 2013 13:43:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376772235; bh=0hpcsLWQ94axVf9EV0Bs7svbQFJ7j4zFcOL3pQ7kJoQ=; h=Date:From:To:Subject:From; b=ka5IOjCg2LahbTw1EI+1WK9zp4+5KbdowILfcD3kir5RmHnKfIk4NhN/els3cLBfj s7PKon4vadYxhuIOtrLV7/T8Ey7c9ls/PE7DhvSTLFwsxNwFVB0hIbhSTeBNXngcKO mR4hwTlrti8pv2H7W0DeF9m+yR9T5tgYg0bXLR1A=
Message-ID: <520FE08B.80005@bluepopcorn.net>
Date: Sat, 17 Aug 2013 13:43:55 -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: perpass@ietf.org
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [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: Sat, 17 Aug 2013 20:43:57 -0000

When I read the purpose of this mailing list, an idea that had been in
the back of my brain came to mind, and I wonder if it fits with that
purpose. To Dave Crocker's point, I'm not sure whether you'd
characterize this as a privacy enhancement or confidentiality
enhancement, but here goes:

SMTP is biased in favor of delivering the message if at all possible.
While some MTAs use TLS to communicate, many do not, so TLS is
negotiated by mutual consent, but if that doesn't work out the message
is sent in the clear.  So if TLS breaks for some reason, people
frequently don't notice.

There might be times when I'm interested in sending a message that I'd
rather not be in the clear on the wire, and I'd rather that the message
bounce rather than be sent in the clear. How about an SMTP option that
allows a sender to specify whether the message transmission requires (1)
TLS and (2) that the receiving MTA also enforce this option. It could
also specify whether the recipient MTA is required to have a certificate
trusted (e.g., via trust chain) by the sending MTA, or whether any TLS
negotiation (e.g., self-signed cert) is OK.

This of course doesn't address a threat model that includes the MTAs
themselves, since they have the message in the clear.

So,

- Is this proposal the sort of thing this list is for?
- If so, any thoughts on the proposal?

-Jim

v2.23.0 | Report a Bug | By Email