Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-e2e-mail-guidance-15: (with DISCUSS and COMMENT)

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

Hi Paul--

Thanks for this detailed review of
draft-ietf-lamps-e2e-mail-guidance-15.  Comments and feedback inline
below.  I've also proposed a handful of edits offering
improvements/clarifications/future work to the draft in git at
https://gitlab.com/dkg/e2e-mail-guidance/

Paul Wouters wrote:
> The document suggests that encrypted but unsigned messages should be
> considered a bug and prevented. However, at times I purposefully send
> encrypted but unsigned mesages as a way to not give someone mathemathical
> proof that I said something. Sort of a "gossip message" or within
> proprietry clients this could be a "auto-destructing message". By
> blocking this usage, I would in the future have to opt for sending
> a non-encrypted message if I am unwilling to sign a message.

I think what you want here are also known as "deniable" messages.  On
more sophisticated platforms (e.g., OTR), those messages are still
authenticatable by the recipient (because they are authenticated with an
established shared secret between the pair of communicants), but they
are repudiable by both parties involved because either party can claim
the other party generated the message.

The fact that the messages are authenticatable is critical for many of
the systems that use e2ee mail, including things like verification of
protected headers.

However, there are no standardized mechanisms for producing
authenticatable-yet-repudiable e-mail messages in 2024 that i'm aware
of.  Encrypted-only messages do not meet this requirement, because they
are not authenticatable by the recipient.  Rather, they are trivially
forgeable by someone outside the conversation.

