Re: [lamps] Draft addition of header protection to the LAMPS charter

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 11 January 2019 18:17 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEE127AC2 for <spasm@ietfa.amsl.com>; Fri, 11 Jan 2019 10:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 0jt4tyHyqIc4 for <spasm@ietfa.amsl.com>; Fri, 11 Jan 2019 10:17:54 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EE21277CC for <spasm@ietf.org>; Fri, 11 Jan 2019 10:17:54 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 20800F99A; Fri, 11 Jan 2019 13:17:52 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 120B621274; Fri, 11 Jan 2019 13:17:50 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Russ Housley <housley@vigilsec.com>, LAMPS WG <spasm@ietf.org>
In-Reply-To: <BB06AD4F-5F6F-4986-9ADC-04B44E34D0DE@vigilsec.com>
References: <DC188C55-6FDE-4E64-9151-54815E96B50B@vigilsec.com> <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <BB06AD4F-5F6F-4986-9ADC-04B44E34D0DE@vigilsec.com>
Date: Fri, 11 Jan 2019 13:17:49 -0500
Message-ID: <87imyvcb3m.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/PvgNYoig1u0C0vC92Meem7KJh1A>
Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2019 18:17:55 -0000

On Thu 2019-01-10 13:21:45 -0500, Russ Housley wrote:
> We seem to have moved on to other topics.  Does that mean we have settled on the text we want the IESG to add to the charter?
>
>    7. Cryptographic protection of electronic mail headers: A
>    mechanism to address this in S/MIME has been standardized
>    in RFC 5751. The WG shall define solutions (both for
>    signature and encryption) to close significant privacy,
>    security and usability gaps in cryptographically-protected
>    electronic mail.

I like the push and am happy to move forward with a charter that
includes e-mail header protection.  But I'm a bit concerned about this
text for mainly stylistic reasons -- the above text only mentions
headers explicitly in the part before the colon, and it doesn't match
the form of the other bullet points that are currently in the charter
(no other bullet point starts with a set-off title like this; no other
bullet point says "The WG shall…", etc).

I propose the following revision that matches the style of the existing
charter elements (using Bernie's notation, i'll call this DKG-2):

--- BEGIN DKG-2 ---

7. Update the specification for the cryptographic protection of e-mail
headers - both for signatures and encryption - to improve the
implementation situation with respect to privacy, security and usability
in cryptographically-protected electronic mail.  Most current
implementations of cryptographically-protected electronic mail protect
only the body of the message, which leaves significant room for attacks
against otherwise-protected messages.

--- END DKG-2 ---

if the group prefers the text Russ cited, i can live with it too.  i'd
like to move on to the actual specification work.

Regards,

        --dkg