Subject: [lamps] Header Protection, summary of my today's suggestion

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 8 Nov 2021 20:44:14 +0100 (CET)

Dear LAMPS WG

As requested I am trying to summarize my suggestion for a compromise to 
deblock the discussions on the Header Protection Draft. 
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/

Background:

Over the last time we assessed pro and cons of the two proposals "wrapped" 
(current S/MIME Standard) and "injected" (an alternative) header 
protection schemes; (the latter with two variants, adding "Legacy 
Display" variant for signed&encrypted).

IMHO the summary on the results of the assessment was roughly:

- None of the protection schemes is clearly superior to the others

- In Signed&Encrypted case the "wrapped" scheme clearly prevails

   - While with the "wrapped" scheme some clients require opening an
     attachment, with the "injected" scheme all assessed clients do NOT
     render ANY subject. The "legacy display" improves the situation
     with some clients, but makes things much worse with Outlook.

- In Signed-Only there is a difference between S/MIME aware and
   non-S/MIME aware clients

   - For S/MIME aware clients there is no clear "winner". (With the
     "wrapped" scheme some clients require opening an attachment, while
     with "injected" scheme all assessed clients can not render the
     protected subject (unprotected subject only).

   - For S/MIME unaware legacy clients in certain cases, it seems more
     likely that the messages can be rendered with the "injected" scheme
     using multipart (however also with the unprotected Subject only)
     compared to the "wrapped" scheme. (Note: This aspect was not assessed
     thoroughly)

In short: The only case, where the "injected" scheme seems to a better 
choice than the currently standardized "wrapped" scheme is for signed-only 
messages sent to with S/MIME unaware clients.

For more complete information, please refer to the streams of 
LAMPS@IETF-111 (July 2021).

My Sugggestion:

- Keep the "wrapped" header protection scheme as the default in the S/MIME 
standard for all cases.

- Provide clear instructions to help implementors on how to update S/MIME 
clients that still need the reader to click on the attachment to 
render a wrapped message.

- Allow "injected" as an option for the case "Signed-Only & multipart", to 
provide a mechanism for sending-clients to help S/MIME unaware 
receiving-clients to render the message.

Note:

Fixing clients to automatically render "wrapped" messages is a fairly easy 
and straight-forward change. Clients like Apple-Mail or Thunderbird do 
this already, while for Outlook there is a Plugin implementing such a 
rendering functionality for pEp (cf. https://pep.software/outlook/ ).

Hope that helps and that I did not leave out important information in an 
attempt to keep this summary shortish.

All the best,
  Bernie

--

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Nov 2021 15:01:26 -0500

Thanks Bernie.

I think the next step is for the authors update the draft to reflect his way forward (or whatever recommend that comes from a sided discussion).

Russ

> On Nov 8, 2021, at 2:44 PM, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Dear LAMPS WG
> 
> As requested I am trying to summarize my suggestion for a compromise to deblock the discussions on the Header Protection Draft. https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
> 
> 
> Background:
> 
> Over the last time we assessed pro and cons of the two proposals "wrapped" (current S/MIME Standard) and "injected" (an alternative) header protection schemes; (the latter with two variants, adding "Legacy Display" variant for signed&encrypted).
> 
> 
> In short: The only case, where the "injected" scheme seems to a better choice than the currently standardized "wrapped" scheme is for signed-only messages sent to with S/MIME unaware clients.
> 
> For more complete information, please refer to the streams of LAMPS@IETF-111 (July 2021).
> 
> 
> My Sugggestion:
> 
> - Keep the "wrapped" header protection scheme as the default in the S/MIME standard for all cases.
> 
> - Provide clear instructions to help implementors on how to update S/MIME clients that still need the reader to click on the attachment to render a wrapped message.
> 
> - Allow "injected" as an option for the case "Signed-Only & multipart", to provide a mechanism for sending-clients to help S/MIME unaware receiving-clients to render the message.
> 
> 
> Note:
> 
> Fixing clients to automatically render "wrapped" messages is a fairly easy and straight-forward change. Clients like Apple-Mail or Thunderbird do this already, while for Outlook there is a Plugin implementing such a rendering functionality for pEp (cf. https://pep.software/outlook/ ).
> 
> Hope that helps and that I did not leave out important information in an attempt to keep this summary shortish.
> 
> All the best,
> Bernie
> 
> 
> --
> 
> http://ucom.ch/
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Nov 2021 21:21:44 -0500

Hi Bernie--

Thanks for writing this down!  I'm looking forward to having more
discussion with you and Alexey about what to propose to the WG as the
next revision.

I think we're still not exactly on the same page, but we're headed in a
direction that sounds like we might have some agreement :)

Alexey noted during the discussion at LAMPS that he would be reluctant
as an implementer to have distinct header protection schemes for signing
and encryption.  i'm not sure how many other implementers share that
concern, but it's also something that we probably want to consider.

Let me highlight a few places where i think my analysis differs from
yours.  Hopefully if other LAMPS participants want to identify points of
agreement or disagreement this is a useful conversation to have in public

>      with some clients, but makes things much worse with Outlook.

I agree with you that Outlook's mangling of the legacy display part
makes that strategy unfeasible for senders who don't know the set of
MUAs used by the recipients (this is probably the majority of all
senders).  But i also think "opening attachment" or "clicking through"
to work with the inner message is potentially problematic in two ways:

 - It is a usability failure, a stumbling block which looks to the
   recipient like it is caused by the sender of the message.  This is
   likely to contribute to backpressure from users who report problems
   to "fix the bug", presumably by turning off header protection, or by
   avoiding encryption altogether.

 - It appears to reinforce actual security failures in the workflow of a
   message reply.  In particular, a legacy client working from an
   "opened attachment" or "clicked-through message" appears likely to
   fail to encrypt the reply automatically (most MUAs automatically mark
   replies to encrypted messages by default, as they should).  But even
   for replies that *are* encrypted, a previously protected subject line
   is very likely to leak to any observer of the e-mail.

   These problems make the security implications of header protection
   more equivocal than they should be: a message sender should not be
   concerned that by protecting the Subject: header of a sent message
   they're more likely to trigger a leak of the sensitive material.

I think we want to minimize both the security and usability problems, so
that MUA implementers feel confident in layering header protection on
signed+encrypted messages by default, without needing additional
configuration.

>      protected subject (unprotected subject only).

Again, the "opening an attachment" situation is a usability failure.

The implication here is that the legacy clients will not be protected
from message tampering that affects the headers for the injected scheme.
I think that is ok.  maybe even better than OK -- it provides some
incentive for the receiving agent (the ones who actually stand to gain
security benefits from signed messages, as they are representing
signature to their user) to learn to interpret these messages correctly.

>      compared to the "wrapped" scheme. (Note: This aspect was not assessed

Signed-only rendering for S/MIME-unaware legacy clients is only
important for users who don't know what their recipients' MUAs are.
But, as noted above, that's pretty much everyone :)  Again, avoiding
this problem seems like it's a way to ensure that it's "safer" for a
sending MUA to add signatures when possible.

> render a wrapped message.

I don't think the problem is that we're lacking "clear instructions" to
help implementers -- we just have the classic deployment deadlock where
generators are reluctant to implement a standard that might introduce
problems, and receivers are reluctant to implement a standard that has
seen no deployment :)

> receiving-clients to render the message.

It seems simpler to me to say that "injected" is the safer standard to
emit in all cases -- that senders can implement and deploy it without
significant usability or security concerns -- and then separately try to
come up with some different "legacy display" approach that handles the
lack of visibility of the subject line for legacy decryption-capable
MUAs.

In the meeting, i sketched out an idea for a variant "legacy display"
approach that works for messages with "main part" that terminates in a
text/html leaf:   introduce a simple HTML element at the beginning of
the body with a specific class attribute of "legacy-header-display" that
contains the headers that are protected with confidentiality, like so:

 <div class="legacy-header-display">Subject: Dinner plans with Josie</div>

An MUA that is header-protection-aware and renders text/html parts can
introduce a snippet of CSS in their default local text/html renderer
that hides this "legacy display":

// local stylesheet
   .legacy-header-display {
       display: none;
   }

whereas a legacy renderer will just display it as normal, providing
visibility to the recipient that will *not* leak into the subject field
of the reply by default.

We can extend this idea to text/plain leaf parts of the "main part",
though doing so is a bit scarier because of its potential to interact
poorly with automated systems that parse text/plain message bodies out
of encrypted e-mail.  But i haven't seen any analysis of those systems
in the context of any of these message formats yet: they could stumble
on other approaches too.

Anyway, Alexey and Bernie and I will meet separately early next month to
try to hash out these ideas and propose an updated draft to the WG and
try to move the discussion forward.

If anyone has other ideas that they want to contribute, please post
here!  we'd be happy to include them.

All the best,

    --dkg