Internet DRAFT - draft-dkg-lamps-expect-signed-mail
draft-dkg-lamps-expect-signed-mail
lamps D. K. Gillmor
Internet-Draft American Civil Liberties Union
Intended status: Informational A. Wussler
Expires: 3 April 2024 Proton AG
1 October 2023
Expect Signed Mail
draft-dkg-lamps-expect-signed-mail-01
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."
Gillmor & Wussler Expires 3 April 2024 [Page 1]
Internet-Draft Expect Signed Mail October 2023
This Internet-Draft will expire on 3 April 2024.
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
Gillmor & Wussler Expires 3 April 2024 [Page 2]
Internet-Draft Expect Signed Mail October 2023
C.1.1. Changes from draft-dkg-lamps-expect-signed-mail-00 to
draft-dkg-lamps-expect-signed-mail-01 . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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.
Gillmor & Wussler Expires 3 April 2024 [Page 3]
Internet-Draft Expect Signed Mail October 2023
* 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.
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.
Gillmor & Wussler Expires 3 April 2024 [Page 4]
Internet-Draft Expect Signed Mail October 2023
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].
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.
Gillmor & Wussler Expires 3 April 2024 [Page 5]
Internet-Draft Expect Signed Mail October 2023
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.
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.
Gillmor & Wussler Expires 3 April 2024 [Page 6]
Internet-Draft Expect Signed Mail October 2023
* *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:
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 & Wussler Expires 3 April 2024 [Page 7]
Internet-Draft Expect Signed Mail October 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 & Wussler Expires 3 April 2024 [Page 8]
Internet-Draft Expect Signed Mail October 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 & Wussler Expires 3 April 2024 [Page 9]
Internet-Draft Expect Signed Mail October 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 & Wussler Expires 3 April 2024 [Page 10]
Internet-Draft Expect Signed Mail October 2023
C.1. Document History
C.1.1. Changes from draft-dkg-lamps-expect-signed-mail-00 to draft-dkg-
lamps-expect-signed-mail-01
* add Aron Wussler to authors
Authors' Addresses
Daniel Kahn Gillmor
American Civil Liberties Union
Email: dkg@fifthhorseman.net
Aron Wussler
Proton AG
Switzerland
Email: aron@wussler.it
Gillmor & Wussler Expires 3 April 2024 [Page 11]
