[lamps] AD Review of draft-ietf-lamps-header-protection-18

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-lamps-header-protection-18.  Thank you for all of the work on this document and for the extremely robust set of examples associated with it. My feedback is as follows:


** What is the formal relationship between this draft and the S/MIME specification(s)?  A few quotes from the document:

(a) Abstract. “This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients.”

(b) Section 1.1.  “This document calls this scheme "Wrapped Message", and it is documented in more detail in [RFC8551].”

(c) Section 2.3.5. “The Wrapped Message header protection scheme is briefly documented in Section 3.1 [RFC8551].  This section provides a more detailed explanation of how to build such a message, and augments it with the protected-headers parameter with the value wrapped.”

-- The meta data of the document has no update tag, but (a) uses language suggesting it does.  Should this document update RFC8851?

-- I read (b) as saying RFC8551 has the canonical definition of “Wrapped Messages” but (c) then seems to say this document has more guidance on protecting the message and the additional (new to this document) guidance on headers.  I’m looking for some declarative statement for implementers on what needs to get read to use “Wrapped Messages”.  Does Section 2.3.5 supersede (replace) Does this guidance replace of some text in RFC8551?  Is an implementer supposed to combine Section 3.5.1 + this document for the totality of the guidance?  


** Section 1.4.  Editorial.
   For example, a legacy signed message  has a signature that covers the
   body but not the header fields.

What’s a legacy signed message?  “Legacy MUA” was defined as not supporting either injected or wrapped headers.

** Section 2.3.2.  Typo. s/it mean/it means/

** Section 2.4.3.  Typo. s/The/the/

** Section 2.3.4.2
   The content and formatting of this decorative <div> have no strict
   requirements, but they SHOULD represent all the obscured header
   fields in a readable fashion.

Why isn’t this a MUST.  When should the obscured headers be represented in an _un_readable fashion?

** Section 2.4

   An MUA SHOULD have a sensible default Header Confidentiality Policy,
   and SHOULD NOT require the user to select one.
...
   Any default Header Confidentiality Policy SHOULD provide
   confidentiality for the Subject header field by replacing it with the
   literal string "[...]".  


-- I agree with this guidance in a natural language sense.  However, from a conformance perspective what makes a policy “sensible”.  Beyond Section 2.4.1, what else would be “sensible” as an alternative?

-- When is a sensible policy not appropriate to field (i.e., a sensible possible is not actually required)?

-- Saying default to me already implies that local policy might override things. Did the WG discuss the possibility of something more straightforward like say:

==[ snip ]==
An MUA MUST have a default Header Confidentiality Policy of at least the protections provided by the minimum policy described in Section 2.4.1 to ensure that the user does not have to select one.  Local policy and configuration may alter this policy.
==[ snip ]==

My line of inquiry is whether it is too strong of a statement to say implementers of an MUA supporting this draft need to have a “secure default config”.

** Section 2.4.3

   A MUA offering header protection SHOULD NOT use hcp_null by default.

Same line of reasoning as above.  Why couldn’t this be a MUST where the default configuration is Section 2.4.1 and  local policy/configuration could decide to weaken things.

** Section 2.4.4.

   However, the first
   Internet Draft that attempts to define another HCP as a possible
   recommendation for the public should ask IANA to establish such a
   registry to avoid potential future namespace confusion. 

-- If this is important to do to prevent namespace confusion, why doesn’t this document define a registry?

-- If a future document did define HCP registry to prevent name collision, is this document the owner of hpc_null/hpc_minimal/etc or could it take that namespace?

-- Could the situation where there is namespace confusion be clarified.  Is the thinking that one could evaluate MUAs on their support of say “hcp_strong”?  That label would mean some kind of agreed upon configuration?

-- If there is an ecosystem of HPCs envisioned, how does one define them?  There is pseudo-code here with no defined semantics.  What is here looks almost like Python.

** Section 2.5.4.1.
   The MUA SHOULD ignore header fields from part J for the purposes of
   rendering.

