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

From: Russ Housley <[email-masked]>
Date: Thu, 3 Jan 2019 14:18:04 -0500

At the LAMPS session in Bangkok, there was interest in adding a header
protection work item to the charter.  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 LAMPS WG
produced an RFC on this topic.

Shortly before the holidays, DKG proposed charter text:

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

Does anyone have any concerns with this text?  If not, we will ask the
Security ADs to add this to the existing charter.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Jan 2019 19:25:44 +0000

Hiya,

> Security ADs to add this to the existing charter.

In case it helps: I previously voiced support for this on the
assumption that implementations were likely. Subsequent mails
to the list convinced me that's a safe assumption.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Jan 2019 19:32:47 +0000

Minor nit, I found one sentence a bit confusing.  Does this express the intent?
	Cryptographic protection, both signatures and encryption, applied to the headers in conjunction ...

Or is "both" better as "such as" ?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Jan 2019 14:39:16 -0500

> Or is "both" better as "such as" ?

I'm fine with either (or with "including"), but i prefer to say "both"
because i want to stress that these are the two forms of cryptographic
protection of e-mail messages that we're talking about (are there
others?), and that we want to ensure that we actually do handle them
both.

        --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Jan 2019 20:07:50 +0000

>    I'm fine with either (or with "including"), but i prefer to say "both"
  
Works for me.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 3 Jan 2019 22:32:40 +0100 (CET)

Hi DKG, Russ et al.

I think we need to include what's the current situation with this 
issue, in particular mention that there is a solution in on Standards 
Track already (RFC5751). How about something like this:

--- BEGIN ---

7. Cryptographic protection of electronic mail headers: RFC5751 defines a 
mechanism that is somewhat underspecified and thus not widely implemented. 
Most current implementations of cryptographically-protected electronic 
mail protect only the body of the message - but not the header part - 
which leaves significant room for attacks on otherwise-protected messages. 
The WG shall improve the specification to cryptographic protection of 
email-headers (both for integrity and encryption) to close significant 
privacy, security and usability gaps in cryptographically-protected 
electronic mail.

--- END ---

cheers
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

On Thu, 3 Jan 2019, Russ Housley wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Jan 2019 17:28:18 -0500

Bernie:

I do not agree that it is underspecified, but I do agree that it is not widely implemented.  The presentation to the user is not specified at all, which is quite normal for IETF protocol specifications.

Also, S/MIME and OpenPGP offer signature and encryption.  With S/MIME 4.0, you can get authenticated-encryption.  In any case, I think that "signature and encryption" was a better description.

Russ

