Re: [lamps] WG Last Call for draft-ietf-lamps-header-protection-14

[Nicolas Lidzborski <[e-mail]>]

Thanks for this proposal. A few comments based on
draft-ietf-lamps-header-protection-14 (some may be corrected on your
separate git instance).

Page 4: Style for Appendix titles: I noted that the appendix chapters do
not use uppercase for words, which makes them inconsistent with the rest of
the doc and seems to go against RFC standards.
This appears to be covered by
https://www.rfc-editor.org/rfc/rfc7322#section-3.4

Page 6: "interpret such messages": I am wondering whether it would make
sense to split this RFC in two components. One focused on the actual
schemes you introduce and define (hcp) and then another one focused on MUA
suggestions. The rationale to do this would be that the generated messages
are permanent, while the MUA capabilities and UX can change a lot over
time. I also believe that UX would greatly benefit from extensive user
studies rather than "setting it in stone" via RFC.

Page 7: "Two Schemes of Header Protection": I think it would be valuable to
focus effort on a single scheme rather than having the complexity of
multiple mechanisms supported. I think more complexity here increases the
time required for implementation, the risk of bugs as well as UX confusion
for end-users.

Page 7: "several legacy MUAs": can you clarify what those MUA and bugs
were? One source I found was
https://stackoverflow.com/questions/60380150/encrypting-headers-s-mime-message-rfc822,
which paints a pretty bleak picture with no significant MUA adequately
supporting the Wrapped Message header protection scheme. Back to my earlier
point, let's focus on ONE scheme and ensure it is properly defined and
supported by multiple providers.

Page 7: "some mail user agents cannot render message/rfc822 message": I
suggest not using "worst cases" as it is definitely judgemental. Imho,
implementation of the RFC that exposes users to more harm (for example
phishing) are worse for security and privacy end goals.

Page 8: "email" vs "e-mail": I suggest staying consistent throughout the
document for which one you use.

Page 8: "such as the message Subject": Did we consider having explicit
Subject versus EncryptedSubject headers (with supporting UX) actually
enable users to understand the difference better (and have backwards
compatibility)?

Page 9: Is "DKIM+DMARC" used as singular or plural? Adjust the verbs
accordingly. Maybe be explicit with "DKIM+DMARC suite" or "DKIM+DMARC
messages"?

Page 9: "DKIM+DMARC not provide" -> "DKIM+DMARC do(es) not provide"

Page 11: "Header Protection" -> "Header Protection (HP)" as HP abbreviation
is used later on.

Page 12: "Out of scope": I think it is a bit harsh to cast aside a
significant amount of existing constructions. In particular, triple-wrapped
messages are used at scale today and explicitly mentioned in RFC 2634. I
think it is worth identifying how we can land a common standard rather than
continue to have plenty of different, complex and incompatible schemes that
will likely provide a high likelihood of misleading users and impacting
security + privacy gal here.

Page 13: Typo: "MIME part of the Cryptograhic Payload" -> "MIME part of the
Cryptographic Payload"

Page 16: Can you explain better the role of the HP-Removed and HP-Obscured
headers? Wouldn't it be simple to just have the encrypted headers just
override the external headers?

Page 17: "Composing with "Injected Headers" Header Protection": given the
current poor and uneven support for header protection, do we need to add so
much complexity here? I appreciate the effort of handling legacy, but it
may be better to not end up with endless backwards compatibility complexity.

Page 17: "Composing with "Injected Headers" Header Protection": is it
really acceptable for the MUA to modify the main message body like this
after the user clicks send? Basically, the MUA is adding main body content
that will be digitally signed without clear callout that this is happening.

Page 24: "are surprised": this depends on the users and training. Also
people will stay confused given the many other schemes possible in MUA. See
my point earlier about explicitly having an Encrypted Subject (or renaming
the normal subject "Cleartext Subject" throughout the MUA compose UI to
stay consistent).

Page 24: "unlikely to cause deliverability or usability problems": in the
absence of wide support, there is a high likelihood that messages will be
flagged by anti-spam systems or reported as spam by end-users.

Page 26: Where is "cryptographic summary" defined? This seems like a new
notion here.

Page 26: "Updating the Cryptographic Summary": going header by header may
be problematic for something presented as a summary. Given this is "complex
and messy", do we really want to include this unclearly defined part in the
RFC?

Page 27: "Example Signed-only Message with Injected Headers": I thought we
defined earlier that hcp and legacy are effectively ignored if crypto does
not contain encryption, so Signed-only should NOT have injected headers.

Page 28: "Do Not Render Legacy Display Elements": training end-users to
trust the email HTML body seems like a way to mislead recipients.

Page 29: Typo: "MIME subpart with within the" -> "MIME subpart within the"

Page 30: MUA would typically not allow the styles and CSS to propagate like
this. More likely the MUA should use an HTML sanitizer that will explicitly
target those.

Page 31: "should improve the system's security": complexity of standard may
go against that goal also until reaching mass adoption, security will
likely still be limited by the most common denominator.

Page 32: Typo: "decrypts the incoming mssages" -> "decrypts the incoming
messages"

Page 32: "adjust the status of a tracked issue by a specially-formatted": I
think such design would need a LOT more attention, for instance avoiding
replay attacks.

Page 33: "pEp": can we simplify and obsolete to focus on minimizing
complexity and bugs?

Page 35: "ignore any unprotected header fields": did we consider the risk
associated with leakage of MUA capabilities by getting different behavior
when the user replies?

Page 36: "MUA MAY prefer to verify that the header fields in question":
which MUA are verifying DKIM themselves? This is not standard and likely to
be very brittle.

Page 37: "Dropping Legacy Display Elements": it is hard to envision
backward compatibility that will not have to last forever for email.

Page 46: "intervening transport agent to drop the message entirely": where
did you observe that non-standard behavior? It is extremely common to
deliver emails without the recipient in To/Cc/Bcc fields (mailing lists,...)

Page 46: Typo: "Bcced" -> "Bcc'ed"

Page 54: Link to https://header-protection.cmrg.net which has an expired
certificate (Expires On Sunday, March 5, 2023 at 12:34:10 AM).

Page 54: "Test Vectors" while it is great to have so many vectors here, I
feel we should have better IETF infrastructure for hosting those rather
than being painfully paginated, indented and taking 2/3 of the document
length. Consider providing tooling allowing extraction of all the samples
in the RFC (which would help verifying they are correct).

Generally, given this mechanism is potentially breaking traditional MUA
capabilities based on headers, are we suggesting for the MUAs to decrypt
and interpret emails as soon as they are delivered (not waiting for the
end-user to open the messages) and possibly persist the decrypted headers
to be able to provide normal MUA capabilities (sort, filter,  search,...)?
This may be problematic for end-users that store cryptographic materials on
a separate hardware device and/or require interaction for each
cryptographic operation.

Take care,

Nico


On Fri, Apr 7, 2023 at 7:53 AM Russ Housley <[e-mail]> wrote:

> Title: Header Protection for Cryptographically Protected E-mail
>
> Authors: D. K. Gillmor, B. Hoeneisen, A. Melnikov
>
> Datatracker:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection
>
> Please respond to this WG last Call by 21 April 2022.
>
> For the LAMPS WG Chairs,
> Russ
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>