Expect Signed Mail
draft-dkg-lamps-expect-signed-mail-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Daniel Kahn Gillmor | ||
Last updated | 2023-09-29 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-dkg-lamps-expect-signed-mail-00
lamps D. K. Gillmor Internet-Draft American Civil Liberties Union Intended status: Informational 29 September 2023 Expires: 1 April 2024 Expect Signed Mail draft-dkg-lamps-expect-signed-mail-00 Abstract 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. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dkg.gitlab.io/expect-signed-mail/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- dkg-lamps-expect-signed-mail/. Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/. Source for this draft and an issue tracker can be found at https://gitlab.com/dkg/expect-signed-mail. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 April 2024. Gillmor Expires 1 April 2024 [Page 1] Internet-Draft Expect Signed Mail September 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signalling Mechanism . . . . . . . . . . . . . . . . . . . . 3 2.1. Expect-Signed syntax . . . . . . . . . . . . . . . . . . 4 2.1.1. The expiry directive . . . . . . . . . . . . . . . . 4 2.2. Header Examples . . . . . . . . . . . . . . . . . . . . . 5 3. Validating Policy . . . . . . . . . . . . . . . . . . . . . . 5 4. On Policy Violation . . . . . . . . . . . . . . . . . . . . . 5 4.1. Warn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Explicit Feedback . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Sender behaviour . . . . . . . . . . . . . . . . . . 6 4.3. Inline Feedback . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Failure-reason . . . . . . . . . . . . . . . . . . . 6 4.3.2. Sender behaviour . . . . . . . . . . . . . . . . . . 7 5. Common UX for Absent and Invalid Signatures . . . . . . . . . 7 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 Appendix B. Mapping the Solution Space . . . . . . . . . . . . . 9 B.1. Signal Location . . . . . . . . . . . . . . . . . . . . . 9 B.2. Signal Scope . . . . . . . . . . . . . . . . . . . . . . 10 B.3. Intervening Mail User Agents . . . . . . . . . . . . . . 10 B.4. How to Signal? . . . . . . . . . . . . . . . . . . . . . 10 B.5. Retraction . . . . . . . . . . . . . . . . . . . . . . . 10 B.6. Consequences . . . . . . . . . . . . . . . . . . . . . . 10 B.7. What Kind of Cryptographic Signature? . . . . . . . . . . 10 Appendix C. Document Considerations . . . . . . . . . . . . . . 10 C.1. Document History . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Gillmor Expires 1 April 2024 [Page 2] Internet-Draft Expect Signed Mail September 2023 1. 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The terms Message Submission Agent (MSA), Message Transfer Agent (MTA), and Message User Agent (MUA) are to be interpreted as defined in [RFC6409]. 2. 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 [I-D.ietf-lamps-header-protection-16]), 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 [RFC6376] and SHOULD require them to be in the protected headers. * SHOULD validate the SPF records [RFC7208] to verify it is coming from an authorized source and SHOULD require the message to be delivered over TLS before deeming it valid. Gillmor Expires 1 April 2024 [Page 3] Internet-Draft Expect Signed Mail September 2023 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. 2.1. Expect-Signed syntax The ABNF (Augmented Backus-Naur Form) syntax for the Expect-Signed header field is given below, as described by [RFC2616]. Expect-Signed = "Expect-Signed" ":" [ directive ] *( ";" [ directive ] ) directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token | quoted-string 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. 2.1.1. 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 [RFC5322]. Gillmor Expires 1 April 2024 [Page 4] Internet-Draft Expect Signed Mail September 2023 expiry-name = "expiry" expiry-value = IMF-fixdate 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. 2.2. Header Examples The Expect-Signed header stipulates an Expect-Signed policy to remain in effect until the specified date: Expect-Signed: expiry="Sun, 20 Oct 2019 14:19:20 GMT"; 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? 3. 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 Section 5.2.4 of [RFC4880]. FIXME: This is not only OpenPGP. Should include a reference to PGP/ MIME [RFC3156], S/MIME [RFC8551], and [I-D.ietf-lamps-e2e-mail-guidance-12]. 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. 4. 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. Gillmor Expires 1 April 2024 [Page 5] Internet-Draft Expect Signed Mail September 2023 4.1. 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. 4.2. 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. 4.2.1. Sender behaviour FIXME: Define what to do with the explicit feedback. FIXME: Key points: Should it be machine or human readable? Localization? 4.3. 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 [RFC2616] is as follows: "Expect-Signed-Failure" ":" failure-reason CRLF Note that the Expect-Signed-Failure header field name and failure- reason value are not case sensitive. 4.3.1. 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. Gillmor Expires 1 April 2024 [Page 6] Internet-Draft Expect Signed Mail September 2023 * *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: failure-reason = ( "no-signature" / "signature-invalid" / "signature-not-verified" / "signature-expired" ) 4.3.2. 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. 5. 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. 6. Related Work This draft is inspired by (and similar to) HSTS, MTA-STS, TLSRPT, etc. FIXME: include references Gillmor Expires 1 April 2024 [Page 7] Internet-Draft Expect Signed Mail September 2023 7. IANA Considerations IANA might need to register the e-mail headers Expect-Signed and Expect-Signed-Failure. 8. Normative References [I-D.ietf-lamps-e2e-mail-guidance-12] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Guidance on End-to-End E-mail Security", Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-12, 13 September 2023, <https://datatracker.ietf.org/doc/html/ draft-ietf-lamps-e2e-mail-guidance-12>. [I-D.ietf-lamps-header-protection-16] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header Protection for Cryptographically Protected E-mail", Work in Progress, Internet-Draft, draft-ietf-lamps-header- protection-16, 13 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- header-protection-16>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/rfc/rfc2616>. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, <https://www.rfc-editor.org/rfc/rfc3156>. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <https://www.rfc-editor.org/rfc/rfc4880>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/rfc/rfc5322>. Gillmor Expires 1 April 2024 [Page 8] Internet-Draft Expect Signed Mail September 2023 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/rfc/rfc6376>. [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/rfc/rfc6409>. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/rfc/rfc7208>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/rfc/rfc8551>. Appendix A. Acknowledgements FIXME Appendix B. 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. B.1. 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? Gillmor Expires 1 April 2024 [Page 9] Internet-Draft Expect Signed Mail September 2023 B.2. 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? B.3. 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? B.4. 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. B.5. 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? B.6. 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? B.7. 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? Appendix C. Document Considerations [ RFC Editor: please remove this section before publication ] Gillmor Expires 1 April 2024 [Page 10] Internet-Draft Expect Signed Mail September 2023 C.1. Document History Author's Address Daniel Kahn Gillmor American Civil Liberties Union Email: dkg@fifthhorseman.net Gillmor Expires 1 April 2024 [Page 11]