]> American Civil Liberties Union

dkg@fifthhorseman.net

int lamps Internet-Draft This draft proposes a mechanism for e-mail users to indicate to their peers that the peer should expect all future e-mail from them to be cryptographically signed. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction E-mail signature validation is hard. When an e-mail signature is absent (or invalid), a reasonable mail user agent will hide their cryptographic authenticity security indicator for the message. But an absent security indicator is hard to notice. Some e-mail users create end-to-end signatures of all of their e-mails. The peers of those users may want to display a more significant warning message when a signature is absent or invalid. This draft proposes a mechanism whereby an e-mail author can indicate to a peer that they should expect all their future messages to be cryptographically signed.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The terms Message Submission Agent (MSA), Message Transfer Agent (MTA), and Message User Agent (MUA) are to be interpreted as defined in .

Signalling Mechanism A sender that intends to signal their intention to activate the Expected-Signed mechanism MUST add an "Expected-Signed" header to the outgoing email, specifying an expiration date in the value of the header. The authenticity of the header MUST be validated. The header SHOULD be transmitted in the protected headers (see ), and a recipient MUA SHOULD deem it valid if the signing key is already trusted. Alternatively, the recipient's MUA: SHOULD validate the DKIM headers and SHOULD require them to be in the protected headers. SHOULD validate the SPF records to verify it is coming from an authorized source and SHOULD require the message to be delivered over TLS before deeming it valid. FIXME: Do we want to support them all? A recipient MUA that receives a valid "Expected-Signed" header SHOULD safely store this information and its expiration date indexed per email address.

Expect-Signed syntax The ABNF (Augmented Backus-Naur Form) syntax for the Expect-Signed header field is given below, as described by .

Note that: The Expect-Signed header field name and directive names are not case sensitive. All directives MUST appear only once in an Expect-Signed header field. Directives are either optional or required, as stipulated in their definitions. The order of appearance of directives is not significant. MUAs MUST ignore any Expect-Signed header field containing directives, or other header field value data, that does not conform to the syntax defined in this specification. If an Expect-Signed header field contains directive(s) not recognized by the MUA, the MUA MUST ignore the unrecognised directives. If the Expect-Signed header field otherwise satisfies the above requirements, the MUA MUST process the recognized directives.

The expiry directive The expiry directive defines an expiration date for the expectation of a signature. The policy MUST be enforced until the expiry date is in the past. This value is expressed by the sender with a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format .

This value SHOULD be safely stored by the recipient’s MUA, and SHOULD be updated when a valid newer one is received. NOTE: any date in the past will effectively cease the policy enforcement.

Header Examples The Expect-Signed header stipulates an Expect-Signed policy to remain in effect until the specified date:

NOTE: the expiry-value must be quoted since it is not a token. FIXME: should the expiry use a more sane date format, like ISO-8601?

Validating Policy All e-mails coming from addresses that are stored and valid as Expect-Signed MUST be validated. To validate a message's signature the recipient's client MUST follow OpenPGP's specification . FIXME: This is not only OpenPGP. Should include a reference to PGP/MIME , S/MIME , and . The sender's key can be retrieved from any trusted storage or repository, and if none is found it SHOULD be indicated in the feedback. This mechanism will allow the sender to automatically reply with their key.

On Policy Violation In the scenario where a sender has enabled the Expect-Signature it is expected that all the outgoing messages are provided with a a valid signature, and both the sender and recipient should be notified when a signature is missing or invalid. An MSA, MTA, or MUA SHOULD NOT prevent a message from being received due to a missing signature. The MUA MUST warn the user if an expected signature is missing or invalid, and SHOULD provide feedback as specified in the following sections.

Warn The recipient's MUA MUST warn the user that the signature is missing or invalid on every instance where the signature is expected but not verified. The two cases SHOULD be treated as equal, because a missing signature is not any more suspicious than a broken signature: a malicious attacker that alters a message can easily remove the signature too.

Explicit Feedback FIXME: describe TLSRPT-style feedback The MUA MAY avoid automatic explicit feedback, as it introduces a vector for attackers to know if an email is reachable or if a user read the message.

