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

From: Russ Housley <[email-masked]>
Date: Mon, 5 Nov 2018 22:34:33 -0500

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.

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

2) If it is added, would you review the document?

3) If it results in an RFC, would you implement?

Russ & Tim

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Nov 2018 03:36:45 +0000

I support this and would review any drafts; I am unlikely to do any implementation.

---

From: Quynh Dang <[email-masked]>
Date: Mon, 5 Nov 2018 22:40:11 -0500

Hi Russ,

I support this work and would review the document.

Regards,
Quynh.

On Mon, Nov 5, 2018 at 10:35 PM Russ Housley <[email-masked]> 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.
>
> Three questions:
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Nov 2018 03:44:04 +0000

> I support this and would review any drafts; I am unlikely to do any implementation.

Same here. (Assuming that someone will implement.)

S.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Nov 2018 11:24:05 +0700

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Tuesday, November 6, 2018 10:35 AM
> To: SPASM <[email-masked]>
> Subject: [lamps] Proposed addition of header protection to the LAMPS
> charter
> 
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.

Yes
> 2) If it is added, would you review the document?

Yes

> 3) If it results in an RFC, would you implement?

No

Jim

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2018 11:57:54 +0700

>3) If it results in an RFC, would you implement?

Not to be an old grouch or anything, but anything that affects mail
user interfaces is dismayingly hard to do well and easy to do in ways
that nobody wants to use.  When we were looking at anti-DMARC hacks
for the IETF mailing lists I wrote a mail reflector that wrapped
messages in various ways and sent them back so people could see how
they looked in their mail programs.  The only thing that was
consistent from one MUA to another was that they looked awful.

I think header protection is a fine idea, but without some code to try
and see if it's usable, we're far too likely to end up with yet
another paper spec.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 6 Nov 2018 12:29:09 +0700

> On 6 Nov 2018, at 11:57, John Levine <[email-masked]> wrote:
> 

I am planning to test existing S/MIME clients that are ignorant of header protection to see how they behave. My hope is that one of 2 proposals described in my draft will result in much better UI experience for such clients. I will send results of my testing to the mailing list.

---

From: Hernâni Marques (p≡p project) <[email-masked]>
Date: Wed, 7 Nov 2018 06:16:42 +0100

Hello Russ

> 1) Do you support the addition of this work to the LAMPS charter?

Yes.

> 2) If it is added, would you review the document?

Yes.

> 3) If it results in an RFC, would you implement?

For incoming messages in any case (for interop) in pEp implementations
(for now: Android, iOS, Outlook and Enigmail/pEp mode), for outgoing
messages depending on the final specification.

Greets

Hernani

---

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Wed, 7 Nov 2018 06:29:20 +0100

> I am planning to test existing S/MIME clients that are ignorant of header protection to see how they behave. My hope is that one of 2 proposals described in my draft will result in much better UI e…

From pEp side we can also provide valuable feedback how things behave in
the field, as we're running extensive interoperability / doing trials in
within larger companies and for that adapting: e.g., there exist
extensive tests for the Microsoft world in S/MIME and PGP contexts (e.g,
w/ Symantec PGP).

-- 
p≡p foundation: https://pep.foundation/

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 7 Nov 2018 06:37:36 +0100 (CET)

I support the addition of Header protection to the charter and will review 
the document. As just mentioned by Hernani the pEp implementations will 
remain interoperable.

cheers
  Bernie (Ucom.ch / pEp)

--

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

On Mon, 5 Nov 2018, Russ Housley wrote:

> protection work item to the agenda.  Alexey talked about this in 
> Montreal, and he posted a draft a few weeks ago:

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 12 Nov 2018 10:57:40 -0500

> consistent from one MUA to another was that they looked awful.

John, if you have the infrastructure set up to generate screenshots of
e-mail messages on multiple MUAs (particularly those that handle message
encryption and/or signatures), i'd love to take advantage of it!  If
it's something you can share, please let me know (off-list is fine if
it's not something you can make broadly public).

> and see if it's usable, we're far too likely to end up with yet

There are multiple clients already doing header protection today,
interoperably (e.g. enigmail and K-9 mail).  This is not a code-free
exercise :)

         --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 12 Nov 2018 10:55:30 -0500

> 1) Do you support the addition of this work to the LAMPS charter?

I support this change to the charter.

> 2) If it is added, would you review the document?

i will not only review, but have offered to co-author the doc with Alexey.

> 3) If it results in an RFC, would you implement?

yes, i already have a implementation that consumes both variants
described, and will implement a producer for one of them as well.

           --dkg

---

From: "John R Levine" <[email-masked]>
Date: 12 Nov 2018 11:51:48 -0500

> it's not something you can make broadly public).

I have the code that wraps and responds lying around somewhere.  I'll see 
if I can find what addresses it's attached to.  I don't have any 
screenshot tools beyond what anyone has on a Mac or a phone.

> interoperably (e.g. enigmail and K-9 mail).  This is not a code-free

The question isn't whether it's possible to write applications that can 
wrap and unrwap mail.  Of course it is.  The question is whether it's 
usable at scale.  Two niche applications do not scale make.  Get Oath and 
Gmail to implement it in webmail and MS to put it in Outlook, and then 
it'll be interesting.

If e2e encrypted mail becomes at all popular outside of small closed 
communities it will be useless because 95%* of it will be spam and 
malware.  Spam filtering depends both on metadata which the MTA can use 
with encrypted mail and with body filtering which it can't.  Filters need 
to look at the contents and correlate them with the contents of other 
messages both to look for bulk mail, and to recognize and deflect links to 
phishes and malware.

The mail community has known about this issue for a long time and so far 
we have no idea what to do about it other than giving your keys to your 
MTA so it can unwap and filter.

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

* - that's how much of mail is spam and malware these days