What would it mean for the MUA NOT to ignore the headers in rendering?  Is this UI advice?

** Section 2.5.5.2
   In this case, the automated system that decrypts the incoming
   messages and scans the relevant MIME part SHOULD identify when the
   MIME part contains a legacy display element (see Section 2.5.3.3.1),
   and it SHOULD parse the relevant MIME part with the legacy display
   element removed.

What happens if these SHOULDs are not followed by certain MUA?  Doesn’t that produce inconsistent rendering of the same message across MUAs?  Is this flexibility needed?

** Section 2.5.7.  Editorial.  I don’t understand this section.  The title suggests that there are other rendering schemes, but it lists exactly one, pEp.  As an implementer, what do I do with this section?

** Section 2.5.9.
   An MUA that depends on any implicitly-rendered header field in a
   message with header protection SHOULD use the value from the
   protected header field, and SHOULD NOT use any value found outside
   the cryptographic protection.

-- I’m trying to understand if this guidance is saying “if the implicitly-rendered header fields are protected, use those instead of any implicitly rendered field that are not protected”, or something else?  

-- The construction of this guidance also has me confused about the situation where header protection exists for say the Subject field (hpc_minimum) but not for any of the implicit rendering fields?  Is the “SHOULD NOT” then applicable to using those unprotected implicit-rendered headers?

** Section 3.1.  Editorial.  There is a raw markdown reference of “{#compose-injected-headers}” suggesting there is a typo.

** Section 4.2.  Typo. s/not not/not/

**  Section 4.2.
   In the event that a MUA implementer gets user complaints about
   problems with removed or obscured header fields due to the MUA's
   defined HCP, the implementer may offer the user an option to drop
   header confidentiality altogether for freshly composed messages
   (thereby reverting to hcp_null).

The roles as described here don’t seem right.  Let me try to fill in the role names with specifics to explain.

“In the event that Microsoft gets a user complaint about problems with removed … fields due to Outlook’s defined HCP, Microsoft may offer the user ...”

“In the event that Google gets a user complained about problems with removed fields due to Gmail’s defined HCP, Google may offer …”?

-- How does the implementer offer to the user anything without going through the MUA?  Should the second clause be some version of s/the implementer may offer the user/the MUA UI may offer more robust configuration options that let the user .../
-- Maybe end-users in the consumer space complain to the MUA implementers, but in the enterprise space, aren’t the complaints sent to an IT department of some kind? Wouldn’t the HCP policy also be controlled by local policy in those cases?

** Section 4.3.  Typo.  s/outboud/outbound/

** Section 4.2
   A MUA should not expose the ordinary user to any configuration option
   where they are expected to manually select, enable, or disable header
   protections for new cryptographically-protected messages.

What’s an “ordinary user”?  Thunderbird shouldn’t give me the option to configure which of these I want to use?

** Section 5.  Do RFC8551-S/MIME Security Considerations apply here?

** Section 6.2.   Editorial.  Recommend s/powerful HCP/aggressive HCP” since that terminology was used earlier.

** Section 6.2.
   Instead, the composing MUA MUST judiciously
   populate the origheaders list for any outbound message with only
   information that the user reasonably intends the recipient to have
   access to.

Is it possible to be more specific on what a “user reasonably intends” or to soften the language.

** Section 6.2.4

   A receiving MUA should be cautious about how it represents the
   cryptographic status of encrypted-only and signed-and-encrypted
   header fields to the user, to avoid overpromising.

What does overpromising mean here?  Can this be tied back to more specific guidance mentioned here or to the e2e-mail-guidance document?

** Section 7.  Table 1 has the column of “Author/Change Control” but I don’t see that as a field in https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers

** Section 7.
   If a registry of Content-Type parameters is created, the parameter
   protected-headers should refer to this document.  Its possible values
   are v1 (meaning Injected Headers, see Section 2.1) and wrapped
   (meaning Wrapped Message, see Section 2.2).

Was there any discussion inside the WG or with the ART area (the place with the most concentrated knowledge of MIME) on creating such a registry?

Regards,
Roman