Re: [lamps] New Version Notification for draft-luck-lamps-pep-header-protection-01.txt (fwd)

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 01 April 2019 04:02 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 6552F12004A for <spasm@ietfa.amsl.com>; Sun, 31 Mar 2019 21:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=s32fy43t; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=KATXmT3e
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 TkXzzqXTKNJ9 for <spasm@ietfa.amsl.com>; Sun, 31 Mar 2019 21:02:29 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F1612004F for <spasm@ietf.org>; Sun, 31 Mar 2019 21:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554091347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=buTF8sB+l4AAPuaYD3t6SNfNZ9b8XQLpfDZsdg1hFAc=; b=s32fy43tlW6HeiJAwMxh75hcm9IoDiRdo08blIV9dw2oUusAwdOB76BC 2v0wlnKi7wiUCFnXoYHq9r12ofr/Cg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554091347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=buTF8sB+l4AAPuaYD3t6SNfNZ9b8XQLpfDZsdg1hFAc=; b=KATXmT3eTUUCuSy+ZA5I6y+G1RJeQCIMkH+VXC8q4EMGaKxQOmKROAg1 itmY9LsaKfDQUbPfAinpX/FJh3dEai1b1ask+Pcs91ZdRmNUab/iFZ7Xb3 nQEc2ITsJpvo0V1yLQPpqIzthLCnozhSfMGzgdx7hIUlKXrj6xj+pLZalv G1m3DYMNSA9vgLbqgvKX9+hNeAca72WqokkA3Zz4L67O/PqGH6mY3pmaIt ModYRN9GCGJWrShfw3pwaH64XoWd2kk6+70xxHlb2y4Ot5DqXzljL+xG3H Q3ZCSgkJSoTl1XHjmEzhC0appN9IR5X2mi3UNYI10uh+TqY0GaGgIA==
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (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 6C713F9A5; Mon, 1 Apr 2019 00:02:26 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id EDB9021091; Sun, 31 Mar 2019 21:59:22 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, IETF LAMPS WG <spasm@ietf.org>
In-Reply-To: <alpine.DEB.2.20.1903141524030.6514@softronics.hoeneisen.ch>
References: <alpine.DEB.2.20.1903141524030.6514@softronics.hoeneisen.ch>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Sun, 31 Mar 2019 21:59:22 -0400
Message-ID: <87tvfia3k5.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/cnSgKeo_Iswvp7aGmVY_dqaT7FU>
Subject: Re: [lamps] New Version Notification for draft-luck-lamps-pep-header-protection-01.txt (fwd)
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: Mon, 01 Apr 2019 04:02:32 -0000

On Thu 2019-03-14 15:24:51 +0100, Bernie Hoeneisen wrote:
> draft-luck-lamps-pep-header-protection-01.txt

Thanks for raising this to the group, Bernie!  As i said at the mic in
Prague, I like the framing of this draft, and i think it's asking the
right questions.

In particular, i like that it breaks down different types of
protections, and calls out a clear set of interactions that need to be
accounted for.  And i like that it aims to be comprehensive across both
S/MIME and PGP/MIME.

A few concerns about the draft itself:

 * OpenPGP Radix-64 § 2.1 -- inaccurate (missing newline), and its
   subsection 2.1.1 sneaks in action recommendations within a broader
   "Terms" section.  Also "Radix-64" not used elsewhere in the draft --
   i think it's safest to strike this section.

 * Formalized MIME subset (described as "pEp implementation" in § 5.1)
   -- this seems like a huge design decision that is probably out of
   scope.  If this draft tries to define something about the structure
   of the cryptographic protections of the message, that would be in
   scope, but making it affect the structure of the payload seems too
   radical for what this draft aims to do.

 * § 5.5 "Outer Message" and § 5.3 "pEp inner message" together seem
   similarly problematic, as they introduce another change to the
   payload MIME structure that is unrelated to header protection.  While
   that might be worthwhile in some contexts, this is not the place to
   make that proposal.

 * § 7 seems to suggest that Bcc: should be present in any of the
   headers.  having the Bcc explicitly present on a generated e-mail is
   unusual in modern mailers (though not impossible, of course).  If we
   want to call it out here as being potentially present, we might want
   to reference the guidance on page 24 of RFC 5322, to make it clear
   that we don't mean to encourage the introduction of Bcc anywhere else
   ("if included in the original message" could mean different things
   for Bcc depending upon which variant of Bcc practice is followed, and
   when you consider the Bcc hedaer being "included")

 * § 7 again: the Subject: masking header offers "p≡p" or "pEp" or
   "Encrypted message" -- I've seen a growing consensus among several
   MUA developers that this kind of in-band signalling is problematic.
   In the event that this subject line leaks to the receivers with any
   regularity, users will take this string as though it were an
   indicator from the UI that the message is actually protected.  This
   can result in confusion around the status of a message, if a subject
   line like "Re: p≡p" shows up on cleartext, unsigned messages, which
   is a very likely accidental scenario for e-mail messages that are

 * "trusted server" option (various subsections of § 8) seems like
   implementation details that shouldn't be normatively referenced in
   this draft -- if a draft describes interaction modes between MUAs and
   MTAs, then that draft could normatively reference this one, and
   describe the interaction there.

nitpicking:

 * General Requirement § 4.1 -- seems to skip from G1 to G3.  what
   happened to G2?

Overall, i see a lot of similarities between this and
melnikov-lamps-header-protection -- it seems to me like we should try to
consolidate the ideas in both of these drafts to make a single draft as
a clear set of guidelines.  I'm happy to try to help with that effort if
others agree that this would be useful.

       --dkg