idnits 2.17.1 draft-kucherawy-dkim-atps-00.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 228 has weird spacing: '... Method dkim-...' == Line 232 has weird spacing: '... ptype heade...' == Line 234 has weird spacing: '...roperty from...' == Line 236 has weird spacing: '... value conte...' == Line 242 has weird spacing: '... Code none...' == (20 more instances...) -- The document date (September 21, 2010) is 4965 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'THIS MEMO' is mentioned on line 329, 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 September 21, 2010 5 Expires: March 25, 2011 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-00 10 Abstract 12 This memo proposes an experimental proposal to supplement Domain Keys 13 Identified Mail (DKIM) and Author Domain Signing Practices (ADSP) 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 March 25, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6.1. Transient Security Failures . . . . . . . . . . . . . . . 8 63 6.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 10 68 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 [DKIM] defines a mechanism for transparent domain-level signing of 73 messages for the purpose of declaring that a particular 74 Administrative Mail Domain (ADMD) takes some responsibility for a 75 message. [ADSP] creates a mechanism by which an ADMD can declare 76 that mail from it is expected to include a valid DKIM signature from 77 that same ADMD, and mail that does not should be considered suspect 78 or even discarded by receivers. 80 Absent is a mechanism by which an ADMD can announce that signatures 81 on its mail from other ADMDs should also be considered acceptable by 82 verifiers. This memo presents an experimental mechanism for doing 83 so. 85 The results of this experiment are intended to yield statistics or 86 other information as to the efficacy of this or similar models, and 87 may lead to either evolution of this work toward the Standards Track 88 or to its abandonment. We anticipate at least a few interoperating 89 implementations in short order so that the experiment may begin. 91 2. Definitions 93 2.1. Keywords 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [KEYWORDS]. 99 2.2. E-Mail Architecture Terminology 101 Readers should be familiar with the material and terminology 102 discussed in [MAIL] and [EMAIL-ARCH]. 104 3. Discussion 106 Participation in this experiment is divided into two parties: 107 Senders, whose domains appear in the RFC5322.From field of a [MAIL] 108 message, and Verifiers, who implement the validation procedures 109 described in [DKIM] and [ADSP]. 111 A Sender participates in this protocol if it wishes to announce that 112 a message from it (in the RFC5322.From sense) should be considered 113 valid as long as it bears a signature from any in a list of specified 114 domains. One might, for example, wish to delegate signing authority 115 for its DNS domain to an approved messaging service provider. 117 A Verifier participates in this protocol if it wishes to ensure that 118 a message bears one or more signatures from sources approved to sign 119 mail on behalf of the Sender, and identify for special treatment mail 120 that does not meet that criterion. 122 A Verifier with this interest has presumably already implemented ADSP 123 and is therefore making one DNS query for each DKIM signature (to 124 retrieve the matching public key) on the message, and one to check 125 for any published ADSP record. Given this, it seems to make sense 126 that the ADSP record is the right place to declare that this 127 extension is in use. Therefore, a tag indicating this extension will 128 be added to ADSP. 130 4. Queries and Replies 132 This section describes in detail the queries issued, the replies 133 received, and how they should be interpreted and applied. 135 4.1. Extension to ADSP 137 [ADSP] replies contain a "tag=value" sequence, but only one tag 138 ("dkim") is currently defined. 140 This protocol will add an additional tag "atps" whose value is "y" if 141 this extension is in use. The absence of this flag, or any other 142 value in the tag, MUST be ignored and the verifier MUST act as if 143 this protocol is not in use. 145 The formal syntax definition, per [ABNF]: 147 adsp-atps-tag = %x61.74.70.73 *WSP "=" *WSP %x79 149 The registration for this tag can be found in [IANA-CONSIDERATIONS]. 151 4.2. ATPS Query Details 153 If a Sender announces via the ADSP extension that it is using this 154 protocol and the Verifier is also participating, then the Verifier 155 issues a TXT query to the DNS to a specific name looking for 156 confirmation by the sender that a particular third party signature is 157 authorized by the Sender. The query SHOULD be repeated for every 158 domain found in the "d=" tag of a [DKIM] signature on the message 159 that verified. These MAY be done in any order or in parallel. 161 Where the RFC5322.From field contains multiple addresses, this 162 process MAY be repeated for each domain found in the field, and these 163 MAY be done in any order. 165 The name for the query is constructed as follows: 167 1. Extract the value of the "d=" tag from the signature and feed it 168 to the [MD5] hash algorithm. 170 2. Convert the output of the MD5 hash to a string of 32 hexadecimal 171 digits, two for each byte in the hash output, in order. Where 172 alphabetic characters are needed in the conversion, lowercase 173 characters should be used. 175 3. Append the string "._atps." 177 4. Append the domain name found in the RFC5322.From field of the 178 message. 180 The formal syntax definition, per [ABNF]: 182 atps-query = 32*HEXDIG %x2e.5f.61.74.70.73.2e domain-name 184 The "domain-name" is as defined in Section 3.5 of [DKIM]. 186 See Appendix A for an example of a query construction. 188 Since the size of a [DNS] query is limited to 255 bytes, the size of 189 "domain-name" in the ABNF above is constrained to 216 bytes. 191 4.3. ATPS Reply Details 193 At this time, only three possibilities need to be identified in this 194 specification: 196 o An answer is returned (i.e. [DNS] reply code NOERROR). In this 197 case, the protocol has been satisfied and the Verifier may 198 conclude that the signing domain is authorized by the Sender to 199 sign its mail. Further queries SHOULD NOT be initiated. There is 200 at present no need to parse the content (if any) but this is 201 likely to be needed as this protocol is extended. 203 o No answer is returned (i.e. [DNS] reply code NXDOMAIN). In this 204 case, the "d=" domain has not been authorized to act as a third- 205 party signer for this Sender, and thus the Verifier MUST continue 206 to the next query. 208 o An error is returned (i.e. any other [DNS] reply code). It is no 209 longer possible to determine whether or not this message satisfies 210 the Sender's list of authorized third-party signers. The Verifier 211 SHOULD stop processing and defer the message for later processing, 212 such as requesting temporary failure code from the MTA. 214 If all queries are completed and return NXDOMAIN, then the message 215 does not satisfy the policy advertised by the Sender, and the 216 action(s) suggested by the "dkim" tag in the ADSP reply SHOULD be 217 applied. 219 5. IANA Considerations 221 No actions are required by IANA at this time. The following need 222 only be applied if and when this specification reaches the Standards 223 Track. 225 The following should be added to the Email Authentication Method Name 226 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 228 Method dkim-atps 230 Defined In [THIS MEMO] 232 ptype header 234 property from 236 value contents of the [MAIL] From: header field, with contents 237 removed 239 The following should be added to the Email Authentication Result Name 240 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 242 Code none 244 Existing/New Code existing 246 Defined In [AUTHRES] 248 Auth Method dkim-atps 250 Meaning No DKIM Author Domain Signing Practices (ADSP) record was 251 published, or the ADSP record did not indicate ATPS was in use, or 252 ATPS was not performed by the verifier. 254 Code pass 256 Existing/New Code existing 258 Defined In [AUTHRES] 259 Auth Method dkim-atps 261 Meaning An ATPS evaluation was performed and a valid signature from 262 an authorized third-party was found on the message. 264 Code unknown 266 Existing/New Code existing 268 Defined In [ADSP] 270 Auth Method dkim-atps 272 Meaning An ATPS evaluation was performed, no valid signature from an 273 authorized third-party was found on the message, and the published 274 ADSP was "unknown". 276 Code fail 278 Existing/New Code existing 280 Defined In [AUTHRES] 282 Auth Method dkim-atps 284 Meaning An ATPS evaluation was performed, no valid signature from an 285 authorized third-party was found on the message, and the published 286 ADSP was "all". 288 Code discard 290 Existing/New Code existing 292 Defined In [ADSP] 294 Auth Method dkim-atps 296 Meaning An ATPS evaluation was performed, no valid signature from an 297 authorized third-party was found on the message, and the published 298 ADSP was "discardable". 300 Code temperror 302 Existing/New Code existing 303 Defined In [AUTHRES] 305 Auth Method dkim-atps 307 Meaning An ATPS evaluation could not be completed due to some error 308 that is likely transient in nature, such as a temporary DNS error. 309 A later attempt may produce a final result. 311 Code permerror 313 Existing/New Code existing 315 Defined In [AUTHRES] 317 Auth Method dkim-atps 319 Meaning An ATPS evaluation could not be completed due to some error 320 that is not likely transient in nature, such as a permanent DNS 321 error. A later attempt is unlikely to produce a final result. 323 The following should be added to the ADSP Specification Tag Registry 324 established by [ADSP] as per [IANA-CONSIDERATIONS]: 326 +------+-------------+ 327 | TYPE | REFERENCE | 328 +------+-------------+ 329 | atps | [THIS MEMO] | 330 +------+-------------+ 332 6. Security Considerations 334 This section discusses potential security issues related to this 335 experimental protocol. 337 6.1. Transient Security Failures 339 Approving a third party signer exposes the Sender to the risk that 340 the third party signer becomes compromised and then begins to sign 341 malicious or nuisance messages on behalf of the Sender. This can 342 obviously reflect negatively on the Sender, and the impact of this 343 can become more severe as automated domain reputation systems are 344 developed and deployed. Thorough vetting and monitoring practices by 345 Senders of third party signers will likely need to become the norm. 347 6.2. Load on the DNS 349 A Verifier participating in DKIM, ADSP and ATPS will now issue a 350 number of TXT queries to the DNS equal to two plus twice the number 351 of valid signatures on the message plus the number of invalid 352 signatures on the message. This is in addition to any PTR and A 353 queries the MTA may issue at the time the actual message relaying or 354 delivery is initiated. Obviously this can be burdensome on the DNS 355 resolver, and waiting for that number of queries to return when they 356 are issued in parallel can trigger timeouts in the MTA. 358 An alternative to this that has not yet been explored is the storage 359 of the ATPS data at a specific URL tied to the Sender's domain name. 360 This would alleviate pressure on the DNS at the expense of requiring 361 the Sender to operate a web server and the addition of the 362 establishment of a TCP connection. Moreover, the Verifier would be 363 well advised to implement caching of this data to prevent ATPS from 364 being used as a denial-of-service vector. 366 7. References 368 7.1. Normative References 370 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 371 Syntax Specifications: ABNF", STD 68, 372 RFC 5234, January 2008. 374 [AUTHRES] Kucherawy, M., "Message Header Field for 375 Indicating Message Authentication Status", 376 RFC 5451, April 2009. 378 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, 379 M., Fenton, J., and M. Thomas, "DomainKeys 380 Identified Mail (DKIM) Signatures", RFC 4871, 381 May 2007. 383 [DNS] Mockapetris, P., "Domain names - 384 implementation and specification", STD 13, 385 RFC 1035, November 1987. 387 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 388 Indicate Requirement Levels", BCP 14, 389 RFC 2119, March 1997. 391 [MD5] Rivest, R., "The MD5 Message-Digest 392 Algorithm", RFC 1321, April 1992. 394 7.2. Informative References 396 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 397 Levine, "DomainKeys Identified Mail (DKIM) 398 Author Domain Signing Practices (ADSP)", 399 RFC 5617, August 2009. 401 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 402 RFC 5598, October 2008. 404 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 405 Writing an IANA Considerations Section in 406 RFCs", BCP 26, RFC 5226, May 2008. 408 [MAIL] Resnick, P., Ed., "Internet Message Format", 409 RFC 5322, October 2008. 411 Appendix A. Example Query and Reply 413 This section presents an example of the use of this protocol to query 414 for a third-party authorization and discusses the interpretation of 415 the result. 417 Presume a message for which the RFC5322.From domain is "example.com", 418 and it bears two valid signatures, one from "one.example.net" and one 419 from "two.example.net". The following actions are taken: 421 1. A TXT query is made, per [ADSP], to 422 "_adsp._domainkey.example.com" to query for its Author Domain 423 Signing Practices. If no valid reply is returned or the reply 424 does not contain an "atps" tag with value "y", the algorithm 425 stops with [AUTHRES] result "none". 427 2. An MD5 hash of "one.example.net" is computed and converted to 428 hexadecimal form. The result of this is the string 429 "5d6794099a6ce988a5a7ec5f4c285a42". 431 3. A TXT query is issued to 432 "5d6794099a6ce988a5a7ec5f4c285a42._atps.example.com". 434 4. If a reply arrives, the algorithm stops with [AUTHRES] result 435 "pass". If a DNS error code other than NXDOMAIN is returned, the 436 algorithm stops with a result of "temperror" or "permerror" as 437 appropriate. 439 5. An MD5 hash of "two.example.net" is computed and converted to 440 hexadecimal form. The result of this is the string 441 "69ccfaf20790ccf4e348eabc61ed86ad". 443 6. A TXT query is issued to 444 "69ccfaf20790ccf4e348eabc61ed86ad._atps.example.com". 446 7. If a reply arrives, the algorithm stops with [AUTHRES] result 447 "pass". If a DNS error code other than NXDOMAIN is returned, the 448 algorithm stops with a result of "temperror" or "permerror" as 449 appropriate. 451 8. As there are no valid signatures left to test, the algorithm 452 stops with a result of "unknown", "fail" or "discard" as per the 453 value on the ADSP "dkim" tag. 455 Appendix B. Acknowledgements 457 The author wishes to acknowledge the following for their review and 458 constructive criticism of this proposal: (names) 460 The author also wishes to acknowledge Doug Otis and Daniel Black for 461 their original draft upon which this work was based. 463 Author's Address 465 Murray S. Kucherawy 466 Cloudmark, Inc. 467 128 King St., 2nd Floor 468 San Francisco, CA 94107 469 US 471 Phone: +1 415 946 3800 472 EMail: msk@cloudmark.com