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

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 14 Mar 2019 15:24:51 +0100 (CET)

FYI (I-D updated to -01)

---------- Forwarded message ----------
Date: Tue, 12 Mar 2019 00:58:12
From: [email-masked]
To: Claudio Luck <[email-masked]>,
     Bernie Hoeneisen <[email-masked]>
Subject: New Version Notification for
     draft-luck-lamps-pep-header-protection-01.txt

A new version of I-D, draft-luck-lamps-pep-header-protection-01.txt
has been successfully submitted by Bernie Hoeneisen and posted to the
IETF repository.

Name:		draft-luck-lamps-pep-header-protection
Revision:	01
Title:		pretty Easy privacy (pEp): Header Protection
Document date:	2019-03-12
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-luck-lamps-pep-header-protection-01.txt
Status:         https://datatracker.ietf.org/doc/draft-luck-lamps-pep-header-protection/
Htmlized:       https://tools.ietf.org/html/draft-luck-lamps-pep-header-protection-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-luck-lamps-pep-header-protection
Diff:           https://www.ietf.org/rfcdiff?url2=draft-luck-lamps-pep-header-protection-01

Abstract:
    Issues with email header protection in S/MIME have been recently
    raised in the IETF LAMPS Working Group.  The need for amendments to
    the existing specification regarding header protection was expressed.

    The pretty Easy privacy (pEp) implementations currently use a
    mechanism quite similar to the currently standardized message
    wrapping for S/MIME.  The main difference is that pEp is using PGP/
    MIME instead, and adds space for carrying public keys next to the
    protected message.

    In LAMPS voices have also been expressed, that whatever mechanism
    will be chosen, it should not be limited to S/MIME, but also
    applicable to PGP/MIME.

    This document aims to contribute to this discussion and share pEp
    implementation experience with email header protection.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 31 Mar 2019 21:59:22 -0400

> 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