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

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

Hi Nicolas --

Thank you for your close read, and this useful feedback.

You caught many typographical and structural details which i've fixed
directly without commentary.  Thanks for pointing them out!

Several of your comments warrant more discussion, which i'm supplying
in-line below.  Hopefully it didn't get too long!

On Fri 2023-04-21 15:22:45 -0700, Nicolas Lidzborski wrote:

> 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.

I agree with you that splitting the header-protection mechanism from
broader UI/UX concerns is a good idea.  That's already done, in some
sense, in that this document's neighbor
(draft-ietf-lamps-e2e-mail-guidance) provides significant UI/UX
commentary and already explicitly contemplates being revised (it's not
"set in stone" in the way that the wire-format mechanisms have a
tendency to be).

Bernie and Alexey and I think that what UI/UX guidance there is in the
header-protection document is minimal and non-normative.  the draft
describes how to structure and how to interpret the wire formats, but
is pretty loose about rendering or behavior.

If there are specific UI/UX elements in header-protection draft that you
think are too specific, please let us know.  We can consider moving them
to draft-ietf-lamps-e2e-mail-guidance, but i think that the split is
already reasonably decent..

> 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.

The draft defines both schemes to ensure that they can all be readable,
but the Injected Headers scheme is the only MUST implement for
generation.

This is already present in the text, but I've added clarification about
it up front in the "Two Schemes of Header Protection" section of the
introduction.

> 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.

Agreed, the Wrapped Message scheme is very sparsely implemented, but
these messages do exist.  The draft tries to acknowledge this while
still prioritizing the Injected Headers scheme, since it appears to be
less problematic.  But i don't think we can simply ignore the existence
of the other scheme because ther are indeed some implementations which
generate it.

> 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.

Makes sense, thanks for catching this.  the draft now says "some cases"
instead of "worst cases".

> 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)?

I'm not sure whether i understand your proposal here. I see two ways
that you might mean it:

 a) maybe you're suggesting having an independently-decryptable
    EncryptedSubject header that is distinct from the message body.
    This is problematic for several reasons, including that it can (at
    least naively) be severed from the message (and maybe spliced onto a
    different message); it doesn't cover the possibility of providing
    encryption for other headers; and it doesn't address cryptographic
    signature protections, only encryption.

 b) you might mean that we could label the header field that lands
    inside the cryptographic envelope "EncryptedSubject" instead of
    plain old "Subject".  It's not clear what the benefit of this would
    be over the current scheme (and it's also only about encrypting, and
    only about the subject, while the schemes described here handle
    signing as well, and other header fields)

We did actually consider both of these possible designs in the course of
working through the problem space, but the current draft seems better in
in all respects.  Did you mean it some way other than (a) or (b)?

> 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.

The document states that triple wrapping is out of scope, *not* that it
is in any way unacceptable, deprecated, or made obsolete by ths draft.
Triple-wrapping is a perfectly fine way to provide authenticated headers
for intervening transport agents, even in the face of end-to-end
encrypted messages, for example.

I've adjusted the language in the "Out of scope" section that referred
to all of the other forms as "unusual (and tricky)" (which is true about
some of the other categories of out-of-scope messages, but maybe isn't
about triple-wrapping) so that hopefully it's not seen as a dismissal.

> Page 16: Can you explain better the role of the HP-Removed and HP-Obscured
> headers?

Good call -- i've put a short explanation and a link to the relevant
subsection of privacy considerations (overestimating the status) at the
point where HP-{Removed,Obscured} are introduced.

> Wouldn't it be simple to just have the encrypted headers just
> override the external headers?

The encrypted headers do indeed override the external headers.  That's a
deliberate choice, and i'm glad you agree. :)  If you think the draft
says something else, can you please point to it?

HP-Removed and HP-Obscured are present so that tampering with the
*external* headers can't cause the recipient to misinterpret whether
headers were deliberately obscured during sending or not.

> 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.

I think your main complaint here is about the inclusion of the Legacy
Display Elements.  None of the editors of the draft are super happy with
this either, but testing and experimentation didn't turn up any other
options that wouldn't cause complicated breakage for legacy clients.

The Injected Headers scheme *without* the Legacy Display Elements works
perfectly fine with every existing cryptography-capable MUA we've been
able to test with; its only drawback is that any hidden headers can't be
seen, and LDEs are the workaround for that.

That said, in the "E-mail Ecosystem Evolution" section, we do explicitly
contemplate a future where "Legacy Display Elements" are unnecessary.
In that scenario, either the crypto-capable MUAs have been updated, or
they've died off, so implementers can set the "legacy" flag to "off" and
leave it that way.  Some implementers might decide to set the "legacy"
flag to "off" anyway, and accept the risk that some recipients won't see
the Subject.

> 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.

We are uncomfortable with this too, but we don't have a better way of
doing it.  However, i don't see how these modifications will break any
user expectations of what is being signed any more than, say, assembling
a multipart/alternative message body and signing it, when most users
don't understand that structure either.  If anything, signing a message
that explicitly *includes* the Subject line is probably closer to what
most e-mail users think is happening than what happens without header
protection.

> 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).

The draft doesn't prohibit any MUA from adding new headers, new UI
elements, or new UX patterns.  But if the last ~25 years of trying to
launch encrypted e-mail tells us anything, it's that relying primarily
on "user training" and asking users to think about the technology itself
to achieve security results doesn't work very well.

