Re: [lamps] I-D Action: draft-ietf-lamps-header-protection-04.txt

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2021-05-21 07:36:54 -0700, [e-mail] wrote:
>       Title           : Header Protection for S/MIME
>       Authors         : Daniel Kahn Gillmor
>                         Bernie Hoeneisen
>                         Alexey Melnikov
> 	Filename        : draft-ietf-lamps-header-protection-04.txt
> 	Pages           : 168
> 	Date            : 2021-05-21

Hi LAMPS folks--

There are few textual changes in -04 from -03, but the main difference
is that the draft now includes test vectors.

I think the next steps on the document will be a textual cleanup, as the
draft is currently a bit disorganized.

Two primary questions for the WG to answer for MUAs that will choose how
to consume messages with header protection:

  A) does the draft adequately describe the two known header protection
     schemes, such that they can be consumed reliably?

  B) is the draft sufficient in its guidance about how header protection
     (or lack thereof) should be interpreted by a receiving MUA?

Test Vectors
------------

The new test vectors are generated with the certificates and keys from
draft-ietf-lamps-samples-04.  They make up the bulk of the draft.

Each test vector is an e-mail message.  In addition to publishing them
in the draft, they are also available in more accessible formats at
https://header-protection.cmrg.net/ .  The formats offered include mbox,
zipped maildir, individual .eml files, and a public-facing IMAP server.

There are a variety of different messages, as requested during the LAMPS
meeting at IETF 110:

 - the cryptographic payload varies between a simple text/plain message,
   and a more complex  multipart/alternative message with an attached
   PNG image.

 - Some baseline messages have no cryptographic protection at all, to
   make comparisons more clear.
 
 - There are messages with cryptographic protection (both signed and
   signed+encrypted) but no header protection, also for comparison.
   
 - the messages with header protection include messages using both the
   "injected headers" scheme and the "wrapped message" scheme.

I'm asking for people to take screenshots with their preferred MUA of
whatever messages they can.  There are more detailed instructions at
https://header-protection.cmrg.net/

Note that all the test vectors with cryptographic protections rely on
RSA keys and certificates, and do *not* require Ed25519 or X25519.  It
seems more sensible to establish and evaluate header protection patterns
without requiring MUAs to have already implemented the CFRG curves.

I've already made screenshots of all the messages (both rendering and
replying) using three S/MIME-capable clients:

 - Thunderbird 78.10.0
 - Evolution 3.38.3
 - Balsa 2.6.2

I will likely include go on to include more screenshots from MUAs that
are accessible and scriptable from the GNU/Linux platform that i'm most
comfortable with.  I'd really appreciate contributions from folks
comfortable with other platforms.

These screenshots are visible directly in the repository at
https://gitlab.com/dkg/lamps-header-protection

Recommendations Needed
----------------------

We need screenshots of the test vectors (and the experience that comes
with people actually trying to exercise their MUAs) because we need the
WG to come to a decision on two specific questions for MUAs that
*generate* messages with protected headers:

  C) The draft recommends that each MUA be able to *consume* messages
     with either header protection scheme (few MUAs correctly handle
     either scheme today).  But we should recommend generation of only
     one specific scheme.  Which scheme should be recommended?

  D) The draft describes a framework for Header Confidentiality Policies
     (HCPs), and defines two specific HCPs (hcp_strong and hcp_minimal)
     but does not recommend anything.  I think it should recommend one
     for MUAs that opt into header protection but don't know what to
     pick.  Which which one should be recommended?

If the draft can make these recommendations, then a MUA developer that
doesn't want to make any policy decisions can just focus on
implementation.  I think that's a good thing -- making policy decisions
in a relatively novel space can be a cause for inertia.

I have my own current intuitions about how to answer C and D, but I'm
just an editor of the document -- I want the document to reflect WG
consensus.

Regards,

        --dkg