idnits 2.17.1 draft-kucherawy-dkim-atps-11.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 347 has weird spacing: '... Method dkim-...' == Line 351 has weird spacing: '... ptype heade...' == Line 353 has weird spacing: '...roperty from...' == Line 355 has weird spacing: '... value conte...' == Line 363 has weird spacing: '... Code none...' == (14 more instances...) -- The document date (November 13, 2011) is 4547 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 263, but not defined == Missing Reference: 'THIS MEMO' is mentioned on line 432, 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 (~~), 9 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 November 13, 2011 5 Expires: May 16, 2012 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-11 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 May 16, 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 . . . . . . . . . . . . . . . . . . . . 6 59 5. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 7 61 7. Experiment Process . . . . . . . . . . . . . . . . . . . . . . 7 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 8 64 8.2. Email Authentication Method Name Registry Update . . . . . 8 65 8.3. Email Authentication Result Name Registry Update . . . . . 8 66 8.4. DKIM-Signature Tag Specification Registry . . . . . . . . 10 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 9.1. False Privacy . . . . . . . . . . . . . . . . . . . . . . 10 69 9.2. Transient Security Failures . . . . . . . . . . . . . . . 10 70 9.3. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 12 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 [DKIM] defines a mechanism for transparent domain-level signing of 80 messages for the purpose of declaring that a particular 81 Administrative Mail Domain (ADMD) takes some responsibility for a 82 message. 84 DKIM, however, deliberately makes no binding between the DNS domain 85 of the signer and any other identity found in the message. Despite 86 this, there is an automatic human perception that an author domain 87 signature (one for which the RFC5322.From domain matches the DNS 88 domain of the signer) is more valuable or trustworthy than any other. 90 Absent is a protocol by which an ADMD can announce that DKIM 91 signatures on its mail added by other ADMDs should also be considered 92 trustworthy by verifiers. This memo presents an experimental 93 mechanism for doing so. 95 2. Definitions 97 2.1. Keywords 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [KEYWORDS]. 103 2.2. E-Mail Architecture Terminology 105 Readers should be familiar with the material and terminology 106 discussed in [MAIL] and [EMAIL-ARCH]. 108 3. Discussion 110 Participation in this protocol is divided into three parties: 112 o Authors, whose domains appear in the RFC5322.From field of a 113 [MAIL] message; 115 o Signers, who send mail on behalf of Authors and apply [DKIM] 116 signatures using their own domains; and 118 o Verifiers, who implement the signature validation procedures 119 described in [DKIM]. 121 An Author participates in this protocol if it wishes to announce that 122 a message from it (in the RFC5322.From sense) should be considered 123 authentic as long as it bears a signature from any in a set of 124 specified domains. One might, for example, wish to delegate signing 125 authority for its DNS domain to an approved messaging service 126 provider without doing the work of key transfer described in Appendix 127 B.1.1 of [DKIM]. This is communicated to Verifiers via a new tag in 128 the DKIM signature. 130 A Verifier participates in this protocol if it wishes to ensure that 131 a message bears one or more signatures from sources approved to sign 132 mail on behalf of the Author, and identify for special treatment mail 133 that meets (or does not meet) that criterion. 135 4. Queries and Replies 137 This section describes in detail the queries issued, the replies 138 received, and how they should be interpreted and applied. 140 4.1. Extension to DKIM 142 [DKIM] signatures contain a "tag=value" sequence. This protocol will 143 add additional tags called "atps" and "atpsh". 145 When the Signer generates a DKIM signature on behalf of an Author, it 146 MUST include an "atps" tag in the signature and include as its value 147 the Author's domain name. 149 For creating records in the DNS, a hash algorithm needs to be 150 selected. The Signer and the Author have to agree on which hash is 151 to be used, since the Author places a corresponding record in its DNS 152 and the Signer will have to indicate in its generated signatures 153 which hash algorithm the Author is using. The selected hash 154 algorithm MUST be one of the ones registered with IANA as valid for 155 use with DKIM (see Section 7.7 of [DKIM]). The tag name that carries 156 the hash name used is "atpsh". If absent, the Verifier MUST assume 157 "sha1". 159 The formal syntax definition, per [ABNF]: 161 dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name 163 dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP key-h-tag-alg 165 "domain-name" and "key-h-tag-alg" are imported from [DKIM]. 167 The registration for these tags can be found in Section 8. 169 4.2. ATPS Query Details 171 When a [DKIM] signature including an "atps" tag is successfully 172 verified, and is considered acceptable to the Verifier according to 173 any local policy requirements (which are not discussed here or in 174 [DKIM]), the Verifier compares the domain name in the value of that 175 tag with the one found in the RFC5322.From field of the message. The 176 match MUST be done in a case-insensitive manner. 178 If they do not match, the "atps" tag MUST be ignored. 180 If they do match, the Verifier issues a TXT query to the DNS at a 181 specific name looking for confirmation by the Author that the Signer 182 is authorized by the Author to sign mail on its behalf. Where 183 multiple DKIM signatures are present including valid "atps" tags, 184 these queries MAY be done in any order or MAY be done in parallel. 186 Where the RFC5322.From field contains multiple addresses, this 187 process SHOULD be applied if the "atps" tag's value matches any of 188 the domains found in that field. These MAY be done in any order. 190 The name for the query is constructed as follows: 192 1. Select the hash algorithm from the "atpsh" tag in the signature. 193 If none, the default is "sha1". If one is specified but does not 194 appear in the list registered with IANA as one valid for use with 195 DKIM (see Section 7.7 of [DKIM]), abort the query. 197 2. Extract the value of the "d=" tag from the signature. 199 3. Convert any upper-case characters in that string to their lower- 200 case equivalents. 202 4. Feed the resulting string to the selected hash algorithm. 204 5. Convert the output of the hash to a string of printable ASCII 205 characters by applying base32 encoding as defined in Section 6 of 206 [BASE32]. The base32 encoding is used because its output is 207 restricted to characters that are legal for use in labels in the 208 DNS, and evaluates the same way in the DNS whether encoded using 209 uppercase or lowercase characters. 211 6. Append the string "._atps." 213 7. Append the domain name found in the "atps" tag of the validated 214 signature. 216 The query's formal syntax definition, per [ABNF]: 218 atps-query = 1*BASE32 %x2e.5f.61.74.70.73.2e domain-name 220 BASE32 = ( ALPHA / %x32-37 ) 222 See Appendix A for an example of a query construction. 224 4.3. ATPS Reply Details 226 In the descriptions below, the label NOERROR symbolizes DNS response 227 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 228 of [DNS] for further details. 230 At this time, only three possibilities need to be identified in this 231 specification: 233 o An answer is returned (i.e. [DNS] reply code NOERROR with at 234 least one answer) containing a valid ATPS reply. In this case, 235 the protocol has been satisfied and the Verifier can conclude that 236 the signing domain is authorized by the Author to sign its mail. 237 Further queries SHOULD NOT be initiated. 239 o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR 240 with no answers), or one or more answers have been returned as 241 described above but none contain a valid ATPS reply. In this 242 case, the Signer has not been authorized to act as a third-party 243 signer for this Author, and thus the Verifier MUST continue to the 244 next query. 246 o An error is returned (i.e. any other [DNS] reply code). It is no 247 longer possible to determine whether or not this message satisfies 248 the Author's list of authorized third-party signers. The Verifier 249 SHOULD stop processing and defer the message for later processing, 250 such as requesting temporary failure code from the MTA. 252 If all queries are completed and return either NXDOMAIN or NOERROR 253 with no answers, then the Signer was not authorized by the Author. 255 A valid ATPS reply consists of a sequence of tag-value pairs as 256 described in Section 3.2 of [DKIM]. The following tag and value is 257 the only one currently supported in ATPS records: 259 v: Version (plain-text; REQUIRED) This tag defines the version of 260 this specification that applies to the ATPS record. It MUST have 261 the value "ATPS1". ABNF: 263 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 264 ; FWS is imported from [DKIM] 266 5. Interpretation 268 If a Verifier succeeds in confirming that the Author authorized the 269 Signer using this protocol, then the Verifier SHOULD evaluate the 270 message as though the Signer is the Author. 272 This assertion is based on the fact that the Author explicitly 273 endorsed the Signer. Therefore, a module assessing reputation that 274 is based on DKIM signature verification SHOULD apply the reputation 275 of the Author domain instead of, or in addition to, that of the 276 Signer domain. 278 6. Relationship to ADSP 280 [ADSP] defined a protocol by which an Author can advertise a request 281 to message receivers that messages bearing no valid author signature 282 be treated with suspicion or even discarded. 284 A Verifier implementing both ADSP and ATPS SHOULD treat a message for 285 which the ATPS test described above passes as if it were signed by 286 the author domain. That is, a pass of ATPS means a pass for ADSP. 288 7. Experiment Process 290 The working group that developed DKIM was not convinced that third 291 party assertions were critical to DKIM's success, nor were they 292 likely to be immediately useful. However, this was not based on 293 actual experience as there is no specific history on this question. 294 Thus, this experiment was devised. 296 The experimental protocol described here has been implemented as an 297 extension to DKIM in two software products, one of which is open 298 source and seeing increasingly wide use. It is included there to 299 allow customers of those systems to make use of it should they 300 believe such third party assertions are useful to the overall DKIM 301 mechanism. Further adoption as part of the experiment is welcome and 302 encouraged. 304 Use of the protocol and anecdotes of how it affects the overall DKIM 305 experience will be collected by those implementers and the author of 306 this memo. If the response is substantial and positive, advancement 307 along the Standards Track might be warranted. 309 8. IANA Considerations 311 No actions are required by IANA at this time. The following need 312 only be applied if and when this specification reaches the Standards 313 Track. 315 8.1. ATPS Tag Registry 317 An Authorized Third Party Signature (ATPS) Tag Registry will be 318 created by IANA to enumerate the tags that are valid for use in ATPS 319 records. 321 New registrations or updates MUST be published in accordance with the 322 "Specification Required" guidelines described in 323 [IANA-CONSIDERATIONS]. Such registry changes MUST contain the 324 following information: 326 1. Name of the tag being registered or updated 328 2. The document where the specification is created or updated 330 3. The status of the tag, one of "current" (tag is in current use), 331 "deprecated" (tag is in current use but its use is discouraged), 332 or "historic" (tag is no longer in use) 334 The registry's sole initial entry is: 336 +-----+--------------+---------+ 337 | Tag | Specified In | Status | 338 +-----+--------------+---------+ 339 | v | [this memo] | current | 340 +-----+--------------+---------+ 342 8.2. Email Authentication Method Name Registry Update 344 The following should be added to the Email Authentication Method Name 345 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 347 Method dkim-atps 349 Defined In [THIS MEMO] 351 ptype header 353 property from 355 value contents of the [MAIL] From: header field, with comments 356 removed 358 8.3. Email Authentication Result Name Registry Update 360 The following should be added to the Email Authentication Result Name 361 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 363 Code none 365 Existing/New Code existing 367 Defined In [AUTHRES] 369 Auth Method dkim-atps 371 Meaning No valid DKIM signatures were found on the message bearing 372 "atps" tags. 374 Code pass 376 Existing/New Code existing 378 Defined In [AUTHRES] 380 Auth Method dkim-atps 382 Meaning An ATPS evaluation was performed and a valid signature from 383 an authorized third-party was found on the message. 385 Code fail 387 Existing/New Code existing 389 Defined In [AUTHRES] 391 Auth Method dkim-atps 393 Meaning All valid DKIM signatures bearing an "atps" tag either did 394 not reference a domain name found in the RFC5322.From field, or 395 the ATPS test(s) performed failed to confirm a third-party 396 authorization. 398 Code temperror 400 Existing/New Code existing 402 Defined In [AUTHRES] 404 Auth Method dkim-atps 406 Meaning An ATPS evaluation could not be completed due to some error 407 that is likely transient in nature, such as a temporary DNS error. 408 A later attempt may produce a final result. 410 Code permerror 412 Existing/New Code existing 414 Defined In [AUTHRES] 416 Auth Method dkim-atps 418 Meaning An ATPS evaluation could not be completed due to some error 419 that is not likely transient in nature, such as a permanent DNS 420 error. A later attempt is unlikely to produce a final result. 422 8.4. DKIM-Signature Tag Specification Registry 424 The following should be added to the DKIM-Signature Tag Speficication 425 Registry established by [DKIM] as per [IANA-CONSIDERATIONS]: 427 +-------+-------------+---------+ 428 | TYPE | REFERENCE | STATUS | 429 +-------+-------------+---------+ 430 | atps | [THIS MEMO] | current | 431 +-------+-------------+---------+ 432 | atpsh | [THIS MEMO] | current | 433 +-------+-------------+---------+ 435 9. Security Considerations 437 This section discusses potential security issues related to this 438 experimental protocol. 440 9.1. False Privacy 442 The fact that the authorized third-party domain name is hashed and 443 then encoded with base32 may give some the false sense that the 444 relationship between the two parties is somehow protected. This is 445 not the case. Indeed, the very purpose of this protocol is to make 446 it possible for such relationships to be discovered, so such an 447 obscuration would make that process more difficult without a shared 448 secret delivered out-of-band to message verifiers (which also adds 449 further complexity. Rather, the hash and encode steps are done 450 merely to convert any third-party domain name to a fixed width in the 451 construction of the DNS query. 453 9.2. Transient Security Failures 455 Approving a third party signer exposes the Author to the risk that 456 the third party signer becomes compromised and then begins to sign 457 malicious or nuisance messages on behalf of the Author. This can 458 obviously reflect negatively on the Author, and the impact of this 459 can become more severe as automated domain reputation systems are 460 developed and deployed. Thorough vetting and monitoring practices by 461 Authors of third party signers will likely need to become the norm. 463 9.3. Load on the DNS 465 A Verifier participating in DKIM, ADSP and ATPS will now issue a 466 number of TXT queries to the DNS equal to as many as one (for the 467 ADSP query) plus the number of signatures on the message (one for 468 each key that is to be verified) plus the number of signatures that 469 validated which also bear an "atps" tag. This is in addition to any 470 PTR and A queries the MTA may issue at the time the actual message 471 relaying or delivery is initiated. Obviously this can be burdensome 472 on the DNS at both ends, and waiting for that number of queries to 473 return when they are issued in parallel could trigger timeouts in the 474 MTA. 476 An alternative to this that has not yet been explored is the storage 477 of the ATPS data at a specific URL tied to the Author's domain name. 478 This would alleviate pressure on the DNS at the expense of requiring 479 the Author to operate a web server (which has its own security 480 implications) and the addition of the establishment of a TCP 481 connection. Moreover, the Verifier would be well advised to 482 implement caching of this data to prevent ATPS from being used as a 483 denial-of-service vector. 485 10. References 487 10.1. Normative References 489 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 490 Syntax Specifications: ABNF", STD 68, 491 RFC 5234, January 2008. 493 [AUTHRES] Kucherawy, M., "Message Header Field for 494 Indicating Message Authentication Status", 495 RFC 5451, April 2009. 497 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 498 Data Encodings", RFC 4648, October 2006. 500 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. 501 Kucherawy, Ed., "DomainKeys Identified Mail 502 (DKIM) Signatures", RFC 6376, September 2011. 504 [DNS] Mockapetris, P., "Domain names - 505 implementation and specification", STD 13, 506 RFC 1035, November 1987. 508 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 509 Indicate Requirement Levels", BCP 14, 510 RFC 2119, March 1997. 512 10.2. Informative References 514 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 515 Levine, "DomainKeys Identified Mail (DKIM) 516 Author Domain Signing Practices (ADSP)", 517 RFC 5617, August 2009. 519 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 520 RFC 5598, October 2008. 522 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 523 Writing an IANA Considerations Section in 524 RFCs", BCP 26, RFC 5226, May 2008. 526 [MAIL] Resnick, P., Ed., "Internet Message Format", 527 RFC 5322, October 2008. 529 Appendix A. Example Query and Reply 531 This section presents an example of the use of this protocol to query 532 for a third-party authorization and discusses the interpretation of 533 the result. 535 Presume a message for which the RFC5322.From domain is "example.com", 536 and it bears two valid signatures, from "one.example.net" and from 537 "two.example.net", each with an "atps" tag whose value is 538 "example.com", and no "atpsh" tag is present in either. The 539 following actions are taken: 541 1. A SHA1 hash of "one.example.net" is computed and then converted 542 to printable form using base32 encoding, resulting in the string 543 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 545 2. A TXT query is issued to 546 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 548 3. If a valid reply arrives, the algorithm stops with [AUTHRES] 549 result "pass". If a DNS error code other than NXDOMAIN is 550 returned, the algorithm stops with a result of "temperror" or 551 "permerror" as appropriate. 553 4. A SHA1 hash of "two.example.net" is computed and then converted 554 to printable form using base32 encoding, resulting in the string 555 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 557 5. A TXT query is issued to 558 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 560 6. If a valid reply arrives, the algorithm stops with [AUTHRES] 561 result "pass". If a DNS error code other than NXDOMAIN is 562 returned, the algorithm stops with a result of "temperror" or 563 "permerror" as appropriate. 565 7. As there are no valid signatures left to test, the algorithm 566 stops with an "unknown" result. 568 Appendix B. Acknowledgements 570 The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark 571 Martinec and Phil Pennock for their review and constructive criticism 572 of this proposal. 574 The author also wishes to acknowledge Doug Otis and Daniel Black for 575 their original draft upon which this work was based. 577 Author's Address 579 Murray S. Kucherawy 580 Cloudmark, Inc. 581 128 King St., 2nd Floor 582 San Francisco, CA 94107 583 US 585 Phone: +1 415 946 3800 586 EMail: msk@cloudmark.com