Re: Proposed Proposed Statement on e-mail encryption at the IETF

"John Levine" <johnl@taugh.com> Tue, 02 June 2015 16:48 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E5D1B2BE4 for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 09:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zPdBP1id5eHd for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 09:48:12 -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 9E5591B2BE2 for <ietf@ietf.org>; Tue, 2 Jun 2015 09:48:12 -0700 (PDT)
Received: (qmail 58067 invoked from network); 2 Jun 2015 16:48:19 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Jun 2015 16:48:19 -0000
Date: Tue, 02 Jun 2015 16:47:49 -0000
Message-ID: <20150602164749.35037.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: ietf@ietf.org
Subject: Re: Proposed Proposed Statement on e-mail encryption at the IETF
In-Reply-To: <DD88F4E4-6BBA-4610-BB49-3158A26DF55B@hopcount.ca>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/i1V_hSREGQiAeFZm9bdF4XcHFjo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 16:48:14 -0000

>Mail to public mailing lists can already be signed (like this one is). It'd be nice if mailman didn't MITM the signed content, so that the signature can be validated.

The last time I checked, Mailman is pretty good about wrapping MIME parts when it
adds a header or footer, so if you send multipart/signed, that will be part of
the resulting message.

I also found that the way MUAs treat partially signed mail ranges from
mediocre (Thunderbird) to bad (Outlook and Alpine) to nonexistent (all
of the usual web mail.)

But I have to ask, what problem are we trying to solve?  The issues
here are roughly the same as the ones that came up when we were
designing DKIM, and some people insisted that mailing lists had to
preserve DKIM signatures.  (This was before last year's DMARC fiasco.)

As far as I could tell, the threat model was that bad guys were
flooding lists with forged mail, list operators were asleep at the
switch and did nothing about it, so recipients had to do retroactive
spam filtering.  While everyone agreed this model was silly, nobody
could come up with anything else other than to insist that it was
obvious which to me, at least, it was and is not.

There is a fairly popular list manager called Sympa which can
apparently do end to end S/MIME.  Contributors can provide an S/MIME
key when they sign up, it can verify signatures on the way in and
derypt mail encrypted to the list's key, then re-encrypt mail to each
recipient's key.  I say apparently because it's in the code and the
manual, but I can't find anyone who actually uses it so I don't know
if it works.

I wouldn't suggest the IETF switch from Mailman to Sympa, but if
people are interested in some code sprintage, they might hack on
Mailman to provide a way for subscribers to register S/MIME and PGP
keys, check signatures on the way in and annotate the mail to say what
it found.  We already do DKIM signatures on the way out which should
be adequate to protect the annotations.  Then once we see how that
works, we might add features to reject or at least make insulting
comments on unsigned mail from people who've provided keys.

R's,
John