Re: [lamps] WG Last Call for draft-ietf-lamps-header-protection and draft-ietf-lamps-e2e-mail-guidance

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

Hi Nicolas--

Thanks for your notes, they make the draft better!

I'm responding to them point-by-point inline below, but i wanted to
first address the overall issue you raised here:

> Overall, I would still prefer the RFC to focus on a specific objective
> (Subject protection) and simplicity of implementation rather than maximal
> flexibility and the ensuing complexity (and bugs).

We did discuss this in the working group.  While I agree with you that
it would be nice to just have the narrow scope, sadly, Subjecta
confidentiality is not sufficient.  There are numerous situations where
cryptographic integrity is useful for non-Subject headers (e.g. being
able to detect tampering of the sender's To/Cc list by transport agents,
or ensuring that other security-relevant headers added by the MUA are
cryptographically signed), and other prospective headers that may
eventually warrant confidentiality protection (e.g. the work represented
by draft-dkg-mail-cleartext-copy -- it's not clear that there is a good
reason to advertise on the outside of the cryptographic envelope that a
cleartext copy of this message may exist).

So, while i share your wish to have something simpler, it wouldn't
address the underlying need.  We need to address the whole thing.

On Tue 2023-09-19 00:41:25 -0700, Nicolas Lidzborski wrote:
> 1.4.1.  Backward Compatibility
> Could we rely on advertised capabilities to simplify this?
> In particular, RFC 4262 (X.509 Certificate Extension for S/MIME
> Capabilities) would enable a sender to advertise that no backward
> compatibility is necessary.

Signalling has come up a few times in this discussion -- I've started a
separate thread on this list about why it's not needed for header
protection.   i hope any further discussion can happen over there.

> 1.5.  Other Protocols to Protect E-Mail Header Fields
> DKIM+DMARC: Nit: I would clarify that first and foremost, they provide
> (DNS-based) protection against impersonation of sender's domain.

The current text already says "This pair of protocols provides a
domain-based reputation mechanism that can be used to mitigate some
forms of unsolicited e-mail (spam)."  I think this means the same thing
you're saying, but if you want to propose additional clarify text, or a
concrete change, i'd be happy to consider it.

> 1.8.  Terms
> Header Field: the short definition does not seem to cover multi-line
> headers / Long Header Fields.

I agree that the current wording is ambiguous and could be misread in
the way that you describe, even though it does explicit reference RFC
5322 for the more formal definition.  Alexey offered to draft a small
textual change to make it clearer.

> 2.3.2. Header Confidentiality Policy
> Is there a really strong use-case for a configuration policy language?
> Would it be more beneficial to standardize a simpler mechanism

The HCP construct is not for users to manually program it, nor will it
ever appear on the wire anywhere.  it's not even a formally defined
language.  The purpose of the HCP is to encourage communication between
MUAs about their current intent.

"hcp_minimal", the recommended default, is exactly the simpler approach
that you're asking for (confidentiality for Subject, no confidentiality
for anything else).  But it's entirely possible that someone will
propose an HCP with improved confidentiality characteristics and no
significant downsides as the mail ecosystem evolves.  We're trying to
make it easier to talk about these choices.

Even without an explicitly declared HCP, a sender *could* generate a
message with more header fields made confidential than a Subject line,
and the recipient would need to think about how to deal with those
things.

If any impementer wants to ignore "HCP" and just protect the Subject
line's confidentiality for new encrypted messages, that should also
work!

> 2.3.4.2.  Adding a Legacy Display Element to a text/html Part
> Should RFC explicitly specify HTML syntax and named classes?

I don't think it's necessary to explicitly specify HTML syntax here, or
to define any named classes other than the
header-protection-legacy-display class, which *is* explicitly defined.
Do you want to propose text?

> Should we specify versions for compatibility?

