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

[Paul Wouters <[e-mail]>]

On Thu, Mar 14, 2024 at 6:48 AM Daniel Kahn Gillmor <[e-mail]>
wrote:

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

I am not sure I'd agree with "critical". I see it more as a user option, a
choice
of the sender to hand out such cryptographic proof or not. There is an
unmistakable difference if we sit at a bar and I tell you "Roman is
impossible to
work with", versus a crypto graphically signed message of the same. In other
words, mandating digital signatures can surely stifle free speech via email.


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

We don't disagree here.


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

The choice of medium can be based on the informal vs formal nature of it.
A slack message can be a lot more informal than an email. Or a text
message can be seen as informal too. Or a DM on various platforms.

My concern is that you are raising the informality of email to a new
formality that is not what some people come to expect of it.


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

"Warning: this message was encrypted but not digitally signed. It could be
a forgery".

I'm not sure if the IETF should step too deep into the UI parts. I'm mostly
pushing back at you trying to make sending encrypted unsigned messages
a MUST NOT. If you could quantify that, I would be much happier.


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

But how useful is the advise of this draft if all these out of scope things
are
not part of the discussion?


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


I see you addressed it in
https://gitlab.com/dkg/e2e-mail-guidance/-/commit/fc7fe640873e2725e2d43c5381975acc59cd45f7
Thanks!

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

I guess the text you have is fine.


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

I guess it is a style issue, so I will drop my complaint on this.


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

Ah I missed that. thanks.


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


Thanks.

> 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'll drop my issue on this.


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

I don't understand "per message" for example in the context of BCC:s,
where the message to different people have different headers.


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

I can't because I dont fully understand what you are trying to coney.


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

I'm not sure I agree, but it's surely not a DISCUSS level item.


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

I see the commit. Thanks for adding the text.


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

No, it is a terrible solution :)


I've updated my ballot to No Objection.

Paul