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