idnits 2.17.1 draft-ietf-dkim-implementation-report-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 -- The document date (October 4, 2010) is 4950 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational October 4, 2010 5 Expires: April 7, 2011 7 RFC4871 Implementation Report 8 draft-ietf-dkim-implementation-report-02 10 Abstract 12 This document contains an implementation report for the IESG covering 13 DomainKeys Identified Mail (DKIM) in support of the advancement of 14 that specification along the Standards Track. 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 April 7, 2011. 33 Copyright Notice 35 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. DKIM Interoperability Event . . . . . . . . . . . . . . . . . 5 53 3.1. Participants . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Testing Methodology . . . . . . . . . . . . . . . . . . . 5 55 3.3. Observations . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Collected DKIM Interoperability and Use Data . . . . . . . . . 8 58 4.1. The OpenDKIM Project . . . . . . . . . . . . . . . . . . . 8 59 4.1.1. Details . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 10 62 4.2. AOL, Inc. Data . . . . . . . . . . . . . . . . . . . . . . 11 63 4.3. Google Mail Data . . . . . . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 DomainKeys Identified Mail ([DKIM]), published in May 2007, has 75 reached a level of maturity sufficient to consider its advancement 76 along the standards track. Enclosed is a summary of collected 77 interoperability data provided from sources that are aggregating such 78 information as well as from a more formal DKIM interoperability event 79 that took place in October 2007. 81 2. Definitions 83 Various terms specific to email are used in this document. Their 84 definitions and further discussion can be found in [EMAIL-ARCH]. 86 3. DKIM Interoperability Event 88 In October 2007, Alt-N Technologies of Dallas, Texas hosted an 89 interoperability and testing event at their headquarters. Twenty 90 organizations sent engineers and their various DKIM implementations 91 to connect to a private internal network and exchange test messages 92 and tabulate observed results. 94 3.1. Participants 96 The interoperability event included participants from all of the 97 following organizations: Alt-N Technologies, AOL Inc., AT&T 98 Laboratories, Bizanga Ltd., Brandenburg InternetWorking, Brandmail 99 Solutions, ColdSpark, Constant Contact, Inc., DKIMproxy, Domain 100 Assurance Council, Google Inc., ICONIX Inc., Internet Initiative 101 Japan (IIJ), Ironport Systems, Message Systems, Port25 Solutions, 102 Postfix, Sendmail, Inc., StrongMail Systems, and Yahoo! Inc. Most of 103 the participants traveled to Dallas and participated in person, but a 104 few operated remotely. 106 Nearly all of the implementations were based on disjoint code 107 development projects. A few were based on a common open source base 108 project. 110 3.2. Testing Methodology 112 Participants were encouraged before the event to craft a set of test 113 messages meant to exercise their own implementations as well as those 114 of the other participants, both in terms of successful verifications 115 as well as some expected to fail. Some test cases were developed 116 with the intent of confounding verifiers that may not have 117 implemented the [ABNF] of [DKIM] correctly. 119 The participants set up Mail Transfer Agents (MTAs) equipped with 120 their own DKIM signing and verifying modules, and their own tools to 121 generate mail to be signed along with tools to analyze the results 122 post-verification. They then sent their own batteries of test 123 messages, looking for both expected and unexpected failures in 124 response. Some implementations included "auto-responders" that would 125 reply with verification results, while others simply collected the 126 results that would then be shared manually. 128 3.3. Observations 130 All of the packages implemented all of the required portions of 131 [DKIM] in terms of both signature and key features. Most of the 132 packages implemented all of the optional features of both signatures 133 and keys. There were at least two implementations of each optional 134 feature. 136 The interoperability testing was largely successful. As might be 137 expected, there were many verification false negatives or false 138 positives that were the result of bugs in corner cases of some of the 139 implementations presented for testing. In such cases the developers 140 were able to identify the issue as resulting from their own mis- 141 reading of the specification and not an error in the specification 142 itself. 144 Several of the failures did occur as a result of specification 145 ambiguities. The participants discussed each of these in turn and 146 were able to come to consensus on how they believed the specification 147 should be changed to resolve them. 149 3.4. Results 151 The handful of interoperability issues described above that referred 152 to weaknesses or ambiguities in [DKIM] resulted in several errata 153 being opened via the RFC Editor web site. These are being addressed 154 in an RFC4871bis draft effort that is now starting from within the 155 DKIM working group. 157 The errata items, in summary: 159 o explicit canonicalized forms of empty bodies for each 160 canonicalization method, along with their SHA1 and SHA256 hash 161 values (errata #1376 and #1377) 163 o clarification about normative text regarding the "a=" tag (errata 164 #1378) 166 o ABNF corrections regarding the "z=" tag (errata #1379) 168 o informative discussion regarding the "x=" tag (errata #1380) 170 o normative clarifications about "q=", "h=", "k=", "s=" and "t=" 171 tags (errata #1381 and #1382) 173 o correction of "g=" description to match its ABNF (errata #1383) 175 o clarifications about "relaxed" body canonicalization (errata 176 #1384) 178 o correction to the signature example (errata #1386) 180 o ABNF corrections regarding the "h=" tag (errata #1461) 181 o ABNF corrections regarding the "v=" tag (errata #1487) 183 o discussion of DomainKeys compatibility (errata #1532) 185 o discussion about what constitutes the actual value of the "b=" tag 186 (errata #1596) 188 4. Collected DKIM Interoperability and Use Data 190 Several implementations are collecting private data about DKIM use, 191 signature survivability, which properties of the base specification 192 are observed in public use, etc. This section includes collection 193 methods and summary reports provided by those implementations. 195 4.1. The OpenDKIM Project 197 The OpenDKIM Project (http://www.opendkim.org) is an open source 198 project providing a DKIM support library, an email filter for use 199 with Mail Transfer Agents (MTAs), and a set of tools to assist with 200 deployment of DKIM. 202 4.1.1. Details 204 Recent releases have included an optional feature to record 205 statistics about messages with and without DKIM signatures. Sites 206 enabling this feature can choose to share the data with the project's 207 development team as part of this interoperability report work. The 208 data can be anonymized to conceal the sending domain and client IP 209 addresses, though these data are passed through a one-way hash to 210 enable collation of data from common sources. 212 4.1.2. Results 214 At the time of writing of this document, five weeks of data had been 215 collected. The results of this effort are as follows: 217 Reporting Hosts: six individual MTAs representing four distinct 218 ADMDs 220 Total Messages: 538702 222 Signatures: 394786 messages (73.3%) were not signed; 140535 (26.1%) 223 had one signature; 3354 (0.6%) had two signatures; the remainder 224 (less than 0.01%) had more. 226 Signing Algorithms: 49% of signatures used "rsa-sha1", while the 227 balance used "rsa-sha256". 229 Header Canonicalization Algorithms: 13.8% of signatures used 230 "simple", while the balance used "relaxed"; when grouped by 231 domains, the percentages were similar. 233 Body Canonicalization Algorithms: 25.6% of signatures used "simple", 234 while the balance used "relaxed"; when grouped by domains, the 235 percentages were similar. 237 Keys in Test Mode: 56.1% of keys retrieved from the DNS were tagged 238 as being in test mode. 240 Keys with Specific Granularity: Four keys were retrieved that had 241 specific names in their "g=" tags. 243 Keys with Syntax Errors: Less than 0.1% of keys retrieved from the 244 DNS had syntax errors. 246 DomainKeys Compatibility: 1.4% of the retrieved keys appeared to be 247 intended for use with the older DomainKeys proposal rather than 248 DKIM 250 Missing Keys: 2% of signatures received referenced keys that were 251 not found in the DNS 253 Optional Signature Tags: Of the optional signature tags supported by 254 the base specification, "t=" was seen 46.7% of the time (1% of 255 which included timestamps in the future, even after forgiving some 256 clock drift); "x=" was seen 4.4% of the time; "l=" was seen 4.6% 257 of the time; "z=" was seen 4.8% of the time. 259 Body Length Limits: Of the signatures for which "l=" was used, 6.4% 260 of them signed none of the body, and 100% of the rest had the body 261 extended after signing. 263 Signature Pass Rates: Overall, 89.9% of observed signatures were 264 successfully verified. 266 Pass Rates for Non-List Mail: Where "list mail" is defined as any 267 mail not bearing one of the header fields defined in [LIST-ID] or 268 in [LIST-URLS], or a "Precedence: list" field, selecting only for 269 mail that is not list mail revealed a successful verification rate 270 of 93.6%; selecting only for list mail produced a 84.7% success 271 rate. 273 DNSSEC: Only one reporting site is currently checking for DNSSEC on 274 keys retrieved from the DNS. It found no signed keys. 276 Common errors: The top five verification errors observed: Key not 277 found in DNS (20.3%), key granularity mismatch (14.2%), DNS 278 retrieval failure such as timeouts (1.8%), key revoked (1.7%), 279 unknown key type (1.6%). 281 Detected Header Field Changes: A subset of the reporting sites are 282 capable of reporting header fields known to have been changed in 283 transit (e.g. when "z=" tags were used by the signer). In such 284 cases, changes to the "To:" field were more common than any other 285 by a factor of two or more. 287 Most Commonly Signed Fields: From: (100%), To: (95.5%), Subject: 288 (93.7%), Date: (92.3%), MIME-Version: (88.8%), Content-Type: 289 (80%), Message-Id: (75.9%), Received: (59.7%). All others are 290 below 50%. 292 Identities: 73.8% of the signatures observed included a "d=" value 293 matching the domain in the From: field. 295 Multiple-use Signing Domains: 10516 unique signing domains were 296 observed. Of these, 41.4% of them sent a single signed message in 297 the sample period, 18.3% sent two and 8.7% sent three. 299 4.1.3. Conclusions 301 The results of the OpenDKIM work are updated constantly as more data 302 feeds come online and more data are reported. Based on the data 303 available at the time of writing, some conclusions are possible. 305 At least some implementations of all of the optional signature 306 features, all of the canonicalization combinations and all of the 307 signing algorithms are in general use. None of the features had zero 308 use counts. 310 Overall signature pass rates are generally quite high. The impact of 311 signature survivability when correlated against Mailing List Manager 312 (MLM) activity is surprisingly low based on observed data. More 313 research into this is recommended. The DKIM Working Group is already 314 working on an Informational draft to discuss those issues. 316 That the "To" field is the one most often associated with 317 verification failures suggests some MTAs handling the message are 318 correcting cases where the field is improperly formed. A common case 319 is failing to quote the comment portion of that field when required 320 to do so by [MAIL]. Such corrections cause signatures to become 321 invalid. 323 The counts of low-use signing domains suggest that spammers, who 324 typically rotate domain names with high frequency, have adopted DKIM 325 as a tool to try to get through message filters. 327 4.2. AOL, Inc. Data 329 A one-day summary of observed traffic from AOL, Inc. reports the 330 following: 332 Ratio of DKIM-signed mail: 42% 334 Properly formed signatures: 1.4 billion 336 Malformed signatures: 3000 338 Unique signing domains: 50,000-90,000 340 Key retrieval errors: 14 million (1%) 342 Signature refers to nonexistent domain: 10 million (0.7%) 344 Signature refers to nonexistent key: 36 million (2.5%) 346 Signature refers to revoked key: 138,000 (~0% ) 348 Verified signatures: 1.2 billion (85.7%) 350 Failed signatures (body changed): 78 million (5.6%) 352 Failed signatures (other): 34 million (2.4%) 354 Expired signatures: less than 1 million (~0%) 356 4.3. Google Mail Data 358 Google Mail reports the following: 360 Unsigned mail: 72.1% 362 Signed mail that verified: 14.7% 364 Signed mail that verified in test mode: 11.7% 366 Signed mail that failed: 0.2% 368 Signed mail that failed in test mode: 0.2% 370 Body hash mismatch: 0.5% 371 Signature missing required parameters: 0.3% 373 Granularity mismatch: 0.2% 375 All other reportable anomalies occurred in vanishingly small 376 percentages. 378 5. IANA Considerations 380 This memo contains no actions for IANA. 382 6. Security Considerations 384 This document is an implementation report and thus has no security 385 considerations. 387 7. References 389 7.1. Normative References 391 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 392 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 393 Signatures", RFC 4871, May 2007. 395 [EMAIL-ARCH] 396 Crocker, D., "Internet Mail Architecture", RFC 5598, 397 July 2009. 399 7.2. Informative References 401 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 402 Specifications: ABNF", RFC 5234, January 2008. 404 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 405 and Namespace for the Identification of Mailing Lists", 406 RFC 2919, March 2001. 408 [LIST-URLS] 409 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 410 for Core Mail List Commands and their Transport through 411 Message Header Fields", RFC 2369, July 1998. 413 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 414 October 2008. 416 Appendix A. Acknowledgements 418 The author wishes to acknowledge the following for their review and 419 constructive criticism of this document: Dave Crocker, Tony Hansen, 420 Jeff Macdonald, S. Moonesamy and Rolf Sonneveld. 422 The author also wishes to acknowledge Margot Koschier of AOL, Inc., 423 Monica Chew of Google, and the members of The OpenDKIM Project for 424 providing data used in this report. 426 The working group expresses its profound thanks to Alt-N Technologies 427 for graciously hosting the 2007 DKIM interoperability event. 429 Author's Address 431 Murray S. Kucherawy 432 Cloudmark 433 128 King St., 2nd Floor 434 San Francisco, CA 94107 435 US 437 Phone: +1 415 946 3800 438 Email: msk@cloudmark.com