idnits 2.17.1 draft-kucherawy-dkim-atps-05.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 302 has weird spacing: '... Method dkim-...' == Line 306 has weird spacing: '... ptype heade...' == Line 308 has weird spacing: '...roperty from...' == Line 310 has weird spacing: '... value conte...' == Line 318 has weird spacing: '... Code none...' == (14 more instances...) (Using the creation date from RFC5617, updated by this document, for RFC5378 checks: 2007-06-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2011) is 4655 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'THIS MEMO' is mentioned on line 385, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: 5617 (if approved) July 30, 2011 5 Intended status: Experimental 6 Expires: January 31, 2012 8 DKIM Authorized Third-Party Signers 9 draft-kucherawy-dkim-atps-05 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 RFC5617. 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 January 31, 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. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Email Authentication Method Name Registry Update . . . . . 7 66 6.3. Email Authentication Result Name Registry Update . . . . . 7 67 6.4. DKIM-Signature Tag Specification Registry . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7.1. Transient Security Failures . . . . . . . . . . . . . . . 9 70 7.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 11 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 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]. 129 A Verifier participates in this protocol if it wishes to ensure that 130 a message bears one or more signatures from sources approved to sign 131 mail on behalf of the Author, and identify for special treatment mail 132 that meets (or does not meet) that criterion. 134 A Verifier with this interest has presumably already implemented DKIM 135 and is therefore making one DNS query for each DKIM signature (to 136 retrieve the matching public key) on the message, and perhaps one to 137 apply the protocol defined in [ADSP]. Therefore, a tag indicating 138 this extension will be added to DKIM's signature tag list. 140 4. Queries and Replies 142 This section describes in detail the queries issued, the replies 143 received, and how they should be interpreted and applied. 145 4.1. Extension to DKIM 147 [DKIM] signatures contain a "tag=value" sequence. This protocol will 148 add an additional tag called "atps". When the Signer generates a 149 DKIM signature on behalf of an Author, it MUST include this tag in 150 the signature and include as its value the Author's domain name. 152 The formal syntax definition, per [ABNF]: 154 dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name 156 "domain-name" is imported from [DKIM]. 158 The registration for this tag can be found in Section 6. 160 4.2. ATPS Query Details 162 When a [DKIM] signature including an "atps" tag is successfully 163 verified, and is considered acceptable to the Verifier according to 164 any local policy requirements (which are not discussed here or in 165 [DKIM]), the Verifier compares the domain name in the value of that 166 tag with the one found in the RFC5322.From field of the message. The 167 match MUST be done in a case-insensitive manner. 169 If they do not match, the "atps" tag MUST be ignored. 171 If they do match, the Verifier issues a TXT query to the DNS to a 172 specific name looking for confirmation by the Author that the Signer 173 is authorized by the Author to sign mail on its behalf. Where 174 multiple DKIM signatures are present including valid "atps" tags, 175 these queries MAY be done in any order or MAY be done in parallel. 177 Where the RFC5322.From field contains multiple addresses, this 178 process SHOULD be applied if the "atps" tag's value matches any of 179 the domains found in that field. These MAY be done in any order. 181 The name for the query is constructed as follows: 183 1. Extract the value of the "d=" tag from the signature. 185 2. Convert any upper-case characters in that string to their lower- 186 case equivalents. 188 3. Feed the resulting string to the [SHA1] hash algorithm. 190 4. Convert the output of the SHA1 hash to a string of 32 191 alphanumeric characters by applying base32 encoding as defined in 192 Section 6 of [BASE32]. The base32 encoding is used because its 193 output is restricted to characters that are legal for use in 194 labels in the DNS, and evaluates the same way in the DNS whether 195 encoded using uppercase or lowercase characters. 197 5. Append the string "._atps." 199 6. Append the domain name found in the "atps" tag of the validated 200 signature. 202 The query's formal syntax definition, per [ABNF]: 204 atps-query = 32*BASE32 %x2e.5f.61.74.70.73.2e domain-name 206 BASE32 = ( ALPHA / %x32-37 ) 208 See Appendix A for an example of a query construction. 210 Since the size of a [DNS] query is limited to 255 bytes, the size of 211 "domain-name" in the ABNF above is constrained to 216 bytes. 213 4.3. ATPS Reply Details 215 In the descriptions below, the label NOERROR symbolizes DNS response 216 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 217 of [DNS] for further details. 219 At this time, only three possibilities need to be identified in this 220 specification: 222 o An answer is returned (i.e. [DNS] reply code NOERROR with at 223 least one answer) containing a valid ATPS reply. In this case, 224 the protocol has been satisfied and the Verifier may conclude that 225 the signing domain is authorized by the Author to sign its mail. 226 Further queries SHOULD NOT be initiated. 228 o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR 229 with no answers), or one or more answers have been returned as 230 described above but none contain a valid ATPS reply. In this 231 case, the Signer has not been authorized to act as a third-party 232 signer for this Author, and thus the Verifier MUST continue to the 233 next query. 235 o An error is returned (i.e. any other [DNS] reply code). It is no 236 longer possible to determine whether or not this message satisfies 237 the Author's list of authorized third-party signers. The Verifier 238 SHOULD stop processing and defer the message for later processing, 239 such as requesting temporary failure code from the MTA. 241 If all queries are completed and return NXDOMAIN, then the Signer was 242 not authorized by the Author. 244 A valid ATPS reply consists of a sequence of tag-value pairs as 245 described in Section 3.2 of [DKIM]. The following tag and value is 246 the only one currently supported in ATPS records: 248 v: Version (plain-text; REQUIRED) This tag defines the version of 249 this specification that applies to the ATPS record. It MUST have 250 the value "ATPS1". ABNF: 252 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 254 5. Relationship to ADSP 256 [ADSP] defined a protocol by which an Author can advertise a request 257 to message receivers that messages bearing no valid author signature 258 be treated with suspicion or even discarded. 260 A Verifier implementing both ADSP and ATPS MAY treat a message for 261 which the ATPS test described above passes as if it were signed by 262 the author domain. That is, a pass of ATPS means a pass for ADSP. 264 6. IANA Considerations 266 No actions are required by IANA at this time. The following need 267 only be applied if and when this specification reaches the Standards 268 Track. 270 6.1. ATPS Tag Registry 272 An Authorized Third Party Signature (ATPS) Tag Registry will be 273 created by IANA to enumerate the tags that are valid for use in ATPS 274 records. 276 New registrations or updates MUST be published in accordance with the 277 "Specification Required" guidelines described in 278 [IANA-CONSIDERATIONS]. Such registry changes MUST contain the 279 following information: 281 1. Name of the tag being registered or updated 283 2. The document where the specification is created or updated 285 3. The status of the tag, one of "current" (tag is in current use), 286 "deprecated" (tag is in current use but its use is discouraged), 287 or "historic" (tag is no longer in use) 289 The registry's sole initial entry is: 291 +-----+--------------+---------+ 292 | Tag | Specified In | Status | 293 +-----+--------------+---------+ 294 | v | [this memo] | current | 295 +-----+--------------+---------+ 297 6.2. Email Authentication Method Name Registry Update 299 The following should be added to the Email Authentication Method Name 300 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 302 Method dkim-atps 304 Defined In [THIS MEMO] 306 ptype header 308 property from 310 value contents of the [MAIL] From: header field, with comments 311 removed 313 6.3. Email Authentication Result Name Registry Update 315 The following should be added to the Email Authentication Result Name 316 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 318 Code none 320 Existing/New Code existing 322 Defined In [AUTHRES] 324 Auth Method dkim-atps 326 Meaning No valid DKIM signatures were found on the message bearing 327 "atps" tags. 329 Code pass 331 Existing/New Code existing 333 Defined In [AUTHRES] 335 Auth Method dkim-atps 337 Meaning An ATPS evaluation was performed and a valid signature from 338 an authorized third-party was found on the message. 340 Code fail 342 Existing/New Code existing 344 Defined In [AUTHRES] 346 Auth Method dkim-atps 348 Meaning All valid DKIM signatures bearing an "atps" tag either did 349 not reference a domain name found in the RFC5322.From field, or 350 the ATPS test(s) performed failed to confirm a third-party 351 authorization. 353 Code temperror 355 Existing/New Code existing 357 Defined In [AUTHRES] 359 Auth Method dkim-atps 361 Meaning An ATPS evaluation could not be completed due to some error 362 that is likely transient in nature, such as a temporary DNS error. 363 A later attempt may produce a final result. 365 Code permerror 367 Existing/New Code existing 369 Defined In [AUTHRES] 371 Auth Method dkim-atps 373 Meaning An ATPS evaluation could not be completed due to some error 374 that is not likely transient in nature, such as a permanent DNS 375 error. A later attempt is unlikely to produce a final result. 377 6.4. DKIM-Signature Tag Specification Registry 379 The following should be added to the DKIM-Signature Tag Speficication 380 Registry established by [DKIM] as per [IANA-CONSIDERATIONS]: 382 +------+-------------+ 383 | TYPE | REFERENCE | 384 +------+-------------+ 385 | atps | [THIS MEMO] | 386 +------+-------------+ 388 7. Security Considerations 390 This section discusses potential security issues related to this 391 experimental protocol. 393 7.1. Transient Security Failures 395 Approving a third party signer exposes the Author to the risk that 396 the third party signer becomes compromised and then begins to sign 397 malicious or nuisance messages on behalf of the Author. This can 398 obviously reflect negatively on the Author, and the impact of this 399 can become more severe as automated domain reputation systems are 400 developed and deployed. Thorough vetting and monitoring practices by 401 Authors of third party signers will likely need to become the norm. 403 7.2. Load on the DNS 405 A Verifier participating in DKIM, ADSP and ATPS will now issue a 406 number of TXT queries to the DNS equal to one (for the ADSP query) 407 plus twice the number of valid signatures on the message (one for 408 each key, one for an ATPS record) plus the number of invalid 409 signatures on the message (one for each key). This is in addition to 410 any PTR and A queries the MTA may issue at the time the actual 411 message relaying or delivery is initiated. Obviously this can be 412 burdensome on the DNS at both ends, and waiting for that number of 413 queries to return when they are issued in parallel could trigger 414 timeouts in the MTA. 416 An alternative to this that has not yet been explored is the storage 417 of the ATPS data at a specific URL tied to the Author's domain name. 418 This would alleviate pressure on the DNS at the expense of requiring 419 the Author to operate a web server (which has its own security 420 implications) and the addition of the establishment of a TCP 421 connection. Moreover, the Verifier would be well advised to 422 implement caching of this data to prevent ATPS from being used as a 423 denial-of-service vector. 425 8. References 427 8.1. Normative References 429 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 430 Syntax Specifications: ABNF", STD 68, 431 RFC 5234, January 2008. 433 [AUTHRES] Kucherawy, M., "Message Header Field for 434 Indicating Message Authentication Status", 435 RFC 5451, April 2009. 437 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 438 Data Encodings", RFC 4648, October 2006. 440 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, 441 M., Fenton, J., and M. Thomas, "DomainKeys 442 Identified Mail (DKIM) Signatures", RFC 4871, 443 May 2007. 445 [DNS] Mockapetris, P., "Domain names - 446 implementation and specification", STD 13, 447 RFC 1035, November 1987. 449 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 450 Indicate Requirement Levels", BCP 14, 451 RFC 2119, March 1997. 453 [SHA1] U.S. Department of Commerce, "Secure Hash 454 Standard", FIPS PUB 180-2, August 2002. 456 8.2. Informative References 458 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 459 Levine, "DomainKeys Identified Mail (DKIM) 460 Author Domain Signing Practices (ADSP)", 461 RFC 5617, August 2009. 463 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 464 RFC 5598, October 2008. 466 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 467 Writing an IANA Considerations Section in 468 RFCs", BCP 26, RFC 5226, May 2008. 470 [MAIL] Resnick, P., Ed., "Internet Message Format", 471 RFC 5322, October 2008. 473 Appendix A. Example Query and Reply 475 This section presents an example of the use of this protocol to query 476 for a third-party authorization and discusses the interpretation of 477 the result. 479 Presume a message for which the RFC5322.From domain is "example.com", 480 and it bears two valid signatures, from "one.example.net" and from 481 "two.example.net", each with an "atps" whose value is "example.com". 482 The following actions are taken: 484 1. A SHA1 hash of "one.example.net" is computed and then converted 485 to printable form using base32 encoding, resulting in the string 486 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 488 2. A TXT query is issued to 489 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 491 3. If a valid reply arrives, the algorithm stops with [AUTHRES] 492 result "pass". If a DNS error code other than NXDOMAIN is 493 returned, the algorithm stops with a result of "temperror" or 494 "permerror" as appropriate. 496 4. A SHA1 hash of "two.example.net" is computed and then converted 497 to printable form using base32 encoding, resulting in the string 498 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 500 5. A TXT query is issued to 501 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 503 6. If a valid reply arrives, the algorithm stops with [AUTHRES] 504 result "pass". If a DNS error code other than NXDOMAIN is 505 returned, the algorithm stops with a result of "temperror" or 506 "permerror" as appropriate. 508 7. As there are no valid signatures left to test, the algorithm 509 stops with an "unknown" result. 511 Appendix B. Acknowledgements 513 The author wishes to acknowledge the following for their review and 514 constructive criticism of this proposal: Mark Martinec 516 The author also wishes to acknowledge Doug Otis and Daniel Black for 517 their original draft upon which this work was based. 519 Author's Address 521 Murray S. Kucherawy 522 Cloudmark, Inc. 523 128 King St., 2nd Floor 524 San Francisco, CA 94107 525 US 527 Phone: +1 415 946 3800 528 EMail: msk@cloudmark.com