> On Jan 3, 2019, at 4:32 PM, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Hi DKG, Russ et al.
> 
> I think we need to include what's the current situation with this issue, in particular mention that there is a solution in on Standards Track already (RFC5751). How about something like this:
> 
> --- BEGIN ---
> 
> 7. Cryptographic protection of electronic mail headers: RFC5751 defines a mechanism that is somewhat underspecified and thus not widely implemented. Most current implementations of cryptographically-protected electronic mail protect only the body of the message - but not the header part - which leaves significant room for attacks on otherwise-protected messages. The WG shall improve the specification to cryptographic protection of email-headers (both for integrity and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail.
> 
> --- END ---
> 
> 
> cheers
> Bernie
> 
> 
> 
> --
> 
> http://ucom.ch/

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 4 Jan 2019 00:02:41 +0100 (CET)

Hi Russ

Thanks for your feedback.

On Thu, 3 Jan 2019, Russ Housley wrote:

> I do not agree that it is underspecified, but I do agree that it is not 
> widely implemented.  The presentation to the user is not specified at 
> all, which is quite normal for IETF protocol specifications.

Obviously, we have different opinion on this. At least, there is the issue 
that encapsulated messages can not (always) be distiguished from forwarded 
messages. Alexey proposed a mechanism to include "forwarded=no" to the 
Content-Type HF to easily keep the two cases appart. See
https://tools.ietf.org/html/draft-melnikov-lamps-header-protection-00 
(Section 3.2)

However, I do not insist on including 'which is somewhat underspecified', 
as long as there is a clear mention / reference to the existing 
standardized solution.

> Also, S/MIME and OpenPGP offer signature and encryption.  With S/MIME 
> 4.0, you can get authenticated-encryption.  In any case, I think that 
> "signature and encryption" was a better description.

Both variants for wording are fine with me.

Here's my updated suggestion with your feedback included:

--- BEGIN ---

7. Cryptographic protection of electronic mail headers: RFC5751 defines a 
mechanism that is not widely implemented. Most current implementations of 
cryptographically-protected electronic mail protect only the body of the 
message - but not the header part - which leaves significant room for 
attacks on otherwise-protected messages. The WG shall improve the 
specification to cryptographic protection of email-headers (both for 
signature and encryption) to close significant privacy, security and 
usability gaps in cryptographically-protected electronic mail.

--- END ---

cheers
  Bernie

>> 7. Cryptographic protection of electronic mail headers: RFC5751 defines 
>> a mechanism that is somewhat underspecified and thus not widely 
>> implemented. Most current implementations of 
>> cryptographically-protected electronic mail protect only the body of 
>> the message - but not the header part - which leaves significant room 
>> for attacks on otherwise-protected messages. The WG shall improve the 
>> specification to cryptographic protection of email-headers (both for 
>> integrity and encryption) to close significant privacy, security and

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2019 20:24:15 -0500

>Track already (RFC5751). How about something like this:

If we're adding references to the charter which seems to me a
premature optimization, add RFC 6376, which is a well-specified
mechanism for full-message signatures, too.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 04 Jan 2019 11:35:22 -0500

>>Track already (RFC5751). How about something like this:

Bernie, thanks for your proposed change.  The second revision of your
text looks fine to me.  It is certainly "not widely implemented" --
iirc, there was only one implementation of it anywhere last i looked.

FWIW, i lean in Bernie's direction as far as "somewhat underspecified"
because the specification does lead to significant usability gaps (as
identified later in the proposed charter text) due to lack of guidance
about how a receiving MUA should interpret conflicting headers on the
inside and outside of the message's cryptographic envelope ("This entity
SHOULD be presented as the top-level message, taking into account header
merging issues as previously discussed." -- but with no mention of
"merging" anywhere else in the document).

This isn't so much a UI issue (which would be out of scope, as Russ
says) as it is an open semantic question, and i do think that's within
scope here.

> mechanism for full-message signatures, too.

John, would you be ok with leaving out RFC 6376 (DKIM) if we changed the
charter text to say "end-to-end cryptographic protection" instead of
just "cryptographic protection"?  is DKIM ever used by the sender
themselves, instead of by the domain itself (for example, with a
user-specific selector)?

I'm not sure that the charter text is a good place for such a catalog,
though perhaps these references could show up in a "related mechanisms"
section of the resultant document.

         --dkg

---

From: Russ Housley <[email-masked]>
Date: Fri, 4 Jan 2019 11:35:46 -0500

> mechanism for full-message signatures, too.

John:

It is true that DKIM signs the headers, but the signature is applied by the sending server, not the originator.  Bernie wants to point out that S/MIME includes a header protection mechanism, but it is not used.

Russ

---

From: "John R Levine" <[email-masked]>
Date: 4 Jan 2019 12:06:35 -0500