Sender behaviour FIXME: Define what to do with the explicit feedback. FIXME: Key points: Should it be machine or human readable? Localization?

Inline Feedback When replying to a message whose expectation of signature is failed the MUA SHOULD introduce an Expect-Signed-Failure header to signal to the original sender that the message signature was missing or invalid. The syntax of the Expect-Signed-Failure field, described by the ABNF is as follows:

Note that the Expect-Signed-Failure header field name and failure-reason value are not case sensitive.

Failure-reason There are four categories of failure for signature verification: no-signature: The message is not provided with a signature packet or part. signature-invalid: The message is provided with a not matching signature, and the key ID matches the signature key ID, i.e., the content is different from the signed data. signature-not-verified: The message is provided with a signature, but the MUA is unable to verify it because it does not have or can not retrieve the matching key. signature-expired: The message has a corresponding signature, that is invalid because either the key or signature expiration are in the past. In this case an MUA SHOULD NOT give any feedback to the sender. The failure-reason value can then assume the following values:

Sender behaviour The sender's MUA receiving an inline feedback MUST display a warning to the user if the reason is "no-signature" or "signature-invalid", and MAY display a warning if the reason is "signature-not-verified" or "signature-expired". The purpose of this warning is to warn the sender that there might be some misconfigured option in the mail client, that result in messages being unsigned or malformed, or that he is victim of an impersonation. Furthermore, when receiving an inline feedback with reason "signature-not-verified" the sender's MUA MAY automatically attach a copy of their public key to a successive reply.

Common UX for Absent and Invalid Signatures FIXME: explain why receiving MUAs should display the same thing when a signature is missing as when it is absent.

Related Work This draft is inspired by (and similar to) HSTS, MTA-STS, TLSRPT, etc. FIXME: include references

IANA Considerations IANA might need to register the e-mail headers Expect-Signed and Expect-Signed-Failure.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK] American Civil Liberties Union pEp Foundation Isode Ltd S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The header protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK] This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. American Civil Liberties Union pEp Foundation Isode Ltd 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 suggestions to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems.

Acknowledgements FIXME

Mapping the Solution Space [ RFC Editor: please remove this section before publication ] The range of possible solutions in this problem space is potentially quite wide. The draft attempts to make some decisions, but they can be revisted. This appendix tries to document some distinct axes along which the problem can be resolved. The completed draft should provide a clear choice along each axis, or a mechanism for some active participant in the protocol to select a choice.

Signal Location Where should the signal be emitted? Is it a per-message signal? Is it in the sender's certificate? Is it in the DNS?

Signal Scope What is the scope of the signal? For example, does it cover a particular e-mail address in the "From" field? Could it cover all e-mail addresses in a given domain? Or does it only cover a specific pair-wise promise (e.g., "alice@example.com will sign all mail that is only addressed to bob@example.net")? Does it apply to all mail, or could it be limited to end-to-end-encrypted mail?

Intervening Mail User Agents How does this signal interact with messages that arrive through intervening MUAs, like mailing lists or bug-tracking systems that may (deliberately or not) break signatures while forwarding mail?

How to Signal? How does the sender opt into emitting this signal such that all of their MUAs are aware of it? Clearly, you'd want each MUA controlled by the sender to know that the signal has been published so that they can all adjust their signing policy.

Retraction How does the sender change their mind once such a signal has been emitted? Does the signal expire? What happens to messages during the period where the signal is in some sort of indeterminate state?

Consequences What should the available consequences be when an unsigned (or broken-signature) message arrives from a sender who has emitted that signal? Should the recieving MUA show the message with a warning? Should the receiving MUA report the failure to the sender (e.g., like MTA-STS)? Should they reject the message entirely? How much control should the signaller be able to exercise?

What Kind of Cryptographic Signature? Does the signal commit the sender to any particular kind of cryptographic signature? For example, PGP/MIME, or S/MIME? To signatures verifiable by any particular certificate?

Document Considerations [ RFC Editor: please remove this section before publication ]

Document History