idnits 2.17.1 draft-kucherawy-dkim-atps-02.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 242 has weird spacing: '... Method dkim-...' == Line 246 has weird spacing: '... ptype heade...' == Line 248 has weird spacing: '...roperty from...' == Line 250 has weird spacing: '... value conte...' == Line 258 has weird spacing: '... Code none...' == (20 more instances...) -- The document date (January 7, 2011) is 4857 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'THIS MEMO' is mentioned on line 347, 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 January 7, 2011 5 Expires: July 11, 2011 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-02 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 July 11, 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. Email Authentication Method Name Registry Update . . . . . 6 62 5.2. Email Authentication Result Name Registry Update . . . . . 6 63 5.3. ADSP Specification Tag Registry . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6.1. Transient Security Failures . . . . . . . . . . . . . . . 9 66 6.2. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 10 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 [DKIM] defines a mechanism for transparent domain-level signing of 76 messages for the purpose of declaring that a particular 77 Administrative Mail Domain (ADMD) takes some responsibility for a 78 message. [ADSP] creates a mechanism by which an ADMD can declare 79 that mail from it is expected to include a valid DKIM signature from 80 that same ADMD, and mail that does not should be considered suspect 81 or even discarded by receivers. 83 Absent is a mechanism by which an ADMD can announce that signatures 84 on its mail from other ADMDs should also be considered authentic by 85 verifiers. This memo presents an experimental mechanism for doing 86 so. 88 The results of this experiment are intended to yield statistics or 89 other information as to the efficacy of this or similar models, and 90 may lead to either evolution of this work toward the Standards Track 91 or to its abandonment. We anticipate at least a few interoperating 92 implementations in short order so that the experiment can begin. 94 2. Definitions 96 2.1. Keywords 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [KEYWORDS]. 102 2.2. E-Mail Architecture Terminology 104 Readers should be familiar with the material and terminology 105 discussed in [MAIL] and [EMAIL-ARCH]. 107 3. Discussion 109 Participation in this experiment is divided into two parties: 110 Senders, whose domains appear in the RFC5322.From field of a [MAIL] 111 message, and Verifiers, who implement the validation procedures 112 described in both [DKIM] and [ADSP]. 114 A Sender participates in this protocol if it wishes to announce that 115 a message from it (in the RFC5322.From sense) should be considered 116 authentic as long as it bears a signature from any in a set of 117 specified domains. One might, for example, wish to delegate signing 118 authority for its DNS domain to an approved messaging service 119 provider without doing the work of key transfer described in Appendix 120 B.1.1 of [DKIM]. 122 A Verifier participates in this protocol if it wishes to ensure that 123 a message bears one or more signatures from sources approved to sign 124 mail on behalf of the Sender, and identify for special treatment mail 125 that does not meet that criterion. 127 A Verifier with this interest has presumably already implemented ADSP 128 and is therefore making one DNS query for each DKIM signature (to 129 retrieve the matching public key) on the message, and one to check 130 for any published ADSP record. Given this, it seems to make sense 131 that the ADSP record is the right place to declare that this 132 extension is in use. Therefore, a tag indicating this extension will 133 be added to ADSP. 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 ADSP 142 [ADSP] replies contain a "tag=value" sequence, but only one tag 143 ("dkim") is currently defined. 145 This protocol will add an additional tag "atps" whose value is "y" if 146 this extension is in use. The absence of this tag, or its presence 147 with any other value, MUST be ignored and the Verifier MUST act as if 148 this protocol is not in use. 150 The formal syntax definition, per [ABNF]: 152 adsp-atps-tag = %x61.74.70.73 *WSP "=" *WSP %x79 154 The registration for this tag can be found in Section 5. 156 4.2. ATPS Query Details 158 If a Sender announces via the ADSP extension that it is using this 159 protocol and the Verifier is also participating, then the Verifier 160 issues a TXT query to the DNS to a specific name looking for 161 confirmation by the Sender that a particular third party signature is 162 authorized by the Sender. The query SHOULD be repeated for every 163 domain found in the "d=" tag of a [DKIM] signature on the message 164 that verified and is not otherwise considered unacceptable to the 165 Verifier for policy reasons. These MAY be done in any order or MAY 166 be done in parallel. 168 Where the RFC5322.From field contains multiple addresses, this 169 process MAY be repeated for each domain found in the field, and these 170 MAY be done in any order. 172 The name for the query is constructed as follows: 174 1. Extract the value of the "d=" tag from the signature. 176 2. Convert any upper-case characters in that string to their lower- 177 case equivalents. 179 3. Feed the resulting string to the [SHA1] hash algorithm. 181 4. Convert the output of the SHA1 hash to a string of 32 hexadecimal 182 digits by applying base32 encoding as defined in Section 6 of 183 [BASE32]. 185 5. Append the string "._atps." 187 6. Append the domain name found in the RFC5322.From field of the 188 message. 190 The query's formal syntax definition, per [ABNF]: 192 atps-query = 32*BASE32 %x2e.5f.61.74.70.73.2e domain-name 194 BASE32 = ( ALPHA / %x32-37 ) 196 The "domain-name" is as defined in Section 3.5 of [DKIM]. 198 See Appendix A for an example of a query construction. 200 Since the size of a [DNS] query is limited to 255 bytes, the size of 201 "domain-name" in the ABNF above is constrained to 216 bytes. 203 4.3. ATPS Reply Details 205 At this time, only three possibilities need to be identified in this 206 specification: 208 o An answer is returned (i.e. [DNS] reply code NOERROR). In this 209 case, the protocol has been satisfied and the Verifier may 210 conclude that the signing domain is authorized by the Sender to 211 sign its mail. Further queries SHOULD NOT be initiated. There is 212 at present no need to parse the content (if any) but this is 213 likely to be needed as this protocol is extended. 215 o No answer is returned (i.e. [DNS] reply code NXDOMAIN). In this 216 case, the "d=" domain has not been authorized to act as a third- 217 party signer for this Sender, and thus the Verifier MUST continue 218 to the next query. 220 o An error is returned (i.e. any other [DNS] reply code). It is no 221 longer possible to determine whether or not this message satisfies 222 the Sender's list of authorized third-party signers. The Verifier 223 SHOULD stop processing and defer the message for later processing, 224 such as requesting temporary failure code from the MTA. 226 If all queries are completed and return NXDOMAIN, then the message 227 does not satisfy the policy advertised by the Sender, and the 228 action(s) specified by the "dkim" tag in the ADSP reply SHOULD be 229 applied. 231 5. IANA Considerations 233 No actions are required by IANA at this time. The following need 234 only be applied if and when this specification reaches the Standards 235 Track. 237 5.1. Email Authentication Method Name Registry Update 239 The following should be added to the Email Authentication Method Name 240 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 242 Method dkim-atps 244 Defined In [THIS MEMO] 246 ptype header 248 property from 250 value contents of the [MAIL] From: header field, with comments 251 removed 253 5.2. Email Authentication Result Name Registry Update 255 The following should be added to the Email Authentication Result Name 256 Registry established by [AUTHRES] as per [IANA-CONSIDERATIONS]: 258 Code none 260 Existing/New Code existing 262 Defined In [AUTHRES] 263 Auth Method dkim-atps 265 Meaning No DKIM Author Domain Signing Practices (ADSP) record was 266 published, or the ADSP record did not indicate ATPS was in use, or 267 ATPS was not performed by the verifier. 269 Code pass 271 Existing/New Code existing 273 Defined In [AUTHRES] 275 Auth Method dkim-atps 277 Meaning An ATPS evaluation was performed and a valid signature from 278 an authorized third-party was found on the message. 280 Code unknown 282 Existing/New Code existing 284 Defined In [ADSP] 286 Auth Method dkim-atps 288 Meaning An ATPS evaluation was performed, no valid signature from an 289 authorized third-party was found on the message, and the published 290 ADSP was "unknown". 292 Code fail 294 Existing/New Code existing 296 Defined In [AUTHRES] 298 Auth Method dkim-atps 300 Meaning An ATPS evaluation was performed, no valid signature from an 301 authorized third-party was found on the message, and the published 302 ADSP was "all". 304 Code discard 306 Existing/New Code existing 307 Defined In [ADSP] 309 Auth Method dkim-atps 311 Meaning An ATPS evaluation was performed, no valid signature from an 312 authorized third-party was found on the message, and the published 313 ADSP was "discardable". 315 Code temperror 317 Existing/New Code existing 319 Defined In [AUTHRES] 321 Auth Method dkim-atps 323 Meaning An ATPS evaluation could not be completed due to some error 324 that is likely transient in nature, such as a temporary DNS error. 325 A later attempt may produce a final result. 327 Code permerror 329 Existing/New Code existing 331 Defined In [AUTHRES] 333 Auth Method dkim-atps 335 Meaning An ATPS evaluation could not be completed due to some error 336 that is not likely transient in nature, such as a permanent DNS 337 error. A later attempt is unlikely to produce a final result. 339 5.3. ADSP Specification Tag Registry 341 The following should be added to the ADSP Specification Tag Registry 342 established by [ADSP] as per [IANA-CONSIDERATIONS]: 344 +------+-------------+ 345 | TYPE | REFERENCE | 346 +------+-------------+ 347 | atps | [THIS MEMO] | 348 +------+-------------+ 350 6. Security Considerations 352 This section discusses potential security issues related to this 353 experimental protocol. 355 6.1. Transient Security Failures 357 Approving a third party signer exposes the Sender to the risk that 358 the third party signer becomes compromised and then begins to sign 359 malicious or nuisance messages on behalf of the Sender. This can 360 obviously reflect negatively on the Sender, and the impact of this 361 can become more severe as automated domain reputation systems are 362 developed and deployed. Thorough vetting and monitoring practices by 363 Senders of third party signers will likely need to become the norm. 365 6.2. Load on the DNS 367 A Verifier participating in DKIM, ADSP and ATPS will now issue a 368 number of TXT queries to the DNS equal to one (for the ADSP query) 369 plus twice the number of valid signatures on the message (one for 370 each key, one for an ATPS record) plus the number of invalid 371 signatures on the message (one for each key). This is in addition to 372 any PTR and A queries the MTA may issue at the time the actual 373 message relaying or delivery is initiated. Obviously this can be 374 burdensome on the DNS at both ends, and waiting for that number of 375 queries to return when they are issued in parallel could trigger 376 timeouts in the MTA. 378 An alternative to this that has not yet been explored is the storage 379 of the ATPS data at a specific URL tied to the Sender's domain name. 380 This would alleviate pressure on the DNS at the expense of requiring 381 the Sender to operate a web server (which has its own security 382 implications) and the addition of the establishment of a TCP 383 connection. Moreover, the Verifier would be well advised to 384 implement caching of this data to prevent ATPS from being used as a 385 denial-of-service vector. 387 7. References 389 7.1. Normative References 391 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 392 Syntax Specifications: ABNF", STD 68, 393 RFC 5234, January 2008. 395 [AUTHRES] Kucherawy, M., "Message Header Field for 396 Indicating Message Authentication Status", 397 RFC 5451, April 2009. 399 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 400 Data Encodings", RFC 4648, October 2006. 402 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, 403 M., Fenton, J., and M. Thomas, "DomainKeys 404 Identified Mail (DKIM) Signatures", RFC 4871, 405 May 2007. 407 [DNS] Mockapetris, P., "Domain names - 408 implementation and specification", STD 13, 409 RFC 1035, November 1987. 411 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 412 Indicate Requirement Levels", BCP 14, 413 RFC 2119, March 1997. 415 [SHA1] U.S. Department of Commerce, "Secure Hash 416 Standard", FIPS PUB 180-2, August 2002. 418 7.2. Informative References 420 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 421 Levine, "DomainKeys Identified Mail (DKIM) 422 Author Domain Signing Practices (ADSP)", 423 RFC 5617, August 2009. 425 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 426 RFC 5598, October 2008. 428 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 429 Writing an IANA Considerations Section in 430 RFCs", BCP 26, RFC 5226, May 2008. 432 [MAIL] Resnick, P., Ed., "Internet Message Format", 433 RFC 5322, October 2008. 435 Appendix A. Example Query and Reply 437 This section presents an example of the use of this protocol to query 438 for a third-party authorization and discusses the interpretation of 439 the result. 441 Presume a message for which the RFC5322.From domain is "example.com", 442 and it bears two valid signatures, one from "one.example.net" and one 443 from "two.example.net". The following actions are taken: 445 1. A TXT query is made, per [ADSP], to 446 "_adsp._domainkey.example.com" to query for its Author Domain 447 Signing Practices. If no valid reply is returned or the reply 448 does not contain an "atps" tag with value "y", the algorithm 449 stops with [AUTHRES] result "none". 451 2. A SHA1 hash of "one.example.net" is computed and then converted 452 to printable form using base32 encoding, resulting in the string 453 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 455 3. A TXT query is issued to 456 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 458 4. If a reply arrives, the algorithm stops with [AUTHRES] result 459 "pass". If a DNS error code other than NXDOMAIN is returned, the 460 algorithm stops with a result of "temperror" or "permerror" as 461 appropriate. 463 5. A SHA1 hash of "two.example.net" is computed and then converted 464 to printable form using base32 encoding, resulting in the string 465 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 467 6. A TXT query is issued to 468 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 470 7. If a reply arrives, the algorithm stops with [AUTHRES] result 471 "pass". If a DNS error code other than NXDOMAIN is returned, the 472 algorithm stops with a result of "temperror" or "permerror" as 473 appropriate. 475 8. As there are no valid signatures left to test, the algorithm 476 stops with a result of "unknown", "fail" or "discard" as per the 477 value on the ADSP "dkim" tag. 479 Appendix B. Acknowledgements 481 The author wishes to acknowledge the following for their review and 482 constructive criticism of this proposal: (names) 484 The author also wishes to acknowledge Doug Otis and Daniel Black for 485 their original draft upon which this work was based. 487 Author's Address 489 Murray S. Kucherawy 490 Cloudmark, Inc. 491 128 King St., 2nd Floor 492 San Francisco, CA 94107 493 US 495 Phone: +1 415 946 3800 496 EMail: msk@cloudmark.com