I think you're proposing here that when composing a message that might
be encrypted, the user should be asked "what should the cleartext
subject be?"   Even as someone who understands all of the mechanics, and
who writes a fair amount of e-mail, i can't imagine how i would decide
what i'd put into such a textentry widget.  I'm just trying to send
mail!

I don't think this standard is the place to add new burdens on the user
who is trying to send mail, though if you wanted to propose a pattern
like that someplace else, i'd be happy to review it.

> 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.

Are you saying that there's a high likelihood that an encrypted message
with minimal_hcp applied will get flagged by anti-spam systems?  We
think that hcp_minimal will be *less* likely to be flagged than other
proposals, but i'd be interested in learning more.  If we're asking
users to fill in a "cleartext subject" field for each message just for
the sake of getting through a spam filter, that seems problematic to me.
It sounds like the filter is demanding access to potentially private
information in exchange for message deliverability.

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

Good catch!  This term is used in e2e-mail-guidance (and explicitly
labeled as a term of art in the latest version of that draft), and i've
updated the header-protection draft to refer specifically to that
definition.

> 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?

The sense of the working group that i've seen in discussions around this
is that it's messy and ugly, but it appears to be the state of the
world.

I've added text to the top of this section that acknowledges that all of
this complexity doesn't need to be exposed to the user, but is instead
focused on the concepts that the MUA needs to make reasonable decisions
to do things like avoid leaking confidential data in a reply.

> 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.

"Injected Headers" is the structural scheme (as opposed to the "wrapped
message" structural scheme).  For encrypted messages, it permits but
does not require Legacy Display Elements.  It's still useful (without
Legacy Display Elements) for signed, unencrypted messages.

I've added a sentence to these two sections calling out the
presence/absence of Legacy Display Elements.

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

I don't think this document asks end-users to "trust" anything.  Do you
have any suggestions for how to change these directives?

> 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.

The CSS was meant to be an example, not a requirement.  I've added a
line that suggests using an HTML sanitizer as an alternative example.

> 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.

We agree that the security of the system is gated by the weakest
implementation, but I'm not sure how that's relevant to the text in this
section.  The goal of the section is to improve the behavior of
automated systems that operate on cryptographically-protected e-mail,
and of course they can't change what their peers do; they can only
change what they can do, which should provide incentives for their peers
to upgrade and improve as well.

> 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.

I agree, but the cited line is basically an example for how to apply the
protections offered by this draft to an automated system, and the doc
doesn't claim that the design is either complete or normative.

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

This document explicitly disclaims any normative commentary about these
drafts (and the editors and the WG may not even agree on their general
merits).  The subsection is just a pointer to other work that an
implementer who wants to be able to read other message formats can use
as a reference.

> 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?

Can you clarify what you mean by this?  We are certainly concerned about
information leakage, which why the document tries to standardize
behaviors.  The leakage of "what MUA am i using" is a concern, of
course, but any leakage of the user's intended confidential content
seems much worse.

I think by normalizing standard behavior (as the draft attempts to do)
we can improve on both forms of leakage.

> 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.

I've added an informative reference to ARC-Authentication-Results (RFC
8617) here, as that may be more meaningful to a MUA than DKIM-Signature.
That said, I agree that these things are likely to be brittle, as
they're intended for consumption by transport agents.  In the event that
these transport-added signatures cannot be validated, the consequence is
that the receiving MUA won't act on them as though they were
cryptographically assured.  This seems like the right tradeoff, given
that this is all in a "MAY prefer to…" clause anyway.

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

Agreed!  this is the case for any store-and-forward system like e-mail:
backward compatibility for reading might be infinite.

However, for generating messages, we do have some hope about being able
to deprecate mechanisms.  That's the point of the section you've linked
to here: how can we imagine evolving the ecosystem in the future?

> 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,...)

Messages get dropped or quarantined all the time for a variety of reasons,
including systems that have scoring capabilities where a factor like not
having the mailbox owner as a named recipient counts against the message
(or where being *explicitly* named counts *for* the message).

The editors of the document agree with you that messages lacking the
appropriate address in the To/Cc/Bcc fields are fairly common.  We hope
that implementers will experiment with more advanced HCPs and publicly
document the ones that do not impair deliverability.  We're fine with
sticking with hcp_minimal for this document now, though.

> 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).

Yeah, we had IETF 116 already had this discussion, and the sense was
that it was better to keep them in the draft, despite the length.

I've encouraged the datatracker to make documents with long appendices
less intimidating generally:

   https://github.com/ietf-tools/datatracker/issues/5457

And it occurs to me that the datatracker could also make it easier to
extract those samples:

    https://github.com/ietf-tools/datatracker/issues/5544

Even if the datatracker doesn't make those changes, the sample files are
also accessible in the git source for the project:

   https://gitlab.com/dkg/lamps-header-protection/-/tree/main/header-protection.maildir/new

And they also remain available from https://header-protection.cmrg.net/
as maildir tarball, mbox, individual .eml files, and via IMAP.
If anyone wants to poke at them with their MUA, i think these are
reasonably accessible.

> 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.

I agree that traditional MUA capabilities based on headers will need to
be based on the protected headers.  All the more reason for
implementations to adopt this draft earlier rather than later.

But as encrypted messages increase in volume (which is the goal of this
work), the same is true for more than the protected headers.  Filter and
search in many MUAs today work on the message structure and contents,
not just headers.

draft-ietf-lamps-e2e-mail-guidance calls out "Indexing and Search of
Encrypted Messages" as an area of future work and discussion.  It'd be
great to have your insights added there if you're up for it.

Regards,

        --dkg