> themselves, instead of by the domain itself (for example, with a

That doesn't strike me as a meaningful distinction.  We designed DKIM so 
polciy about assigning selectors and where signatures are added are out of 
scope.  On my mail system, every DKIM signature has a unique selector. 
On the other hand, I'm pretty sure I know of systems where S/MIME 
signatures are generated and checked in MTAs and mailing list packages.

My preference would be to leave out the prior history catalog completely.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 04 Jan 2019 15:19:45 -0500

On Fri 2019-01-04 12:06:35 -0500, John R Levine wrote:
> That doesn't strike me as a meaningful distinction.  We designed DKIM
> so polciy about assigning selectors and where signatures are added are
> out of scope.  On my mail system, every DKIM signature has a unique
> selector.

Hm, that creates an interesting metadata phone-home situation!  Thanks
for pointing it out.  and taugh.com is a signed zone as well.  So you're
re-signing your zone with every message sent, or do you have a batch of
pre-signed selectors, and you just tick them off and regenerate a batch
when you're running low?  (apologies for the off-topic nature here --
feel free to reply to me privately on this if you want).

> signatures are generated and checked in MTAs and mailing list packages.

yep, understood.  I know such systems exist.  How would you expect DKIM
signatures to interact with protected encrypted headers?  do you think
this should be part of the scope of this work in LAMPS?

> My preference would be to leave out the prior history catalog completely.

Leaving out the prior history catalog works for me, too.

     --dkg

---

From: [email-masked]
Date: Sat, 5 Jan 2019 11:09:03 +0100 (CET)

Hi Daniel

Thanks for your comments.

> iirc, there was only one implementation of it anywhere last i looked.

There are certainly more than just one implementation of S/MIME version 
3.1 / 3.2 Header Protection in the wild. Unfortunately, most of these 
implementations offer this as an optional feature only (e.g. to prevent 
interoperability issues). As a consequence, the Header protection feature 
is mostly hidden.

Outside the S/MIME world I am aware of at least 4 further implementations 
that use RFC 5751 mechanisms for doing header protection.

> "merging" anywhere else in the document).

Yep, that's another challenge faced.

Furthermore, we probably should also look into "feature negotiation" 
capabilities, e.g. to detect whether the other party is (parties are) 
capable of handling Header protection messages.

cheers,
  Bernie

---

From: [email-masked]
Date: Sat, 5 Jan 2019 13:39:58 +0100 (CET)

Hi John

Thanks for your feedback

> My preference would be to leave out the prior history catalog completely.

This is not about prior history.

S/MIME Version 3.2 (RFC 5751) defines a mechanism to perform Header 
Protection, which has some implementations out there. The outcome of the 
new Charter Item on Header Protection is almost certainly going to have an 
impact on the currently standardized version and therefore to update RFC 
5751 (or rather its bis).

Although, I hope (and still believe) we can find a viable solution that 
remains backwards compatible to S/MIME Version 3.2 (i.e. minor updates and 
additions to the existing standards only), there are other proposals that 
suggest to change the way Header Protection is done in S/MIME rather 
fundamentally.

Therefore, I am of the opinion we ought to mention / reference what 
existing standards are directly going to be affected by the outcome of 
the new charter item.

cheers,
  Bernie

---

From: [email-masked]
Date: Sat, 5 Jan 2019 16:04:14 +0100 (CET)

Hi John, Daniel, et al.

> Leaving out the prior history catalog works for me, too.

Would the following proposal (HB-3) be more acceptable? I tried to 
eleminate "redundancy" and removed any assumptions on prior 
implementations, i.e. short and concise:

--- BEGIN HB-3 ---

7. Cryptographic protection of electronic mail headers: A mechanism to 
address this in S/MIME has been standardized in RFC 5751. The WG shall 
improve the specification (both for signature and encryption) to close 
significant privacy, security and usability gaps in 
cryptographically-protected electronic mail.

--- END HB-3 ---

cheers
  Bernie

---

PS: Just for reference and better overview the earlier suggestions 
(with labels added to keep them appart):

--- END DKG-1 ---

Any suggestion I missed?

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2019 10:05:36 -0500

> cryptographically-protected electronic mail.

Sure.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Jan 2019 15:13:24 +0000

Hi Bernie,

Clarifying question and a comment.

> cryptographically-protected electronic mail.

The above reads to me like it constrains the work to be backwards
compatible with 5751 if that is possible.

Is that your intent?

I'd be against having such a constraint myself.

