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

[Claudio Luck <[e-mail]>]

Hi Daniel

Thanks a lot for your comments!

In the current draft in section 5 and onwards we shamelessly described
pEp's current implementation, keeping the emphasis on completeness, thus
expanding a bit bejond header protection alone. This should now change
as we progress with our other drafts in the MEDUP WG, so that we can
reference them properly. I'm looking forward in settling all your
objections.

Please find detailed comments inline.


On 01.04.19 03:59, Daniel Kahn Gillmor wrote:
> 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.

This is a leftover and I'll remove it in the next revision.

> 
>  * 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.

I can imagine that we can abstract this away.

> 
>  * § 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.

Section 5.3 indeed re-iterates section 5.1 and probably will go.

For 5.5 we need to discuss the intersection of various usecases which
all work with signatures: qualified signatures on attachments and full
emails vs. automated transport security. We need to make sure we don't
step on each other's feets by using the same standard for slightly
different purposes.

> 
>  * § 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")

Good point, we need to better separate the sendmail interface
perspective from the SMTP based MUA-to-MTA submission.

> 
>  * § 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

(some text went missing?)

What value would you suggest for the Subject of the wrapper and outer
messages? The Subject header is mandatory, but the value can be
arbitrary (including empty).

Note that pEp ignores the outer subject, we use the "X-Pep-Version"
header. A remark has been made that a MIME Content-Type property would
probably be more appropriate here.

But... a subject reading "Re: p≡p" is a strong indication for a buggy
MUA with does not follow the pEp protocols correctly, or applies various
draft standards concurrently. In any case it's not a good benchmark at
this point...

> 
>  * "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.

I'm partly with you here. I still wonder how much we should consider
server- and client-side message filtering (inbound and outbound), as
much of it relies in accessing the header values. In this case we'll
need to consider transport to/from the mailbox and to mail submission as
separate protocols and transmissions.

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

G2 was merged to G1, and we missed re-numbering. Further revisions are
likely here.

> 
> 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.
> 

We still see these drafts as complementary, but we are definitely open to
discuss consolidation.

-- 
Best
Claudio Luck
pEp Security SA / pEp Foundation