I'm not sure what this means.  are you talking about versions of HTML?
or versions of the legacy display element?  (i can't imagine having
multiple versions of the LDE -- it will either be used, or not used, but
it shouldn't change)

> 2.3.4.2.1.  Step-by-step Example for Inserting Legacy Display Element to
> text/html
> Same as 2.3.4.2 above but specifying HTML parsing logic.

Again, i don't think this is the right draft for specifying HTML parsing
logic.

> 2.3.4.4.  Do Not Add a Legacy Display Element to Other Content-Types
> "The authors are unaware of any legacy client that would render any MIME
> part type other than text/plain and text/html as the Main Body."
> https://amp.dev/documentation/guides-and-tutorials/email/start/create_email
> :-(

Thanks for this pointer!  I hadn't seen this, and the reference you've
provided doesn't actually talk about MIME structure at all.  It reads
almost like it's recommending how to produce the text/html part of the
message.

But looking through my mailbox, i do see a handful of messages that try
to do this, using a content type of text/x-amp-html.  But i don't know
where this is standardized or even casually written down.

I would think that if you are generating an AMP main body part for a
multipart/alternative, you'd treat it exactly the same way as a
text/html body part.  Is that right?  Would you care to offer
suggestions for how to add an LDE to a text/x-amp-html body part?  How
many MUAs actually interpret this part as the main body part?  If there
aren't many, and those MUAs can be updated to properly handle the actual
Injected Headers approach appropriately, then maybe there's no need to
specify an LDE for text/x-amp-html.

> 2.4.1.  Minimal Header Confidentiality Policy
> I feel that cleaning out the Subject is well understood and the most
> realistic option. Would only focusing on this reduce the complexity and bar
> for MUA to adopt this?

I don't think it reduces complexity for the reasons described above: a
receiving MUA could still encouner a message with arbitrary header
fields removed or obscured, and it would need to figure out what to do
with it.  The text in the draft describes what to do, even if there is
no mention of different HCPs.

> Should the naming be more explicit to mention the subject?

I think you're asking to rename hcp_minimal to something like
hcp_obscure_subject_only -- that might have been a reasonable thing to
do early on in this draft, but at this point it doesn't feel worthwhile
to me.  We can easily rename it if the WG wants, but having two names
that point to the same thing just seems likely to cause confusion rather
than adding to the clarity.

> 2.5.  Receiving Side
> Cryptographic summary creates a dependency of a standard RFC on an
> informational RFC (
> https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/).

You're describing a downref, but i'm not convinced that is a problem.
For example, CFRG drafts are informational (see RFC 7748) and yet they
are regularly normatively referenced by standards-based drafts.

Removing the reference seems worse than keeping it to me, as the
reference (about cryptographic e-mail structure) is definitely relevant
in its current location.

> Should the rendering of messages be moved entirely into informational RFC
> as those tend to vary based on providers, user expectation and device type
> where the message is rendered?

The commentary about rendering is relevant specifically to usability
related to header protection.  it belongs alongside the description of
header protection.

> Generally, the whole section is not using MUST/SHOULD/MAY except in a few
> subsections.

Right.  These are not necessarily RFC 2119 requirements, but they
describe how to deal with the messages, and they are likely going to be
subtly different in different MUA contexts.  If you have specific
instances where you think we should use RFC 2119 language, i'd welcome
pointers/suggestions.


> 3.1.  Dropping Legacy Display Elements
> Is there a point to specify this at this stage? Maintaining a "legacy"
> parameter is additional complexity for implementations.

The draft explicitly says "How a MUA determines the value of `legacy` is
out of scope for this document; an initial implementation can simply set
it to `true`" -- hopefully this reduces the complexity ☺

> 3.2.  Stronger Default Header Confidentiality Policy
> Do we have a real commitment by significant MTAs beyond subject header
> confidentiality?
>
> 3.3.  Deprecation of Messages Without Header Protection
> Is this section necessary? It seems hypothetical.

These are all grouped into section 3, "E-mail Ecosystem Evolution".  By
definition, this section is speculative and (in some cases) hopeful, but
as the saying goes, "prediction is hard, especially about the future".

It's still relevant to the draft, though, because this draft is written
with an eye to deployment and impact.  that impact won't happen this
month, it will happen *if* there is reasonable adoption among e2e mail
implementations.  It would be a mistake to ignore the risks and
opportunities presented by such a future just because it's not assured
to happen.

Hopefully some of this text will also motivate developers to ride (and
build) the wave of adoption and deployment.

> 4.  Usability Considerations
> Should it be moved entirely to ietf-lamps-e2e-mail-guidance as it is
> expressing UX opinions ("overlay a warning flag" for example)? We discussed
> that back in April, but I did not push further.
> I would expect many MUA to work with UX experts and usability studies to
> work on the most effective ways to communicate to end-users. As we have
> seen with HTTPS, there will likely be some iterations on how to adequately
> represent security concepts to end users.

I absolutely agree with you here: MUA developers (especially e2e MUA
developers) need UX expert guidance, and there's nothing in the text
that mandates any particular kind of signalling.  The text even points
to the HTTPS indicators explicitly (the "chrome-indicators" reference)
as one possible path to look to for inspiration.  But the usability
considerations in this draft are specific to header protection, so they
belong here, not in e2e-mail-guidance.

> 5.  Security Considerations
> Are there options we could follow to make things more secure by design?
> For example, should we mandate a specific encoding for the Subject?

I'm not sure what you mean specifically by "encoding" -- are you talking
about RFC 2047-style encoding, or choice of character sets, or something
else?  Is there concrete text you'd like to add?

> 5.1.  Caution about Composing with Legacy Display Elements
> The reason for escaping is not security but rather enabling proper
> rendering.
> It is not really a specific security risk as rendering clients are already
> well versed in sanitizing HTML.

I disagree with you here.  When Alice replies to Bob's mail, her MUA
typically copies the text that Bob put in the Subject line into her
reply's subject line.  That means that Bob's MUA is at risk from
attacker-supplied input, which is a classic security concern.

> What do you mean practically by "conservatively and narrowly" in "When it
> is produced, it should be generated conservatively and narrowly, to avoid
> damaging the rest of the message."?

Thanks for noticing this potential vagueness.  The earlier text in this
section specifically describes narrow and conservative handling for
text/plain (stripping newlines) and text/html (html escaping).  the
"conservatively and narrowly" text is the general rule across content
types, but the earlier text is the explicit guidance.  I've added "as
described above" to make that clearer.

> 6.1.  Encrypted Header Fields Are Not Always Private
> I think the title in the privacy section is a bit more worrisome than the
> reality in "2.5.2.  Updating the Cryptographic Summary" that covers the
> Encrypted Headers states explicitly, including the excellent example of
> "Date" header for signed-only.

Good call that we should make this a bit clearer.  I'm proposing the
following change to make this more explicit:

--------------
diff a/draft-ietf-lamps-header-protection.mkd b/draft-ietf-lamps-header-protection.mkd
--- a/draft-ietf-lamps-header-protection.mkd
+++ b/draft-ietf-lamps-header-protection.mkd
@@ -1162,15 +1162,17 @@ When it is produced, it should be generated conservatively and narrowly, as desc
 
 # Privacy Considerations
 
-## Encrypted Header Fields Are Not Always Private {#encryption-vs-privacy}
+## Some Encrypted Header Fields Are Not Always Private {#encryption-vs-privacy}
 
-For encrypted messages, depending on the sender's HCP, some header fields may appear both within the Cryptographic Envelope and on the outside of the message.
-{{crypto-summary-update}} identifies those messages as `signed-only`.
+For encrypted messages, depending on the sender's HCP, some header fields may appear both within the Cryptographic Envelope and on the outside of the message (e.g. `Date` might exist identically in both places).
+{{crypto-summary-update}} identifies such a header field as `signed-only`.
 These header fields are clearly *not* private at all, despite a copy being inside the Cryptographic Envelope.
 
 A header field whose name can be found in the `HP-Removed` or in any `HP-Obscured` header field from the same part will have `encrypted-only` or `signed-and-encrypted` status.
 But even header fields with these stronger levels of cryptographic confidentiality protection might not be as private as the user would like.
 
+For example, even if the `Date` header field has been obscured, for example by normalizing the timezone to UTC or rounding to the most recent minute or hour (so that header field is formally `signed-and-encrypted`), the MTAs which handle the message can of course record the time that they first encountered it, which is likely to be identical or very close to the original value of the field.
+
 ## Header Fields Can Leak Unwanted Information to the Recipient
 
 For encrypted messages, even with a powerful HCP that successfully obscures most header fields from all transport agents, header fields will be ultimately visible to all intended recipients.
--------------


> 6.2.  Header Fields Can Leak Unwanted Information to the Recipient
> Should we simplify the explanation with the fact that the senders' MUAs may
> behave differently and leak identifying information explicitly (for example
> software version) or implicitly (with the way encrypted content, not just
> the headers, is generated)?

I think this text is clear by being as specific as it is, because it
points to concrete examples.  If you want to propose some changes that
would simplify we'd be happy to consider them.

> I am not sure this is the right section for "erroneously include a Bcc
> header". If this is a concern, it should belong in the security section and
> explicitly ask senders MUA to prevent this.

A leaked Bcc header isn't as much a security concern as it is a privacy
concern (a leakage of information that the sender does not intend to be
exposed).  If you want to propose a concrete change we can review, but i
think this is already a sensible place to point out the concern.

> 6.2.1.  Encrypted Header Fields Can Be Inferred From External Metadata
> The RecipientInfo is already going to provide a very good idea of the
> specific recipients, no?

Absolutely right. I'm proposing adding this text:

--------------
diff a/draft-ietf-lamps-header-protection.mkd b/draft-ietf-lamps-header-protection.mkd
--- a/draft-ietf-lamps-header-protection.mkd
+++ b/draft-ietf-lamps-header-protection.mkd
@@ -1188,10 +1188,11 @@ Instead, the composing MUA MUST judiciously populate the `origheaders` list for
 This is true for messages without any cryptographic protection as well, of course, and it is even worse there: such a leak is exposed to the transport agents as well as the recipient.
 An encrypted message with header protection and a strong header confidentiality policy avoid these leaks exposing information to the transport agents, but cannot defend against such a leak to the recipient.
 
-### Encrypted Header Fields Can Be Inferred From External Metadata
+### Encrypted Header Fields Can Be Inferred From External or Internal Metadata
 
 For example, if the `To:` and `Cc:` header fields are omitted from the unprotected header section, the values in those fields might still be inferred with high probability by an adversary who looks at the message either in transit or at rest.
 If the message is found in, or being delivered to a mailbox for `[e-mail]`, it's likely that Bob was in either `To:` or `Cc:`.
+Furthermore, encrypted message ciphertext may hint at the recipients: for S/MIME messages, the `RecipientInfo`, and for PGP/MIME messages the key ID in the Public Key Encrypted Session Key (PKESK) packets will all hint at a specific set of recipients.
 Additionally, an MTA that handles the message may add a `Received:` header field (or some other custom header field) that leaks some information about the nature of the delivery.
 
 ### HCP May Not Mask All Data in an Encrypted Header Field
--------------

> 6.3.  Privacy and Deliverability Risks with Bcc and Encrypted Messages
> Should the RFC be more forceful of one choice to simplify design and reduce
> risks?

I don't think this draft is the right place to try to enforce any
specific rule for Bcc.  i agree that it would be great if there was only
one way to do it, but the fact is that there are several approaches in
the wild and they have different tradeoffs.  I think some recent
discussion in emailcore butted up against this issue, and they were
unable to narrow the field there.  And this isn't really the right place to
try to tackle that problem anyway, even if we could :/


I've pushed the above mentioned clarifying changes to git, but haven't
yet released a new draft.  I'll do that next week if folks are ok with
the changes and i don't see any more requests for edits coming in.

All the best,

    --dkg