idnits 2.17.1 draft-kucherawy-dkim-atps-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 == Line 288 has weird spacing: '... Method dkim-...' == Line 292 has weird spacing: '... ptype heade...' == Line 294 has weird spacing: '...roperty from...' == Line 296 has weird spacing: '... value conte...' == Line 304 has weird spacing: '... Code none...' == (20 more instances...) -- The document date (March 28, 2011) is 4776 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 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 (==), 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 March 28, 2011 5 Expires: September 29, 2011 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-03 10 Abstract 12 This memo presents an experimental proposal to supplement Domain Keys 13 Identified Mail (DKIM) and Author Domain Signing Practices (ADSP) by 14 allowing advertisement of third-party signature authorizations on 15 behalf of an email originator. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 29, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . 3 55 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Queries and Replies . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Extension to ADSP . . . . . . . . . . . . . . . . . . . . 4 58 4.2. ATPS Query Details . . . . . . . . . . . . . . . . . . . . 4 59 4.3. ATPS Reply Details . . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 6 62 5.2. Email Authentication Method Name Registry Update . . . . . 7 63 5.3. Email Authentication Result Name Registry Update . . . . . 7 64 5.4. ADSP Specification Tag Registry . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6.1. Transient Security Failures . . . . . . . . . . . . . . . 10 67 6.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 11 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 [DKIM] defines a mechanism for transparent domain-level signing of 77 messages for the purpose of declaring that a particular 78 Administrative Mail Domain (ADMD) takes some responsibility for a 79 message. [ADSP] creates a mechanism by which an ADMD can declare 80 that mail from it is expected to include a valid DKIM signature from 81 that same ADMD, and mail that does not should be considered suspect 82 or even refused by receivers. 84 Absent is a mechanism by which an ADMD can announce that signatures 85 on its mail from other ADMDs should also be considered authentic by 86 verifiers. This memo presents an experimental mechanism for doing 87 so. 89 The results of this experiment are intended to yield statistics or 90 other information as to the efficacy of this or similar models, and 91 may lead to either evolution of this work toward the Standards Track 92 or to its abandonment. We anticipate at least a few interoperating 93 implementations in short order so that the experiment can begin. 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 experiment is divided into two parties: 111 Senders, whose domains appear in the RFC5322.From field of a [MAIL] 112 message, and Verifiers, who implement the validation procedures 113 described in both [DKIM] and [ADSP]. 115 A Sender participates in this protocol if it wishes to announce that 116 a message from it (in the RFC5322.From sense) should be considered 117 authentic as long as it bears a signature from any in a set of 118 specified domains. One might, for example, wish to delegate signing 119 authority for its DNS domain to an approved messaging service 120 provider without doing the work of key transfer described in Appendix 121 B.1.1 of [DKIM]. 123 A Verifier participates in this protocol if it wishes to ensure that 124 a message bears one or more signatures from sources approved to sign 125 mail on behalf of the Sender, and identify for special treatment mail 126 that does not meet that criterion. 128 A Verifier with this interest has presumably already implemented ADSP 129 and is therefore making one DNS query for each DKIM signature (to 130 retrieve the matching public key) on the message, and one to check 131 for any published ADSP record. Given this, it seems to make sense 132 that the ADSP record is the right place to declare that this 133 extension is in use. Therefore, a tag indicating this extension will 134 be added to ADSP. 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 ADSP 143 [ADSP] replies contain a "tag=value" sequence, but only one tag 144 ("dkim") is currently defined. 146 This protocol will add an additional tag "atps" whose value is "y" if 147 this extension is in use. The absence of this tag, or its presence 148 with any other value, MUST be ignored and the Verifier MUST act as if 149 this protocol is not in use. 151 The formal syntax definition, per [ABNF]: 153 adsp-atps-tag = %x61.74.70.73 *WSP "=" *WSP %x79 155 The registration for this tag can be found in Section 5. 157 4.2. ATPS Query Details 159 If a Sender announces via the ADSP extension that it is using this 160 protocol and the Verifier is also participating, then the Verifier 161 issues a TXT query to the DNS to a specific name looking for 162 confirmation by the Sender that a particular third party signature is 163 authorized by the Sender. The query SHOULD be repeated for every 164 domain found in the "d=" tag of a [DKIM] signature on the message 165 that verified and is not otherwise considered unacceptable to the 166 Verifier for policy reasons. These MAY be done in any order or MAY 167 be done in parallel. 169 Where the RFC5322.From field contains multiple addresses, this 170 process MAY be repeated for each domain found in the field, and these 171 MAY be done in any order. 173 The name for the query is constructed as follows: 175 1. Extract the value of the "d=" tag from the signature. 177 2. Convert any upper-case characters in that string to their lower- 178 case equivalents. 180 3. Feed the resulting string to the [SHA1] hash algorithm. 182 4. Convert the output of the SHA1 hash to a string of 32 183 alphanumeric characters by applying base32 encoding as defined in 184 Section 6 of [BASE32]. The base32 encoding is used because its 185 output is restricted to characters that are legal for use in 186 labels in the DNS, and evaluates the same way in the DNS whether 187 encoded using uppercase or lowercase characters. 189 5. Append the string "._atps." 191 6. Append the domain name found in the RFC5322.From field of the 192 message. 194 The query's formal syntax definition, per [ABNF]: 196 atps-query = 32*BASE32 %x2e.5f.61.74.70.73.2e domain-name 198 BASE32 = ( ALPHA / %x32-37 ) 200 The "domain-name" is as defined in Section 3.5 of [DKIM]. 202 See Appendix A for an example of a query construction. 204 Since the size of a [DNS] query is limited to 255 bytes, the size of 205 "domain-name" in the ABNF above is constrained to 216 bytes. 207 4.3. ATPS Reply Details 209 In the descriptions below, the label NOERROR symbolizes DNS response 210 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 211 of [DNS] for further details. 213 At this time, only three possibilities need to be identified in this 214 specification: 216 o An answer is returned (i.e. [DNS] reply code NOERROR with at 217 least one answer) containing a valid ATPS reply. In this case, 218 the protocol has been satisfied and the Verifier may conclude that 219 the signing domain is authorized by the Sender 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 "d=" domain has not been authorized to act as a third- 226 party signer for this Sender, and thus the Verifier MUST continue 227 to the 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 Sender'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 NXDOMAIN, then the message 236 does not satisfy the policy advertised by the Sender, and the 237 action(s) specified by the "dkim" tag in the ADSP reply SHOULD be 238 applied. 240 A valid ATPS reply consists of a sequence of tag-value pairs as 241 described in Section 3.2 of [DKIM]. The following tag and value is 242 the only one currently supported in ATPS records: 244 v: Version (plain-text; REQUIRED) This tag defines the version of 245 this specification that applies to the ATPS record. It MUST have 246 the value "ATPS1". ABNF: 248 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 250 5. IANA Considerations 252 No actions are required by IANA at this time. The following need 253 only be applied if and when this specification reaches the Standards 254 Track. 256 5.1. ATPS Tag Registry 258 An Authorized Third Party Signature (ATPS) Tag Registry will be 259 created by IANA to enumerate the tags that are valid for use in ATPS 260 records. 262 New registrations or updates MUST be published in accordance with the 263 "Specification Required" guidelines described in 264 [IANA-CONSIDERATIONS]. Such registry changes MUST contain the 265 following information: 267 1. Name of the tag being registered or updated 269 2. The document where the specification is created or updated 271 3. The status of the tag, one of "current" (tag is in current use), 272 "deprecated" (tag is in current use but its use is discouraged), 273 or "historic" (tag is no longer in use) 275 The registry's sole initial entry is: 277 +-----+--------------+---------+ 278 | Tag | Specified In | Status | 279 +-----+--------------+---------+ 280 | v | [this memo] | current | 281 +-----+--------------+---------+ 283 5.2. Email Authentication Method Name Registry Update 285 The following should be added to the Email Authentication Method Name 286 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 288 Method dkim-atps 290 Defined In [THIS MEMO] 292 ptype header 294 property from 296 value contents of the [MAIL] From: header field, with comments 297 removed 299 5.3. Email Authentication Result Name Registry Update 301 The following should be added to the Email Authentication Result Name 302 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 304 Code none 306 Existing/New Code existing 308 Defined In [AUTHRES] 310 Auth Method dkim-atps 311 Meaning No DKIM Author Domain Signing Practices (ADSP) record was 312 published, or the ADSP record did not indicate ATPS was in use, or 313 ATPS was not performed by the verifier. 315 Code pass 317 Existing/New Code existing 319 Defined In [AUTHRES] 321 Auth Method dkim-atps 323 Meaning An ATPS evaluation was performed and a valid signature from 324 an authorized third-party was found on the message. 326 Code unknown 328 Existing/New Code existing 330 Defined In [ADSP] 332 Auth Method dkim-atps 334 Meaning An ATPS evaluation was performed, no valid signature from an 335 authorized third-party was found on the message, and the published 336 ADSP was "unknown". 338 Code fail 340 Existing/New Code existing 342 Defined In [AUTHRES] 344 Auth Method dkim-atps 346 Meaning An ATPS evaluation was performed, no valid signature from an 347 authorized third-party was found on the message, and the published 348 ADSP was "all". 350 Code discard 352 Existing/New Code existing 354 Defined In [ADSP] 355 Auth Method dkim-atps 357 Meaning An ATPS evaluation was performed, no valid signature from an 358 authorized third-party was found on the message, and the published 359 ADSP was "discardable". 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 5.4. ADSP Specification Tag Registry 387 The following should be added to the ADSP Specification Tag Registry 388 established by [ADSP] as per [IANA-CONSIDERATIONS]: 390 +------+-------------+ 391 | TYPE | REFERENCE | 392 +------+-------------+ 393 | atps | [THIS MEMO] | 394 +------+-------------+ 396 6. Security Considerations 398 This section discusses potential security issues related to this 399 experimental protocol. 401 6.1. Transient Security Failures 403 Approving a third party signer exposes the Sender 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 Sender. This can 406 obviously reflect negatively on the Sender, 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 Senders of third party signers will likely need to become the norm. 411 6.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 one (for the ADSP query) 415 plus twice the number of valid signatures on the message (one for 416 each key, one for an ATPS record) plus the number of invalid 417 signatures on the message (one for each key). This is in addition to 418 any PTR and A queries the MTA may issue at the time the actual 419 message relaying or delivery is initiated. Obviously this can be 420 burdensome on the DNS at both ends, and waiting for that number of 421 queries to return when they are issued in parallel could trigger 422 timeouts in the 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 Sender's domain name. 426 This would alleviate pressure on the DNS at the expense of requiring 427 the Sender 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 7. References 435 7.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] Allman, E., Callas, J., Delany, M., Libbey, 449 M., Fenton, J., and M. Thomas, "DomainKeys 450 Identified Mail (DKIM) Signatures", RFC 4871, 451 May 2007. 453 [DNS] Mockapetris, P., "Domain names - 454 implementation and specification", STD 13, 455 RFC 1035, November 1987. 457 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 458 Indicate Requirement Levels", BCP 14, 459 RFC 2119, March 1997. 461 [SHA1] U.S. Department of Commerce, "Secure Hash 462 Standard", FIPS PUB 180-2, August 2002. 464 7.2. Informative References 466 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 467 Levine, "DomainKeys Identified Mail (DKIM) 468 Author Domain Signing Practices (ADSP)", 469 RFC 5617, August 2009. 471 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 472 RFC 5598, October 2008. 474 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 475 Writing an IANA Considerations Section in 476 RFCs", BCP 26, RFC 5226, May 2008. 478 [MAIL] Resnick, P., Ed., "Internet Message Format", 479 RFC 5322, October 2008. 481 Appendix A. Example Query and Reply 483 This section presents an example of the use of this protocol to query 484 for a third-party authorization and discusses the interpretation of 485 the result. 487 Presume a message for which the RFC5322.From domain is "example.com", 488 and it bears two valid signatures, one from "one.example.net" and one 489 from "two.example.net". The following actions are taken: 491 1. A TXT query is made, per [ADSP], to 492 "_adsp._domainkey.example.com" to query for its Author Domain 493 Signing Practices. If no valid reply is returned or the reply 494 does not contain an "atps" tag with value "y", the algorithm 495 stops with [AUTHRES] result "none". 497 2. A SHA1 hash of "one.example.net" is computed and then converted 498 to printable form using base32 encoding, resulting in the string 499 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 501 3. A TXT query is issued to 502 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 504 4. If a reply arrives, the algorithm stops with [AUTHRES] result 505 "pass". If a DNS error code other than NXDOMAIN is returned, the 506 algorithm stops with a result of "temperror" or "permerror" as 507 appropriate. 509 5. A SHA1 hash of "two.example.net" is computed and then converted 510 to printable form using base32 encoding, resulting in the string 511 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 513 6. A TXT query is issued to 514 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 516 7. If a reply arrives, the algorithm stops with [AUTHRES] result 517 "pass". If a DNS error code other than NXDOMAIN is returned, the 518 algorithm stops with a result of "temperror" or "permerror" as 519 appropriate. 521 8. As there are no valid signatures left to test, the algorithm 522 stops with a result of "unknown", "fail" or "discard" as per the 523 value on the ADSP "dkim" tag. 525 Appendix B. Acknowledgements 527 The author wishes to acknowledge the following for their review and 528 constructive criticism of this proposal: Mark Martinec 530 The author also wishes to acknowledge Doug Otis and Daniel Black for 531 their original draft upon which this work was based. 533 Author's Address 535 Murray S. Kucherawy 536 Cloudmark, Inc. 537 128 King St., 2nd Floor 538 San Francisco, CA 94107 539 US 541 Phone: +1 415 946 3800 542 EMail: msk@cloudmark.com