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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 20 December 2018 00: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 6C761130DD8 for <spasm@ietfa.amsl.com>; Wed, 19 Dec 2018 16:17:32 -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 M4Fu7XFVKwKq for <spasm@ietfa.amsl.com>; Wed, 19 Dec 2018 16:17:30 -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 BABF4129AB8 for <spasm@ietf.org>; Wed, 19 Dec 2018 16:17:30 -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 32F24F99A for <spasm@ietf.org>; Wed, 19 Dec 2018 19:17:28 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 5C9BF2036B; Wed, 19 Dec 2018 19:09:26 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: LAMPS WG <spasm@ietf.org>
In-Reply-To: <DC188C55-6FDE-4E64-9151-54815E96B50B@vigilsec.com>
References: <DC188C55-6FDE-4E64-9151-54815E96B50B@vigilsec.com>
Date: Wed, 19 Dec 2018 19:09:23 -0500
Message-ID: <87bm5hxdn0.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/pFh0n367YVtCULqafxsRLtdczao>
Subject: Re: [lamps] Proposed 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: Thu, 20 Dec 2018 00:17:32 -0000

On Mon 2018-11-05 22:34:33 -0500, Russ Housley wrote:
> In the session earlier today, there was interest in adding a header
> protection work item to the agenda.  Alexey talked about this in
> Montreal, and he posted a draft a few weeks ago:
> draft-melnikov-lamps-header-protection.  Several people said that they
> would implement a solution if the WG produced an RFC on this topic.

This seemed to be acceptable to folks in the room, and i've seen mainly
agreement on the list to adjust the charter in this way.

I propose the following change to the charter so that we can move
forward with adoption of this work:


--- a/lamps-charter.txt
+++ b/lamps-charter.txt
@@ -58,6 +58,14 @@ certificate for a trust anchor, which is often called a Root
 Certification Authority (CA) certificate, to identify the next
 public key that will be used by the trust anchor.
 
+7. Specify a mechanism for the cryptographic protection of e-mail
+headers.  Most current implementations protect only the body of the
+message, which leaves significant room for attacks against
+otherwise-protected messages.  Cryptographic protection (both for
+signatures and encryption) which applies to the headers in conjunction
+with the message body are necessary to close significant security and
+usability gaps in cryptographically-protected electronic mail.
+
 In addition, the LAMPS WG may investigate other updates to documents
 produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
 any of these potential work items without rechartering.



happy to hear any concerns or suggestions for improvement!

Regards,

        --dkg