Even if we did have a standardized mechanism for providing
authenticatable-but-repudiable e-mail messages, it's not clear what the
actual use case for this is.  If the concern is repudiation in front of
a third-party arbiter that is bound by law, most of those arbiters are
just fine accepting "cryptographically deniable" evidence as evidence
(e-mail messages with no e2e cryptographic protections have been
introduced in court cases in every jurisdiction i'm aware of).  If your
concern is a third-party arbiter who is not bound by law, then i'm not
sure why they would care about cryptographic claims of repudiation.

At any rate, this document tries to offer guidance on strong, usable
end-to-end cryptographic protections of e-mail messages.  Offering the
user the opportunity to generate non-authenticatable messages requires
(a) presenting another choice that most users are not prepared to make
or understand, and (b) makes it harder for the recipient MUA to reason
about messages.  That's why the document strongly discourages this
choice.

> Section 6:
>
>         the certificate used to verify the signature does not
>         correspond to the author of the message. (for X.509, there is no
>         subjectAltName of type rfc822Name whose value matches an e-mail
>         address found in From: or Sender:)
>
> So how about:    From: "Daniel Kahn Gillmor <[e-mail]>"   ?

The document currently treats the e-mail address as the sender identity,
and doesn't grapple with the human-readable name at all.

I've opened https://gitlab.com/dkg/e2e-mail-guidance/-/issues/14

> Section 9.1 talks about storing Sent Mail encrypted, but does not
> talk about how one would "search" their email content. Perhaps it
> can also mention keeping a Sent Mail folder on the user's own device,
> such as a laptop with whole disk encryption. But I feel not mentioning
> this issue at all is missing an important point of why people want
> decrypted Sent Mail or why they don't want encrypted Sent Mail.

You're right that this is a serious issue, but the document does touch
on these concerns (albeit without trying to mandate a particular path
forward), in the "future work" appendix:

https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-15.html#name-indexing-and-search-of-encr

If you want to propose more text to add to that section, I'm happy to
review.

> Section 9.4 asks:
>
>         When a message is encrypted, if there is a mechanism to include
>         the certificates of the recipients, whose certificates should
>         be included?
>
> I think that answer is always "not the BCC'ed recipients", so I wonder
> why this is a question and not a requirement. Also the last bullet in
> 9.4.1 states that too. Maybe restate it as a description to solve in
> 9.4.1 by saying it more like "When a message is encrypted and recipient
> certificates are included, the Bcc:ed recipients need to be carefully
> considered".

Section 9.4 starts with a list of questions that need answering.
Section 9.4.1 provides one straightforward and internally coherent set
of answers for all of those questions, and 9.4.1.1 provides a rationale
for that approach.

There could be other approaches which provide an internally coherent and
satisfying response to these open questions, but this document doesn't
try to weigh in on them.

> Section 9.4.1:
>
>         * No cryptographic payload contains any Bcc header field.
>
> Since headers are not encrypted, isn't this always the case?

Headers are included in the cryptographic payload, because section 9.3
mandates the use of draft-ietf-lamps-header-protection.

>         * The main copy of the message is signed and encrypted to all
>         named recipients and to the sender. A copy of this message is
>         also stored in the sender's Sent folder.
>
> Maybe this should more clearly state that it includes the BcC: header?

What includes the Bcc header?  As i read it, the main copy described
here does *not* include the `Bcc` header field, as the Bcc'ed parties
are neither named recipients nor the sender.

>         * To the extent that spare certificates are included in
>         the message, each generated copy of the message should
>         include certificates for the sender and for each named
>         recipient. Certificates for Bcc'ed recipients are not included
>         in any message.
>
> So here is another possible leak. Earlier text said certificates could
> be omited if one knew for sure the parties already knew each other's
> certificate. So if the sender and recipient know each other's certificate,
> but the sender doesn't know if the Bcc:ed recipient knows the (openly)
> recipients certificate, it must not add the certificate or else the Bcc:
> to "someone" becomes exposed to the recipient. I think the bullet point
> is better reframed as "Any Bcc:ed recipient MUST NOT be taken into
> consideration when determining which certificates to include along the
> message.".

Good catch, thanks.  I've opened https://gitlab.com/dkg/e2e-mail-guidance/-/issues/15

> Section 9.6 it seems option 1 and 2 are really not worth considering
> or mentioning. It also seems a 5th option is missing - compose two
> seperate emails with only the seperated recipients in each of the emails.

I think option 2 is definitely worth considering.  In the situation
where a message must be encrypted, and one of the recipients' keys have
been revoked, for example, it may be critical to exclude that recipient.

I'm unconvinced by your proposed 5th option, which I think opens a large
can of worms that i don't know how to close.  Would the two messages
have different Message-IDs or would they share a message ID?  If any
recipient replies-all, would they know that they are replying only to a
subset of the conversation?  Would the sender be the only one with
full visibility into the range of participants?  Is there any precedent
for an MUA that facilitates this sort of approach?

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 2:
>
>         so interface elements that get in the way of communication should
>         be avoided where possible.
>
> That "in the way" carries a lot of weight :P

changed to "interferes with", but… yeah, that is definitely a
challenging metric either way.

>         on every alternate messaging service
>
> Maybe remove "alternate"? or so "on all of the many" ?

I think we can change that to "on the various non-e-mail messaging services".

>
>         For comprehensibility, a conformant MUA SHOULD NOT create multiple
>         copies of a given message that differ in the types of end-to-end
>         cryptographic protections afforded
>
> Can it be clarified whether this is meant "to the same email user" ?
> A message send to multiple people, of whom only a subset support
> encryption, should still send "multiple copies of a given message
> that differ in the types of end-to-end cryptographic protections

The text does not mean "to the same user" -- it deliberately means (and
i think says clearly) "per message" in order to provide a coherent view
to all participants of what kinds of cryptographic properties to
associate with a given message.

Do you want to propose text that would make that even clearer?

The user's typical mental model is that there is a single e-mail message
that is potentially available to multiple parties.  the question "did
Juliana get this e-mail?" is a reasonable, understandable, and
answerable question for normal users; yet it relies on this unstated
assumption.  If we want users to understand the protections they are
getting (which i think is critical if you really want robust end-to-end
cryptographic protections), we should be discouraging behavior in the
underlying system that breaks the users' assumptions about what is
happening.

>         For example, the sender cannot indicate via SMTP whether or not a
>         given message should be encrypted (some messages, like those sent
>         to a publicly archived mailing list, are pointless to encrypt)
>
> Clearly, the mailing list would not have a valid certificate to use to
> encrypt, so how could it ever encrypt? Also a mailinglist could have
> given all members the list private key so members can decrypt all messages
> sent encrypted to the list. This might not be super secure, but a reasonable
> approach for "somewhat secret" list traffic, eg a vendor security vulnerability
> mailing list.

There are mailing lists which do have valid certificates (though they
typically are not publicly archived).  The document doesn't get into
details about mailing lists with cryptographic protections, but we could
add something to the Future Work appendix if folks are interested.  I've
opened https://gitlab.com/dkg/e2e-mail-guidance/-/issues/16 to track that.

> NITS:
>
> Petpeeve: the use of the word "novel".

I'm fine with changing that word to avoid a pet peeve :)  I hope you'll
avoid "utilize" in any future documents on my behalf in exchange!

> non-comment:
>
> It seems the authors do not like my openpgpkey-milter solution :)

Your milter is not the only software i've seen that takes this tempting
shortcut!  ☺ Do you think that any of these implementations can
effectively avoid the pitfalls described in that section?

         --dkg