idnits 2.17.1 draft-levine-dkim-conditional-03.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 (February 12, 2018) is 2258 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 February 12, 2018 5 Expires: August 16, 2018 7 Mandatory Tags for DKIM Signatures 8 draft-levine-dkim-conditional-03 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 August 16, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Mandatory DKIM header tags . . . . . . . . . . . . . . . . . 3 55 3.1. Signature verification features . . . . . . . . . . . . . 3 56 3.2. Processing mandatory tags . . . . . . . . . . . . . . . . 3 57 3.3. Forward signature (!fs) tag . . . . . . . . . . . . . . . 4 58 4. Typical application scenarios . . . . . . . . . . . . . . . . 4 59 4.1. Sender use . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Forwarder use . . . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Recipient use . . . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 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 defines a new version 2 of the DKIM 87 protocol to support the new semantics of conditional signatures. 89 2. Definitions 91 The upper case key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 92 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 [RFC2119]. 96 Syntax descriptions use Augmented BNF (ABNF)[RFC5234]. 98 The ABNF "ALPHA", "FWS", "tag-list" and "domain-name" are defined as 99 in [RFC6376]. 101 3. Mandatory DKIM header tags 103 The current DKIM specification defines a set of header tags, some of 104 which are required to appear in every signature and some of which are 105 optional. It also allows a signer to include private tags that don't 106 conflict with the registered ones. Since verifiers ignore tags that 107 they don't understand, new tags can only provide new information 108 about the message, or enable new verification schemes for signatures 109 that would otherwise be considered invalid. 111 A Mandatory Tag is a new kind of tag prefixed with an exclamation 112 point. Its syntax is otherwise identical to an ordinary tag. 114 ABNF: 116 tag-spec =/ [FWS] "!" tag-name [FWS] "=" [FWS] tag-value [FWS] 118 3.1. Signature verification features 120 The v= tag defined in section [RFC6376] section 3.5 is renamed to the 121 Verification Features tag. Its value is a comma-separated sequence 122 of alphanumeric feature names. 124 ABNF: 126 sig-v-tag = %x76 [FWS] "=" [FWS] 1*(ALPHA / DIGIT) 127 0*(, 1*(ALPHA / DIGIT)) 129 Feature name "1" includes all of the features described in [RFC6376]. 130 Feature name "man" includes the Mandatory Tag. 132 When a signer creates a signature, the v= tag MUST include feature 133 names for all features used in the signature. The v= tag SHOULD NOT 134 include feature names for features not used in the signature. For 135 example, signatures that use only RFC 6376 features have a "v=1" tag. 137 When a verifier encounters a feature name in the v= tag that it does 138 not support, it MUST return PERMFAIL for that signature. 140 3.2. Processing mandatory tags 142 When a verifier encounters a mandatory tag in a signature, it MUST 143 process the tag according to the tag's definition. If the verifier 144 is unable to process the tag the verifier MUST return PERMFAIL for 145 that signature. If there are multiple signatures on a message, the 146 verifier continues to verify other signatures as usual. It is valid 147 to have a signatures using different features on a single message. 149 3.3. Forward signature (!fs) tag 151 The "!fs" mandatory tag means that the signature is only valid if an 152 additional signature is present in the message. The value of the !fs 153 tag is a domain name that is the value of the d= tag of the 154 additional signature. The condition is satisfied if the message 155 includes at least one valid DKIM signature header field with 156 responsible domain (the d= tag) being one specified by the !fs tag. 158 Chained !fs tags are valid and may be useful in scenarios with 159 multiple levels of forwarders. DKIM verifiers SHOULD handle at least 160 three levels of !fs chaining. 162 4. Typical application scenarios 164 A sender that expects a message to be forwarded might put both a 165 conventional DKIM signature and a signature with a !fs tag that 166 refers to the domain name of the expected forwarder. That signature 167 would typically be a "weak" signature that covers the From, To, Date, 168 and Message-ID headers but does not cover the Subject header or the 169 message body, so that it would remain valid even if a forwarder made 170 changes typical of forwarders such as mailing lists. Subsequent 171 recipients observe both the forwarder's signature and the signature 172 with the !fs tag that matches the other signature, and use either or 173 both to assess the message. 175 4.1. Sender use 177 A small sender that doesn't know which of its mail recipients are 178 likely to be forwarders might put a weak signature on all outgoing 179 mail, in the expectation that few of its users correspondents are 180 likely to be malicious. A sender that had some idea which recipients 181 are forwarders could apply weak signnatures only to mail to those 182 recipients. Or a sender might apply weak signatures to all mail 183 except that sent to recipients with poor reputations. 185 For the second or third possibilities, the sender might keep its own 186 reputation data, or might query shared whitelists or blacklists. 188 4.2. Forwarder use 190 At the time the message is forwarded, the forwarder uses the 191 conventional signature to assess the message, edits the message, and 192 then signs the outgoing message with its own signature. This process 193 is the same as what forwarders typically do now. The forwarder must 194 not strip the weak signature from the outgoing message. 196 4.3. Recipient use 198 A sample set of weak and forwarder signatures might be: 200 DKIM-Signature: v=man,1; a=rsa-sha256; d=example.net; s=abc; 201 c=simple; t=1518456670; h=from:to:date:message-id; l=0; 202 !fs=lists.example.com; bh=MT34908vdk3l24kedfkpI=; 203 b=dzdfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR; 204 DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=lists.example.com; 205 h=From : To : Subject : Date : Message-ID; 206 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 207 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB=; 209 A message with a weak signature and a forwarder's signature is signed 210 by both, and the recipient would typically use either or both to 211 assess the message. In particular, if the original sender asserts a 212 DMARC policy, the weak signature would be adequate to satisfy that 213 policy. 215 If a message arrives with signature containing a !fs but no 216 forwarding signature, the recipient would ignore that signature. If 217 the message contains other signatures, the recipient can use them to 218 assess the message. 220 5. IANA Considerations 222 IANA is requested to add this entry to the "DKIM-Signature Tag 223 Specifications" registry. 225 +------+-----------------+--------+ 226 | TYPE | REFERENCE | STATUS | 227 +------+-----------------+--------+ 228 | !fs | (this document) | active | 229 +------+-----------------+--------+ 231 Table 1: DKIM-Signature Tag Specifications additions 233 IANA is requested to create the "DKIM-Signature Feature Name" 234 registry, with the following initial contents. 236 +------+-----------------+--------+ 237 | NAME | REFERENCE | STATUS | 238 +------+-----------------+--------+ 239 | 1 | (this document) | active | 240 | man | (this document) | active | 241 +------+-----------------+--------+ 243 Table 2: DKIM-Signature Feature Name contents 245 6. Security Considerations 247 DKIM was designed to provide assurances that a message with a valid 248 signature was received in essentially the same form that it was sent. 249 The forwarding signature condition deliberately creates a loophole 250 for messages intended to be forwarded by entities that edit the 251 message. It opens up a variety of obvious replay attacks that may or 252 may not be important depending on both the selection of target 253 domains for messages to be forwarded, and the behavior of forwarders 254 that receive messages with conditional signatures. 256 A sender can limit the conceptual size of the loophole by being 257 selective about what other domains it allows in its !fs tags, and by 258 using the x= tag to limit the time during which forwarded signatures 259 are valid. 261 7. Change Log 263 Please remove this section before publication. 265 7.1. -02 to -03 267 Add feature names. 269 Expand usage scenarios. 271 7.2. -01 to -02 273 Change tag character from @ to ! per Murray. 275 Add suggestions about limiting the forwarding loophole. 277 8. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 285 Specifications: ABNF", STD 68, RFC 5234, 286 DOI 10.17487/RFC5234, January 2008, 287 . 289 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 290 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 291 RFC 6376, DOI 10.17487/RFC6376, September 2011, 292 . 294 Author's Address 296 John Levine 297 Taughannock Networks 298 PO Box 727 299 Trumansburg, NY 14886 301 Phone: +1 831 480 2300 302 Email: standards@taugh.com 303 URI: http://jl.ly