idnits 2.17.1 draft-kucherawy-dkim-atps-07.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 == Line 311 has weird spacing: '... Method dkim-...' == Line 315 has weird spacing: '... ptype heade...' == Line 316 has weird spacing: '...roperty from...' == Line 318 has weird spacing: '... value conte...' == Line 326 has weird spacing: '... Code none...' == (14 more instances...) -- The document date (September 21, 2011) is 4600 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'THIS MEMO' is mentioned on line 393, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark, Inc. 4 Updates: 6376 (if approved) September 21, 2011 5 Intended status: Experimental 6 Expires: March 24, 2012 8 DKIM Authorized Third-Party Signers 9 draft-kucherawy-dkim-atps-07 11 Abstract 13 This memo presents an experimental proposal to supplement Domain Keys 14 Identified Mail (DKIM) by allowing advertisement of third-party 15 signature authorizations on behalf of an email originator. 17 This memo updates RFC6376. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 24, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . 3 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Queries and Replies . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Extension to DKIM . . . . . . . . . . . . . . . . . . . . 4 60 4.2. ATPS Query Details . . . . . . . . . . . . . . . . . . . . 4 61 4.3. ATPS Reply Details . . . . . . . . . . . . . . . . . . . . 5 62 5. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 7 66 7.2. Email Authentication Method Name Registry Update . . . . . 7 67 7.3. Email Authentication Result Name Registry Update . . . . . 8 68 7.4. DKIM-Signature Tag Specification Registry . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8.1. Transient Security Failures . . . . . . . . . . . . . . . 9 71 8.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 11 76 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 [DKIM] defines a mechanism for transparent domain-level signing of 81 messages for the purpose of declaring that a particular 82 Administrative Mail Domain (ADMD) takes some responsibility for a 83 message. 85 DKIM, however, deliberately makes no binding between the DNS domain 86 of the signer and any other identity found in the message. Despite 87 this, there is an automatic human perception that an author domain 88 signature (one for which the RFC5322.From domain matches the DNS 89 domain of the signer) is more valuable or trustworthy than any other. 91 Absent is a protocol by which an ADMD can announce that DKIM 92 signatures on its mail added by other ADMDs should also be considered 93 trustworthy by verifiers. This memo presents an experimental 94 mechanism for doing so. 96 2. Definitions 98 2.1. Keywords 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [KEYWORDS]. 104 2.2. E-Mail Architecture Terminology 106 Readers should be familiar with the material and terminology 107 discussed in [MAIL] and [EMAIL-ARCH]. 109 3. Discussion 111 Participation in this protocol is divided into three parties: 113 o Authors, whose domains appear in the RFC5322.From field of a 114 [MAIL] message; 116 o Signers, who send mail on behalf of Authors and apply [DKIM] 117 signatures using their own domains; and 119 o Verifiers, who implement the signature validation procedures 120 described in [DKIM]. 122 An Author participates in this protocol if it wishes to announce that 123 a message from it (in the RFC5322.From sense) should be considered 124 authentic as long as it bears a signature from any in a set of 125 specified domains. One might, for example, wish to delegate signing 126 authority for its DNS domain to an approved messaging service 127 provider without doing the work of key transfer described in Appendix 128 B.1.1 of [DKIM]. This is communicated to Verifiers via a new tag in 129 the DKIM signature. 131 A Verifier participates in this protocol if it wishes to ensure that 132 a message bears one or more signatures from sources approved to sign 133 mail on behalf of the Author, and identify for special treatment mail 134 that meets (or does not meet) that criterion. 136 4. Queries and Replies 138 This section describes in detail the queries issued, the replies 139 received, and how they should be interpreted and applied. 141 4.1. Extension to DKIM 143 [DKIM] signatures contain a "tag=value" sequence. This protocol will 144 add an additional tag called "atps". When the Signer generates a 145 DKIM signature on behalf of an Author, it MUST include this tag in 146 the signature and include as its value the Author's domain name. 148 The formal syntax definition, per [ABNF]: 150 dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name 152 "domain-name" is imported from [DKIM]. 154 The registration for this tag can be found in Section 7. 156 4.2. ATPS Query Details 158 When a [DKIM] signature including an "atps" tag is successfully 159 verified, and is considered acceptable to the Verifier according to 160 any local policy requirements (which are not discussed here or in 161 [DKIM]), the Verifier compares the domain name in the value of that 162 tag with the one found in the RFC5322.From field of the message. The 163 match MUST be done in a case-insensitive manner. 165 If they do not match, the "atps" tag MUST be ignored. 167 If they do match, the Verifier issues a TXT query to the DNS at a 168 specific name looking for confirmation by the Author that the Signer 169 is authorized by the Author to sign mail on its behalf. Where 170 multiple DKIM signatures are present including valid "atps" tags, 171 these queries MAY be done in any order or MAY be done in parallel. 173 Where the RFC5322.From field contains multiple addresses, this 174 process SHOULD be applied if the "atps" tag's value matches any of 175 the domains found in that field. These MAY be done in any order. 177 The name for the query is constructed as follows: 179 1. Extract the value of the "d=" tag from the signature. 181 2. Convert any upper-case characters in that string to their lower- 182 case equivalents. 184 3. Feed the resulting string to the [SHA1] hash algorithm. 186 4. Convert the output of the SHA1 hash to a string of 32 187 alphanumeric characters by applying base32 encoding as defined in 188 Section 6 of [BASE32]. The base32 encoding is used because its 189 output is restricted to characters that are legal for use in 190 labels in the DNS, and evaluates the same way in the DNS whether 191 encoded using uppercase or lowercase characters. 193 5. Append the string "._atps." 195 6. Append the domain name found in the "atps" tag of the validated 196 signature. 198 The query's formal syntax definition, per [ABNF]: 200 atps-query = 32*BASE32 %x2e.5f.61.74.70.73.2e domain-name 202 BASE32 = ( ALPHA / %x32-37 ) 204 See Appendix A for an example of a query construction. 206 Since the size of a [DNS] query is limited to 255 bytes, the size of 207 "domain-name" in the ABNF above is constrained to 216 bytes. 209 4.3. ATPS Reply Details 211 In the descriptions below, the label NOERROR symbolizes DNS response 212 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 213 of [DNS] for further details. 215 At this time, only three possibilities need to be identified in this 216 specification: 218 o An answer is returned (i.e. [DNS] reply code NOERROR with at 219 least one answer) containing a valid ATPS reply. In this case, 220 the protocol has been satisfied and the Verifier can conclude that 221 the signing domain is authorized by the Author to sign its mail. 223 Further queries SHOULD NOT be initiated. 225 o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR 226 with no answers), or one or more answers have been returned as 227 described above but none contain a valid ATPS reply. In this 228 case, the Signer has not been authorized to act as a third-party 229 signer for this Author, and thus the Verifier MUST continue to the 230 next query. 232 o An error is returned (i.e. any other [DNS] reply code). It is no 233 longer possible to determine whether or not this message satisfies 234 the Author's list of authorized third-party signers. The Verifier 235 SHOULD stop processing and defer the message for later processing, 236 such as requesting temporary failure code from the MTA. 238 If all queries are completed and return either NXDOMAIN or NOERROR 239 with no answers, then the Signer was not authorized by the Author. 241 A valid ATPS reply consists of a sequence of tag-value pairs as 242 described in Section 3.2 of [DKIM]. The following tag and value is 243 the only one currently supported in ATPS records: 245 v: Version (plain-text; REQUIRED) This tag defines the version of 246 this specification that applies to the ATPS record. It MUST have 247 the value "ATPS1". ABNF: 249 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 251 5. Interpretation 253 If a Verifier succeeds in confirming that the Author authorized the 254 Signer using this protocol, then the Verifier SHOULD evaluate the 255 message as though the Signer is the Author. 257 This assertion is based on the fact that the Author explicitly 258 endorsed the Signer. Therefore, a module assessing reputation that 259 is based on DKIM signature verification SHOULD apply the reputation 260 of the Author domain instead of, or in addition to, that of the 261 Signer domain. 263 6. Relationship to ADSP 265 [ADSP] defined a protocol by which an Author can advertise a request 266 to message receivers that messages bearing no valid author signature 267 be treated with suspicion or even discarded. 269 A Verifier implementing both ADSP and ATPS SHOULD treat a message for 270 which the ATPS test described above passes as if it were signed by 271 the author domain. That is, a pass of ATPS means a pass for ADSP. 273 7. IANA Considerations 275 No actions are required by IANA at this time. The following need 276 only be applied if and when this specification reaches the Standards 277 Track. 279 7.1. ATPS Tag Registry 281 An Authorized Third Party Signature (ATPS) Tag Registry will be 282 created by IANA to enumerate the tags that are valid for use in ATPS 283 records. 285 New registrations or updates MUST be published in accordance with the 286 "Specification Required" guidelines described in 287 [IANA-CONSIDERATIONS]. Such registry changes MUST contain the 288 following information: 290 1. Name of the tag being registered or updated 292 2. The document where the specification is created or updated 294 3. The status of the tag, one of "current" (tag is in current use), 295 "deprecated" (tag is in current use but its use is discouraged), 296 or "historic" (tag is no longer in use) 298 The registry's sole initial entry is: 300 +-----+--------------+---------+ 301 | Tag | Specified In | Status | 302 +-----+--------------+---------+ 303 | v | [this memo] | current | 304 +-----+--------------+---------+ 306 7.2. Email Authentication Method Name Registry Update 308 The following should be added to the Email Authentication Method Name 309 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 311 Method dkim-atps 313 Defined In [THIS MEMO] 315 ptype header 316 property from 318 value contents of the [MAIL] From: header field, with comments 319 removed 321 7.3. Email Authentication Result Name Registry Update 323 The following should be added to the Email Authentication Result Name 324 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 326 Code none 328 Existing/New Code existing 330 Defined In [AUTHRES] 332 Auth Method dkim-atps 334 Meaning No valid DKIM signatures were found on the message bearing 335 "atps" tags. 337 Code pass 339 Existing/New Code existing 341 Defined In [AUTHRES] 343 Auth Method dkim-atps 345 Meaning An ATPS evaluation was performed and a valid signature from 346 an authorized third-party was found on the message. 348 Code fail 350 Existing/New Code existing 352 Defined In [AUTHRES] 354 Auth Method dkim-atps 356 Meaning All valid DKIM signatures bearing an "atps" tag either did 357 not reference a domain name found in the RFC5322.From field, or 358 the ATPS test(s) performed failed to confirm a third-party 359 authorization. 361 Code temperror 363 Existing/New Code existing 365 Defined In [AUTHRES] 367 Auth Method dkim-atps 369 Meaning An ATPS evaluation could not be completed due to some error 370 that is likely transient in nature, such as a temporary DNS error. 371 A later attempt may produce a final result. 373 Code permerror 375 Existing/New Code existing 377 Defined In [AUTHRES] 379 Auth Method dkim-atps 381 Meaning An ATPS evaluation could not be completed due to some error 382 that is not likely transient in nature, such as a permanent DNS 383 error. A later attempt is unlikely to produce a final result. 385 7.4. DKIM-Signature Tag Specification Registry 387 The following should be added to the DKIM-Signature Tag Speficication 388 Registry established by [DKIM] as per [IANA-CONSIDERATIONS]: 390 +------+-------------+---------+ 391 | TYPE | REFERENCE | STATUS | 392 +------+-------------+---------+ 393 | atps | [THIS MEMO] | current | 394 +------+-------------+---------+ 396 8. Security Considerations 398 This section discusses potential security issues related to this 399 experimental protocol. 401 8.1. Transient Security Failures 403 Approving a third party signer exposes the Author to the risk that 404 the third party signer becomes compromised and then begins to sign 405 malicious or nuisance messages on behalf of the Author. This can 406 obviously reflect negatively on the Author, and the impact of this 407 can become more severe as automated domain reputation systems are 408 developed and deployed. Thorough vetting and monitoring practices by 409 Authors of third party signers will likely need to become the norm. 411 8.2. Load on the DNS 413 A Verifier participating in DKIM, ADSP and ATPS will now issue a 414 number of TXT queries to the DNS equal to as many as one (for the 415 ADSP query) plus the number of signatures on the message (one for 416 each key that is to be verified) plus the number of signatures that 417 validated which also bear an "atps" tag. This is in addition to any 418 PTR and A queries the MTA may issue at the time the actual message 419 relaying or delivery is initiated. Obviously this can be burdensome 420 on the DNS at both ends, and waiting for that number of queries to 421 return when they are issued in parallel could trigger timeouts in the 422 MTA. 424 An alternative to this that has not yet been explored is the storage 425 of the ATPS data at a specific URL tied to the Author's domain name. 426 This would alleviate pressure on the DNS at the expense of requiring 427 the Author to operate a web server (which has its own security 428 implications) and the addition of the establishment of a TCP 429 connection. Moreover, the Verifier would be well advised to 430 implement caching of this data to prevent ATPS from being used as a 431 denial-of-service vector. 433 9. References 435 9.1. Normative References 437 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 438 Syntax Specifications: ABNF", STD 68, 439 RFC 5234, January 2008. 441 [AUTHRES] Kucherawy, M., "Message Header Field for 442 Indicating Message Authentication Status", 443 RFC 5451, April 2009. 445 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 446 Data Encodings", RFC 4648, October 2006. 448 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. 449 Kucherawy, Ed., "DomainKeys Identified Mail 450 (DKIM) Signatures", RFC 6376, September 2011. 452 [DNS] Mockapetris, P., "Domain names - 453 implementation and specification", STD 13, 454 RFC 1035, November 1987. 456 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 457 Indicate Requirement Levels", BCP 14, 458 RFC 2119, March 1997. 460 [SHA1] U.S. Department of Commerce, "Secure Hash 461 Standard", FIPS PUB 180-2, August 2002. 463 9.2. Informative References 465 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 466 Levine, "DomainKeys Identified Mail (DKIM) 467 Author Domain Signing Practices (ADSP)", 468 RFC 5617, August 2009. 470 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 471 RFC 5598, October 2008. 473 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 474 Writing an IANA Considerations Section in 475 RFCs", BCP 26, RFC 5226, May 2008. 477 [MAIL] Resnick, P., Ed., "Internet Message Format", 478 RFC 5322, October 2008. 480 Appendix A. Example Query and Reply 482 This section presents an example of the use of this protocol to query 483 for a third-party authorization and discusses the interpretation of 484 the result. 486 Presume a message for which the RFC5322.From domain is "example.com", 487 and it bears two valid signatures, from "one.example.net" and from 488 "two.example.net", each with an "atps" whose value is "example.com". 489 The following actions are taken: 491 1. A SHA1 hash of "one.example.net" is computed and then converted 492 to printable form using base32 encoding, resulting in the string 493 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 495 2. A TXT query is issued to 496 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 498 3. If a valid reply arrives, the algorithm stops with [AUTHRES] 499 result "pass". If a DNS error code other than NXDOMAIN is 500 returned, the algorithm stops with a result of "temperror" or 501 "permerror" as appropriate. 503 4. A SHA1 hash of "two.example.net" is computed and then converted 504 to printable form using base32 encoding, resulting in the string 505 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 507 5. A TXT query is issued to 508 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 510 6. If a valid reply arrives, the algorithm stops with [AUTHRES] 511 result "pass". If a DNS error code other than NXDOMAIN is 512 returned, the algorithm stops with a result of "temperror" or 513 "permerror" as appropriate. 515 7. As there are no valid signatures left to test, the algorithm 516 stops with an "unknown" result. 518 Appendix B. Acknowledgements 520 The author wishes to acknowledge Dave Crocker and Mark Martinec for 521 their review and constructive criticism of this proposal. 523 The author also wishes to acknowledge Doug Otis and Daniel Black for 524 their original draft upon which this work was based. 526 Author's Address 528 Murray S. Kucherawy 529 Cloudmark, Inc. 530 128 King St., 2nd Floor 531 San Francisco, CA 94107 532 US 534 Phone: +1 415 946 3800 535 EMail: msk@cloudmark.com