Guidance on End-to-End E-mail Security
draft-ietf-lamps-e2e-mail-guidance-16

[Ballot comment]
Thanks for this.  It's well written and provides good coverage of the material.  I'll be going to YES once the DISCUSS is resolved.

Given the use of BCP 14 keywords in this document, I would prefer this be done as a BCP or a Standards Track document (specifically, an Applicability Statement).  It really is specifying something that's got compliance requirements and use of existing protocols to achieve a particular outcome.  You might even consider Experimental if you're simply not sure about how robust the advice in here is.  The IESG will take up some future discussion about what guidance we might want to provide for future efforts like this one.

I'm curious: If there are no committed or planned implementations, what was the source for most of this advice?  Prior working groups in the area of email security, like DKIM and DMARC, have firmly avoided providing any sort of user interface advice on the basis that we simply do not have experience from which to develop such advice.  I'm wondering what's different now.

The discussion about lock icons and such was interesting.  Over on the DKIM list, there was some recent discussion about whether such user indications are useful at all, whether they highlight security or non-security of a message.  Some studies were cited that suggest these simply have never worked.

[Ballot discuss]
I'll do what Robert chose not to do and ask that we briefly discuss the status.  Specifically: Why isn't this a BCP, or perhaps an Applicability Statement?  It's peculiar to have BCP 14 language in an Informational document, and this does seem to be laying out a bunch of best practices.

[Ballot comment]
Thanks for this.  It's well written and provides good coverage of the material.  I'll be going to YES once the DISCUSS is resolved.

I'm curious: If there are no committed or planned implementations, what was the source for most of this advice?  Prior working groups in the area of email security, like DKIM and DMARC, have firmly avoided providing any sort of user interface advice on the basis that we simply do not have experience from which to develop such advice.  I'm wondering what's different now.

The discussion about lock icons and such was interesting.  Over on the DKIM list, there was some recent discussion about whether such user indications are useful at all, whether they highlight security or non-security of a message.  Some studies were cited that suggest these simply have never worked.

[Ballot comment]
Thanks for working on this. Once this document has become an RFC I look forward to the day, soon I'm sure, when end-to-end e-mail [is] simple and secure for the end user.

[Ballot 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 "  ?

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.

[Ballot 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 :)

[Ballot comment]
Thanks for this document.

Would it be worthwhile to discuss the handling of encrypted email with obsolete ciphers, as is done in (6.4) for signatures?

[Ballot comment]
Hi,

Thanks for this document. I'm no expert on the email related RFCs but I found this document to be very well written, being both easy to read and understand.

I was considering balloting 'DISCUSS' on this document because I think that it should really be a BCP rather than Informational.  Was BCP considered (the shepherd writeup doesn't indicate) and dismissed?

Anyway, I have a few other minor/nit level comments for the authors consideration:


Minor level comments:

(1) p 14, sec 4.1.1.4.  S/MIME PKCS7 authEnveloped-data Cryptographic Layer

  Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
  (Section 4.1.1.4) have identical message structure and very similar
  semantics.  The only difference between the two is ciphertext
  malleability.

I was slightly confused by the statement that they offer very similar semantics when one of them offers integrity and the other does not, at least according to the explanations accompanying them.


(2) p 26, sec 6.4.  Signature failures

  A conformant MUA MUST NOT render a message with a failed signature as
  more dangerous or more dubious than a comparable message without any
  signature at all.  In both cases, the Cryptographic Summary should be
  Unprotected.

Does it still make sense to flag the failed signature at all, e.g., so potentially the receiver can warn the sender that their signature is failing?



Nit level comments:

(3) p 30, sec 7.3.  MIME Part Examples

  In this case, parts M and N are still the Cryptographic Envelope.

are still => are still in?


(4) p 31, sec 8.1.1.  Peer Certificate Selection

  *  It must have a subjectAltName of type rfc822Name whose contents
      match the destination address.  In particular, the local-part of
      the two addresses should be an exact bytewise match, and the
      domain parts of the two addresses should be matched by ensuring
      label equivalence across the full domain name, as described in
      Section 2.3.2.4 of [RFC5890].

For clarity, perhaps "destination address" => "destination e-mail address".

Regards,
Rob

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-e2e-mail-guidance-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-e2e-mail-guidance@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Guidance on End-to-End E-mail Security) to Informational RFC


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Guidance on
End-to-End E-mail Security'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  End-to-end cryptographic protections for e-mail messages can provide
  useful security.  However, the standards for providing cryptographic
  protection are extremely flexible.  That flexibility can trap users
  and cause surprising failures.  This document offers guidance for
  mail user agent implementers to help mitigate those risks, and to
  make end-to-end e-mail simple and secure for the end user.  It
  provides a useful set of vocabulary as well as recommendations to
  avoid common failures.  It also identifies a number of currently
  unsolved usability and interoperability problems.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/



No IPR declarations have been submitted directly on this I-D.

# Shepherd Write-up for draft-ietf-lamps-e2e-mail-guidance-13

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document. It was developed over
  tha last three years, with discussion at almost every IETF meeting during
  that time period.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the authors.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written, but so far, vendors of major email user
  agents have not said whether they will implement.  One did offer insightful
  review of the Internet-Draft during WG Last Call.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  We are expecting more review from the email community during IETF Last Call,
  including the ART-ART review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  This document does not make use of a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Informational on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR disclosures were issued against this document.

    The authors have explicitly stated that he is unaware of any IPR
    that needs to be declared.

    The authors have explicitly stated that he do not hold any IPR
    related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    There are many lines with non-ASCII characters. This is intentional, and
    the authors are prepared to work with the RFC Editor to ensure that the
    publication formats produce appropriate output.

    IDnits complains 'SHOULD not' in one paragraph.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.  [I-D.ietf-lamps-header-protection] is being sent to the IESG
    at the same time as this document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    [REPLY] is behind a paywall.  It is an informational reference, and part
    of it is  available at the URL in the reference:
   
      https://doi.org/10.1007/978-3-030-21568-2_2

    The whole paper can be found at:
   
      https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    Yes.  [I-D.ietf-lamps-header-protection] is being sent to the IESG at the
    same time as this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No, this document will not change the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This document does not require anything from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.

# Shepherd Write-up for draft-ietf-lamps-e2e-mail-guidance-13

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document. It was developed over
  tha last three years, with discussion at almost every IETF meeting during
  that time period.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the authors.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written, but so far, vendors of major email user
  agents have not said whether they will implement.  One did offer insightful
  review of the Internet-Draft during WG Last Call.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  We are expecting more review from the email community during IETF Last Call,
  including the ART-ART review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  This document does not make use of a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Informational on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR disclosures were issued against this document.

    The authors have explicitly stated that he is unaware of any IPR
    that needs to be declared.

    The authors have explicitly stated that he do not hold any IPR
    related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    There are many lines with non-ASCII characters. This is intentional, and
    the authors are prepared to work with the RFC Editor to ensure that the
    publication formats produce appropriate output.

    IDnits complains 'SHOULD not' in one paragraph.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.  [I-D.ietf-lamps-header-protection] is being sent to the IESG
    at the same time as this document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    [REPLY] is behind a paywall.  It is an informational reference, and part
    of it is  available at the URL in the reference:
   
      https://doi.org/10.1007/978-3-030-21568-2_2

    The whole paper can be found at:
   
      https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    Yes.  [I-D.ietf-lamps-header-protection] is being sent to the IESG at the
    same time as this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No, this document will not change the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This document does not require anything from IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.