idnits 2.17.1 draft-levine-dkim-conditional-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (30 August 2020) is 1335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track 30 August 2020 5 Expires: 3 March 2021 7 Mandatory Tags for DKIM Signatures 8 draft-levine-dkim-conditional-04 10 Abstract 12 The DKIM protocol applies a cryptographic signature to an e-mail 13 message. This specification extends DKIM to allow new signature tags 14 that validators are required to evaluate. The first such tag 15 specifies a second signature that must be present for a signature to 16 be valid. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 3 March 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Mandatory DKIM header tags . . . . . . . . . . . . . . . . . 3 54 3.1. Signature verification features . . . . . . . . . . . . . 3 55 3.2. Processing mandatory tags . . . . . . . . . . . . . . . . 4 56 3.3. Forward signature (!fs) tag . . . . . . . . . . . . . . . 4 57 4. Typical application scenarios . . . . . . . . . . . . . . . . 4 58 4.1. Sender use . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Forwarder use . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Recipient use . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 DKIM [RFC6376] defines a cryptographic header field consisting of a 73 series of tags and values. The values include signed hashes of some 74 of the header fields and part or all of the body of a message. The 75 signature contains a domain name that is responsible for the 76 signature. The signature is valid if the hashes in the signature 77 match the corresponding hashes of the message at validation time, the 78 signature is validated by a public key retrieved from that 79 responsible domain's DNS, and it is before the expiration time in the 80 signature header field. 82 This specification defines the syntax for new tags in a signature 83 header field that specify additional conditions that must be 84 satisfied for a signature to be valid. The first such condition 85 requires the presence of an additional signature from a specified 86 different domain. It also changes the DKIM version tag to a 87 verification features tag to allow the new semantics of conditional 88 signatures. 90 2. Definitions 92 The upper case key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 93 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 Syntax descriptions use Augmented BNF (ABNF)[RFC5234]. 99 The ABNF "ALPHA", "FWS", "tag-list" and "domain-name" are defined as 100 in [RFC6376]. 102 3. Mandatory DKIM header tags 104 The current DKIM specification defines a set of header tags, some of 105 which are required to appear in every signature and some of which are 106 optional. It also allows a signer to include private tags that don't 107 conflict with the registered ones. Since verifiers ignore tags that 108 they don't understand, new tags can only provide new information 109 about the message, or enable new verification schemes for signatures 110 that would otherwise be considered invalid. 112 A Mandatory Tag is a new kind of tag prefixed with an exclamation 113 point. Its syntax is otherwise identical to an ordinary tag. 115 ABNF: 117 tag-spec =/ [FWS] "!" tag-name [FWS] "=" [FWS] tag-value [FWS] 119 3.1. Signature verification features 121 The v= tag defined in section [RFC6376] section 3.5 is renamed to the 122 Verification Features tag. Its value is a comma-separated sequence 123 of alphanumeric feature names. 125 ABNF: 127 sig-v-tag = %x76 [FWS] "=" [FWS] 1*(ALPHA / DIGIT) 128 0*(, 1*(ALPHA / DIGIT)) 130 Feature name "1" includes all of the features described in [RFC6376]. 131 Feature name "man" includes the Mandatory Tag. 133 When a signer creates a signature, the v= tag MUST include feature 134 names for all features used in the signature. The v= tag SHOULD NOT 135 include feature names for features not used in the signature. For 136 example, signatures that use only RFC 6376 features have a "v=1" tag. 138 When a verifier encounters a feature name in the v= tag that it does 139 not support, it MUST return PERMFAIL for that signature. 141 3.2. Processing mandatory tags 143 When a verifier encounters a mandatory tag in a signature, it MUST 144 process the tag according to the tag's definition. If the verifier 145 is unable to process the tag the verifier MUST return PERMFAIL for 146 that signature. If there are multiple signatures on a message, the 147 verifier continues to verify other signatures as usual. It is valid 148 to have a signatures using different features on a single message. 150 3.3. Forward signature (!fs) tag 152 The "!fs" mandatory tag means that the signature is only valid if an 153 additional signature is present in the message. The value of the !fs 154 tag is a domain name that is the value of the d= tag of the 155 additional signature. The condition is satisfied if the message 156 includes at least one valid DKIM signature header field with 157 responsible domain (the d= tag) being one specified by the !fs tag. 159 Chained !fs tags are valid and may be useful in scenarios with 160 multiple levels of forwarders. DKIM verifiers SHOULD handle at least 161 three levels of !fs chaining. 163 4. Typical application scenarios 165 A sender that expects a message to be forwarded might put both a 166 conventional DKIM signature and a signature with a !fs tag that 167 refers to the domain name of the expected forwarder, most likely the 168 domain of the recipient in the To header. That signature would be a 169 "weak" signature that covers the From, To, Date, and Message-ID 170 headers but does not cover the Subject header or the message body, so 171 that it would remain valid even if a forwarder made changes that 172 forwarders such as mailing lists often make. Subsequent recipients 173 observe both the forwarder's signature and the signature with the !fs 174 tag that matches the other signature, and use either or both to 175 assess the message. 177 4.1. Sender use 179 A small sender that doesn't know which of its mail recipients are 180 likely to be forwarders might put a weak signature on all outgoing 181 mail, in the expectation that few of its users correspondents are 182 likely to be malicious. A sender that had some idea which recipients 183 are forwarders could apply weak signnatures only to mail to those 184 recipients. Or a sender might apply weak signatures to all mail 185 except that sent to recipients with poor reputations. 187 For the second or third possibilities, the sender might keep its own 188 reputation data, or might query shared reputation services. 190 4.2. Forwarder use 192 At the time the message is forwarded, the forwarder uses the 193 conventional signature to assess the message, edits the message, and 194 then signs the outgoing message with its own signature. This process 195 is the same as what forwarders typically do now. The forwarder must 196 not strip the weak signature from the outgoing message. 198 The forwarder's signature d= domain has to match the one in the 199 original !fs= tag. The simplest way to arrange this is for that 200 domain to be the one in the To header, normally one that the 201 forwarder controls. 203 [[ Possibly allow some flexibility about superdomain or subdomain 204 matching? ]] 206 4.3. Recipient use 208 A sample set of weak and forwarder signatures might be: 210 DKIM-Signature: v=man,1; a=rsa-sha256; d=example.net; s=abc; 211 c=simple; t=1518456670; h=from:to:date:message-id; l=0; 212 !fs=lists.example.com; bh=MT34908vdk3l24kedfkpI=; 213 b=dzdfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR; 214 DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=lists.example.com; 215 h=From : To : Subject : Date : Message-ID; 216 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 217 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB=; 219 A message with a weak signature and a forwarder's signature is signed 220 by both, and the recipient would typically use either or both to 221 assess the message. In particular, if the original sender asserts a 222 DMARC policy, the weak signature would be adequate to satisfy that 223 policy. 225 If a message arrives with signature containing a !fs but no 226 forwarding signature, the recipient would ignore that signature. If 227 the message contains other signatures, the recipient can use them to 228 assess the message. 230 5. IANA Considerations 232 IANA is requested to add this entry to the "DKIM-Signature Tag 233 Specifications" registry. 235 +======+=================+========+ 236 | TYPE | REFERENCE | STATUS | 237 +======+=================+========+ 238 | !fs | (this document) | active | 239 +------+-----------------+--------+ 241 Table 1: DKIM-Signature Tag 242 Specifications additions 244 IANA is requested to create the "DKIM-Signature Feature Name" 245 registry, with the following initial contents. 247 +======+=================+========+ 248 | NAME | REFERENCE | STATUS | 249 +======+=================+========+ 250 | 1 | (this document) | active | 251 +------+-----------------+--------+ 252 | man | (this document) | active | 253 +------+-----------------+--------+ 255 Table 2: DKIM-Signature Feature 256 Name contents 258 6. Security Considerations 260 DKIM was designed to provide assurances that a message with a valid 261 signature was received in essentially the same form that it was sent. 262 The forwarding signature condition deliberately creates a loophole 263 for messages intended to be forwarded by entities that edit the 264 message. It opens up a variety of obvious replay attacks that may or 265 may not be important depending on both the selection of target 266 domains for messages to be forwarded, and the behavior of forwarders 267 that receive messages with conditional signatures. 269 A sender can limit the conceptual size of the loophole by being 270 selective about what other domains it allows in its !fs tags, and by 271 using the x= tag to limit the time during which forwarded signatures 272 are valid. 274 7. Change Log 276 Please remove this section before publication. 278 7.1. -03 to -04 280 Add hints to use To domain as the chain link 282 7.2. -02 to -03 284 Add feature names. 286 Expand usage scenarios. 288 7.3. -01 to -02 290 Change tag character from @ to ! per Murray. 292 Add suggestions about limiting the forwarding loophole. 294 8. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 302 Specifications: ABNF", STD 68, RFC 5234, 303 DOI 10.17487/RFC5234, January 2008, 304 . 306 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 307 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 308 RFC 6376, DOI 10.17487/RFC6376, September 2011, 309 . 311 Author's Address 313 John Levine 314 Taughannock Networks 315 PO Box 727 316 Trumansburg 318 Email: standards@taugh.com 319 URI: http://jl.ly