idnits 2.17.00 (12 Aug 2021) /tmp/idnits54271/draft-ietf-dkim-implementation-report-06.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 (March 28, 2011) is 4065 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 March 28, 2011 5 Expires: September 29, 2011 7 RFC4871 Implementation Report 8 draft-ietf-dkim-implementation-report-06 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 September 29, 2011. 33 Copyright Notice 35 Copyright (c) 2011 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 reached 75 a level of maturity sufficient to consider its advancement along the 76 standards track. Enclosed is a summary of collected interoperability 77 data provided from sources that are aggregating such information as 78 well as from a more formal DKIM interoperability event that took 79 place in October 2007. 81 2. Definitions 83 DomainKeys Identified Mail is defined in [DKIM]. 85 Various terms specific to email are used in this document. Their 86 definitions and further discussion can be found in [EMAIL-ARCH]. 88 3. DKIM Interoperability Event 90 In October 2007, Alt-N Technologies of Dallas, Texas hosted an 91 interoperability and testing event at their headquarters. Twenty 92 organizations sent engineers and their various DKIM implementations 93 to connect to a private internal network and exchange test messages 94 and tabulate observed results. 96 3.1. Participants 98 The interoperability event included participants from all of the 99 following organizations: Alt-N Technologies, AOL Inc., AT&T 100 Laboratories, Bizanga Ltd., Brandenburg InternetWorking, Brandmail 101 Solutions, ColdSpark, Constant Contact, Inc., DKIMproxy, Domain 102 Assurance Council, Google Inc., ICONIX Inc., Internet Initiative 103 Japan (IIJ), Ironport Systems, Message Systems, Port25 Solutions, 104 Postfix, Sendmail, Inc., StrongMail Systems, and Yahoo! Inc. Most of 105 the participants traveled to Dallas and participated in person, but a 106 few operated remotely. 108 Nearly all of the implementations were based on disjoint code 109 development projects. A few were based on a common open source base 110 project. 112 3.2. Testing Methodology 114 Participants were encouraged before the event to craft a set of test 115 messages meant to exercise their own implementations as well as those 116 of the other participants, both in terms of successful verifications 117 as well as some expected to fail. Test cases were developed with the 118 intent of confounding verifiers that may not have implemented the 119 [ABNF] of [DKIM] correctly. 121 The participants set up Mail Transfer Agents (MTAs) equipped with 122 their own DKIM signing and verifying modules, and their own tools to 123 generate mail to be signed along with tools to analyze the results 124 post-verification. They then sent their own batteries of test 125 messages, looking for both expected and unexpected failures in 126 response. Some implementations included "auto-responders" that would 127 reply with verification results, while others simply collected the 128 results that would then be shared manually. 130 3.3. Observations 132 All of the packages implemented all of the required portions of 133 [DKIM] in terms of both signature and key features. Most of the 134 packages implemented all of the optional features of both signatures 135 and keys. There were at least two implementations of each optional 136 feature. 138 The interoperability testing was largely successful. As might be 139 expected, there were many verification false negatives or false 140 positives that were the result of bugs in corner cases of some of the 141 implementations presented for testing. In such cases the developers 142 were able to identify the issue as resulting from their own mis- 143 reading of the specification and not an error in the specification 144 itself. 146 Several of the failures did occur as a result of specification 147 ambiguities. The participants discussed each of these in turn and 148 were able to come to consensus on how they believed the specification 149 should be changed to resolve them. 151 The participants agreed to keep the results about the specific tests 152 private. Accordingly, those data are not presented here. 154 3.4. Results 156 The handful of interoperability issues described above that referred 157 to weaknesses or ambiguities in [DKIM] resulted in several errata 158 being opened via the RFC Editor web site. These are being addressed 159 in an RFC4871bis draft effort that is now starting from within the 160 DKIM working group. 162 The errata items, in summary: 164 o explicit canonicalized forms of empty bodies for each 165 canonicalization method, along with their SHA1 and SHA256 hash 166 values (errata #1376 and #1377) 168 o clarification about normative text regarding the "a=" tag (errata 169 #1378) 171 o ABNF corrections regarding the "z=" tag (errata #1379) 173 o informative discussion regarding the "x=" tag (errata #1380) 175 o normative clarifications about "q=", "h=", "k=", "s=" and "t=" 176 tags (errata #1381 and #1382) 178 o correction of "g=" description to match its ABNF (errata #1383) 180 o clarifications about "relaxed" body canonicalization (errata 181 #1384) 183 o correction to the signature example (errata #1386) 185 o ABNF corrections regarding the "h=" tag (errata #1461) 187 o ABNF corrections regarding the "v=" tag (errata #1487) 189 o discussion of DomainKeys compatibility (errata #1532) 191 o discussion about what constitutes the actual value of the "b=" tag 192 (errata #1596) 194 4. Collected DKIM Interoperability and Use Data 196 Several implementations are collecting private data about DKIM use, 197 signature survivability, which properties of the base specification 198 are observed in public use, etc. This section includes collection 199 methods and summary reports provided by those implementations. 201 4.1. The OpenDKIM Project 203 The OpenDKIM Project (http://www.opendkim.org) is an open source 204 project providing a DKIM support library, an email filter for use 205 with Mail Transfer Agents (MTAs), and a set of tools to assist with 206 deployment of DKIM. 208 4.1.1. Details 210 Recent releases have included an optional feature to record 211 statistics about messages with and without DKIM signatures. Sites 212 enabling this feature can choose to share the data with the project's 213 development team as part of this interoperability report work. The 214 data can be anonymized to conceal the sending domain and client IP 215 addresses, though these data are passed through a one-way hash to 216 enable collation of data from common sources. 218 4.1.2. Results 220 At the time of writing of this document, seven months of data had 221 been collected. The results of this effort are as follows: 223 Reporting Hosts: 21 individual MTAs representing nine distinct ADMDs 225 Total Messages: 11367042 227 Signatures: 8146244 messages (71.7%) were not signed; 3186313 228 (28.0%) had one signature; 34156 (0.3%) had two signatures; the 229 remainder (less than 0.01%) had more. 231 Signing Algorithms: 53.4% of signatures used "rsa-sha1", while the 232 balance used "rsa-sha256". 234 Header Canonicalization Algorithms: 14.8% of signatures used 235 "simple", while the balance used "relaxed"; when grouped by 236 domains, 11.8% of domains used "simple" while the balance used 237 "relaxed". 239 Body Canonicalization Algorithms: 26.2% of signatures used "simple", 240 while the balance used "relaxed"; 19.1% of observed signing 241 domains used "simple" while the balance used "relaxed". 243 Keys in Test Mode: 54.5% of keys retrieved from the DNS were tagged 244 as being in test mode. 246 Keys with Specific Granularity: 434 keys were retrieved that had 247 specific names in their "g=" tags. 249 Keys with Syntax Errors: Less than 0.1% of keys retrieved from the 250 DNS had syntax errors. 252 DomainKeys Compatibility: 1% of the retrieved keys appeared to be 253 intended for use with the older DomainKeys proposal rather than 254 DKIM 256 AUID use: 49.8% of signatures did not contain an explicit AUID ("i=" 257 value). Of those that did, 89.4% used a domain matching the SDID 258 ("d=" value). Across all "i=" tags present, 43.6% provided no 259 local-part, 52.8% included a local-part matching the one found in 260 the From: field, and the remainder had a different local-part. 262 Missing Keys: 2.1% of signatures received referenced keys that were 263 not found in the DNS 265 Optional Signature Tags: Of the optional signature tags supported by 266 the base specification, "t=" was seen 45.3% of the time, "x=" was 267 seen 3.4% of the time; "l=" was seen 3.7 of the time; "z=" was 268 seen 5.9% of the time. (The "z=" statistic is likely inflated due 269 to the nature of the sampling.) 271 Body Length Limits: Of the signatures for which "l=" was used, 11.9% 272 of them signed none of the body, and 92.5% of the rest had the 273 body extended after signing. 275 Signature Pass Rates: Overall, 92.3% of observed signatures were 276 successfully verified. 278 Pass Rates for Non-List Mail: Where "list mail" is defined as any 279 mail bearing one of the header fields defined in [LIST-ID] or in 280 [LIST-URLS], or a "Precedence: list" field, selecting only for 281 mail that is not list mail revealed a successful verification rate 282 of 93.5%; selecting only for list mail produced a 90.5% success 283 rate. 285 DNSSEC: There has been scant but detectable uptake in the checking 286 of whether or not DKIM or ADSP records in the DNS are protected by 287 DNSSEC. 289 Common errors: The top five verification errors observed: Key not 290 found in DNS (28.3%), key granularity mismatch (13.8%), DNS 291 retrieval failure such as timeouts (10.6%), key type unknown 292 (2.3%), key timestamp is in in the future (2.2%). 294 Detected Header Field Changes: A subset of the reporting sites are 295 capable of reporting header fields known to have been changed in 296 transit (e.g. when "z=" tags were used by the signer). In such 297 cases, changes to the "To:" field were more common than any other 298 by more than an order of magnitude. 300 Most Commonly Signed Fields: From: (100%), Subject: (95.8%), Date: 301 (95.6%), To: (95.4%), MIME-Version: (92.9%), Content-Type: 302 (85.0%), Message-Id: (75.6%), Reply-To: (43.8%), Received: 303 (35.2%), List-Unsubscribe: (31.3%). All others are below 30%. 305 Identities: 76% of the signatures observed included a "d=" value 306 matching the domain in the From: field. 308 Low-use Signing Domains: 50942 unique signing domains were observed. 309 Of these, 26% of them sent a single signed message in the sample 310 period, 14.4% sent two and 8.3% sent three. 312 4.1.3. Conclusions 314 The results of the OpenDKIM work are updated constantly as more data 315 feeds come online and more data are reported. Based on the data 316 available at the time of writing, some conclusions are possible. 318 At least some implementations of all of the optional signature 319 features, all of the canonicalization combinations and all of the 320 signing algorithms are in general use. None of the features had zero 321 use counts. 323 Overall signature pass rates are generally quite high. The impact of 324 signature survivability when correlated against Mailing List Manager 325 (MLM) activity is detectable based on observed data. More research 326 into this is recommended. The DKIM Working Group is already working 327 on an Informational draft to discuss those issues. 329 That the "To" field is the one most often associated with 330 verification failures suggests some MTAs handling the message are 331 correcting cases where the field is improperly formed. A common case 332 is failing to quote the comment portion of that field when required 333 to do so by [MAIL]. Such corrections cause signatures to become 334 invalid. The working group may want to consider revising Section 5.5 335 of [DKIM] to either reduce the list of recommended header fields for 336 signature content or provide some additional text warning of this 337 potential issue. 339 The high counts (i.e., nearly half) of low-use signing domains 340 suggest that spammers, who typically rotate domain names with high 341 frequency, have adopted DKIM as a tool to try to get through message 342 filters. 344 4.2. AOL, Inc. Data 346 A one-day summary of observed traffic from AOL, Inc. reports the 347 following: 349 Ratio of DKIM-signed mail: 42% 351 Properly formed signatures: 1.4 billion 353 Malformed signatures: 3000 355 Unique signing domains: 50,000-90,000 357 Key retrieval errors: 14 million (1%) 359 Signature refers to nonexistent domain: 10 million (0.7%) 361 Signature refers to nonexistent key: 36 million (2.5%) 363 Signature refers to revoked key: 138,000 (~0% ) 365 Verified signatures: 1.2 billion (85.7%) 367 AUID matches From: domain: 1.2 billion (85.7%) 369 Failed signatures (body changed): 78 million (5.6%) 371 Failed signatures (other): 34 million (2.4%) 373 Expired signatures: less than 1 million (~0%) 375 4.3. Google Mail Data 377 Google Mail reports the following: 379 Unsigned mail: 72.1% 381 AUID matches From: domain: 68.7% 383 Signed mail that verified: 14.7% 385 Signed mail that verified in test mode: 11.7% 387 Signed mail that failed: 0.2% 389 Signed mail that failed in test mode: 0.2% 391 Body hash mismatch: 0.5% 393 Signature missing required parameters: 0.3% 395 Granularity mismatch: 0.2% 397 These data are reported based on an implementation that only 398 evaluates one signature per message. 400 All other reportable anomalies occurred in vanishingly small 401 percentages. 403 5. IANA Considerations 405 This memo contains no actions for IANA. 407 6. Security Considerations 409 This document is an implementation report and thus has no security 410 considerations. 412 7. References 414 7.1. Normative References 416 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 417 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 418 Signatures", RFC 4871, May 2007. 420 [EMAIL-ARCH] 421 Crocker, D., "Internet Mail Architecture", RFC 5598, 422 July 2009. 424 7.2. Informative References 426 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 427 Specifications: ABNF", RFC 5234, January 2008. 429 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 430 and Namespace for the Identification of Mailing Lists", 431 RFC 2919, March 2001. 433 [LIST-URLS] 434 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 435 for Core Mail List Commands and their Transport through 436 Message Header Fields", RFC 2369, July 1998. 438 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 439 October 2008. 441 Appendix A. Acknowledgements 443 The author wishes to acknowledge the following for their review and 444 constructive criticism of this document: Dave Crocker, Tony Hansen, 445 Jeff Macdonald, S. Moonesamy and Rolf Sonneveld. 447 The author also wishes to acknowledge Margot Koschier of AOL, Inc., 448 Monica Chew of Google, and the members of The OpenDKIM Project for 449 providing data used in this report. 451 The working group expresses its profound thanks to Alt-N Technologies 452 for graciously hosting the 2007 DKIM interoperability event. 454 Author's Address 456 Murray S. Kucherawy 457 Cloudmark 458 128 King St., 2nd Floor 459 San Francisco, CA 94107 460 US 462 Phone: +1 415 946 3800 463 Email: msk@cloudmark.com