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

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-lamps-e2e-mail-guidance-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. It contains good advise for implementers. I have a
few issues that I would like to DISCUSS, although perhaps some of those marked
as DISCUSS are between DISCUSS and COMMENT.

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.

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

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.

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

        * No cryptographic payload contains any Bcc header field.

Since headers are not encrypted, isn't this always the case?

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

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

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.


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

        on every alternate messaging service

Maybe remove "alternate"? or so "on all of the many" ?

        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

        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.

NITS:

Petpeeve: the use of the word "novel".

non-comment:

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