If you don't intend such a constraint then I think wording that
makes that clear would be better.

All told though, I'd prefer if the history was just omitted - I
think we're better focusing on what's likely to get implemented,
deployed and used, rather than our collective historic failures
wrt e2e security for mail.

Cheers,
S.

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2019 10:29:07 -0500

> I'd be against having such a constraint myself.

This is a good point.  The message wrapping in 5751 makes some fundamental 
assumptions about the environment in which a message is sent and received.

Regards,

---

From: [email-masked]
Date: Sat, 5 Jan 2019 17:04:50 +0100 (CET)

Hi Stephen

Thanks for pointing this out.

Trying to answer your question:
It is _not_ my intent to include any constraints on the solution to the 
new charter item, in fact IMHO the charter shall _not_ limit the solution 
space. At the end of the day, we need to be able select the best solution.

However, I just noticed what likely triggers your concern with the wording 
in HB-3, i.e. different people may interpret the text in HB-3 differently 
(which should to be avoided).

Would the following improved suggestion HB-3.1 address your concern 
adequately?

--- BEGIN HB-3.1 ---

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.

--- END HB-3.1 ---

cheers,
  Bernie

--

http://ucom.ch/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Jan 2019 16:09:03 +0000

Hiya,

On 05/01/2019 16:04, [email-masked] wrote:
> define solutions (both for signature and encryption) to close

Thanks. That would allay my concern yes.

That said, I'd still prefer omit the reference as I reckon it's
more likely to confuse than help, but the above form is not a
problem.

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 05 Jan 2019 17:16:02 -0500

> that use RFC 5751 mechanisms for doing header protection.

Thanks for doing this research, Bernie.

It would inform the discussion if you could point to the implementations
you're talking about here.

        --dkg

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 7 Jan 2019 09:38:25 +0100 (CET)

Hi Daniel

> Thanks for doing this research, Bernie.

Well, my findings are just the result of some rather basic websearch I 
did some time ago out of curiosity.

Sure.

What I remember from this basic websearch: In S/MIME isode, rebex, and a 
couple of others (I don't remember the names anymore) appeared to 
have implemented (full or partial) support for S/MIME version 3.1 / 3.2 
Header Protection. Anyways, the total number of implementations is likely 
rather low.

Maybe others on this list have further information on the implementation 
situation of Header Protection in S/MIME, which they may want to share 
here.

Outside the S/MIME world, I can refer to the four implementations that 
support pEp (pretty Easy privacy). pEp is specified to perform Header 
protection (almost) the same way as described in RFC 5751. Said 
implementations are:

- pEp for Outlook as add-on for Microsoft Outlook

- pEp for Android (based on a fork of the K9 MUA)

- Enigmail/pEp as add-on for Mozilla Thunderbird

- pEp for iOS (implemented in a new MUA)

Hope that helps.

cheers,
  Bernie

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 07 Jan 2019 08:58:38 -0500

On Mon 2019-01-07 09:38:25 +0100, Bernie Hoeneisen wrote:
> Header Protection.

Isode is the implementation i was aware of.

Can you point me to the rebex implementation?  I see:

  https://www.rebex.net/secure-mail.net/features/s-mime.aspx

which says:

     Please note that only the message body is encrypted - everyone can
     still read the message headers such as From, To, Date or Subject.

If you could remember the names of the couple of others you found, or
dig them back up with another websearch, that'd be great.

> Anyways, the total number of implementations is likely rather low.

yep, that seems to be the consensus on the list.

> situation of Header Protection in S/MIME, which they may want to share 

agreed, that would be great.

> protection (almost) the same way as described in RFC 5751.

RFC 5751 doesn't cover anything outside of S/MIME, but i agree with you
-- i want whatever header protection LAMPS specifies to work for
PGP/MIME as well.  Can you explain what the "(almost)" means in the
paragraph above?

Are you talking about "pEp email format 1" or "pEp email format 2" of
https://pep.foundation/dev/repos/internet-drafts/file/tip/pep-email/draft-marques-pep-email.mkd
or are you talking about something else?

it doesn't look to me like either of those two formats specifically are
related to RFC 5751-style headers protection -- there's no mention of
message/rfc822 content-type in the text, or in the examples, and the
headers aren't positioned as headers, but instead they're included "as
the first line" of the body (which i confess i don't understand if the
Content-Type is anything other than text/plain).

Anyway, i don't mean to have the design discussion in this thread, i'm
just trying to gather information about what's actually implementing and
using RFC 5751, so we can determine how to represent it accurately in
the charter text (if we refer to it at all).

Can we settle on a single proposal?

        --dkg

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 9 Jan 2019 21:53:31 +0100 (CET)

Hi Daniel

> dig them back up with another websearch, that'd be great.

If I (re-)find more information on rebex and others, I'll share it.

> PGP/MIME as well.

If we can agree on a proposal that works for PGP and S/MIME, that would be 
great.

> Can you explain what the "(almost)" means in the paragraph above?

As you mention above, RFC 5751 is only defined for S/MIME, though in 
pEp it works by the same principle.

> or are you talking about something else?

I refer to 'pEp email format 2', which performs header protection 
by message encapsulation in a similar way as described in RFC 5751.

However, I understand that you may be confused by the current version of 
draft-marques-pep-email, as this draft is rather incomplete at this stage, 
i.e. it does not yet describe the case, if both ends are pEp-aware. 
Hernani promised an update of that I-D by the end of this week.

> Can we settle on a single proposal?

Do you have any issues or counter proposals on the HB-2 or HB-3.1 
charter proposals (I sent to this list last week)?

cheers
  Bernie

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Jan 2019 13:21:45 -0500

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.

Russ

> On Jan 3, 2019, at 2:18 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Hernâni Marques (p≡p project) <[email-masked]>
Date: Thu, 10 Jan 2019 22:54:29 +0100

>    security and usability gaps in cryptographically-protected

For me fine.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jan 2019 09:17:03 +0000

>>    security and usability gaps in cryptographically-protected

Also seems fine to me. I'd say shoot it on.

S

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 11 Jan 2019 13:17:49 -0500

>    security and usability gaps in cryptographically-protected

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Jan 2019 13:56:45 -0500

I prefer this wording as well.

Russ

> On Jan 11, 2019, at 1:17 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
>

---

From: Hernâni Marques (p≡p project) <[email-masked]>
Date: Fri, 11 Jan 2019 20:39:46 +0100

Hello dkg & Russ & list

> against otherwise-protected messages.

Thanks for the new suggestion!

Despite *email, I can live with that, but if there's no objection I
would also add interoperability to the list, such as to have the
following text:

--- BEGIN HM-1 ---

7. Update the specification for the cryptographic protection of email
headers -- both for signatures and encryption -- to improve the
implementation situation with respect to privacy, security, usability
and interoperability 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 HM-1 ---

Greets!

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 11 Jan 2019 21:05:45 +0100 (CET)

Hi Daniel

Thanks for your input. Your latest proposal (DKG-2) works for me. As you
say, it even fits better to the existing charter text and probably
allays the concerns raised by John and Stephen about explit references to
(legacy) RFCs.

Hernani's small amendment (HM-1) looks even better.

I suggest to go forward with the wording HM-1, though DKG-2 is also a
viable option for me.

cheers,
   Bernie

--

http://ucom.ch/

* * *

> for attacks against otherwise-protected messages.

* * *

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 11 Jan 2019 15:29:49 -0500

> for attacks against otherwise-protected messages.

I'm fine with this text too.  Does anyone have an objection to HM-1?
can we move forward with working on the actual draft? :)

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Sat, 12 Jan 2019 11:43:27 -0500

> On Jan 11, 2019, at 3:29 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

The next step is IESG approval of the revised charter.

We have an individual draft, and we can continue to work on that, including discussing issues on this list, while the IESG does the re-charter process.

Russ