idnits 2.17.1 draft-kucherawy-authres-header-b-04.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 (June 17, 2010) is 5054 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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 (~~), 1 warning (==), 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: Standards Track June 17, 2010 5 Expires: December 19, 2010 7 Authentication-Results Registration For Differentiating Among 8 Cryptographic Results 9 draft-kucherawy-authres-header-b-04 11 Abstract 13 This memo updates the registry of properties in Authentication- 14 Results: message header fields to allow a multiple-result report to 15 distinguish among one or more cryptographic signatures on a message, 16 thus associating specific results with the signatures they represent. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 19, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 5 60 6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Authentication-Results Examples . . . . . . . . . . . 6 65 A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 7 66 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 [AUTHRES] defined a new header field for electronic mail messages 71 that presents the results of a message authentication effort in a 72 machine-readable format. Absent from that specification was the 73 means by which the results of two cryptographic signatures, such as 74 those provided by [DKIM], can both have results reported in an 75 unambiguous manner. 77 Fortunately, [AUTHRES] created IANA registries of reporting 78 properties, enabling an easy remedy for this problem. This memo thus 79 registers an additional reporting property allowing a result to be 80 associated with a specific digital signature. 82 2. Keywords 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [KEYWORDS]. 88 3. Discussion 90 A message can contain multiple signatures of a common sender 91 authentication mechanism, such as [DKIM]. For example, a DKIM signer 92 could apply signatures using two or more different message 93 canonicalization algorithms to determine the resistance of each to 94 being broken in transit. 96 By applying supported "ptype.property" combinations (cf. the ABNF in 97 [AUTHRES]), a result can be associated with a given signature 98 provided the signatures are all unique within one of the registered 99 values (e.g. all of them had unique "header.d" or "header.i" values). 100 This is not guaranteed, however; a single signing agent might have 101 practical reasons for affixing multiple signatures with the same "d=" 102 values while varying other signature parameters. This means one 103 could get a "dkim=pass" and "dkim=fail" result simultaneously on 104 verification which is clearly ambiguous. 106 It is thus necessary either to create or to identify a signature 107 attribute guaranteed to be unique, such that it is possible to 108 unambiguously associate a result with the signature to which it 109 refers. 111 Collisions during general use of SHA1 and SHA256 are uncommon (see 112 [HASH-ATTACKS]) and RSA key signing mechanisms are resilient to 113 producing common substrings. Thus, the actual digital signature for 114 a cryptographic signing of the message is an ideal property for such 115 a unique identification. It is not however necessary to include the 116 entire digital signature in an [AUTHRES] header field just to 117 identify which result goes with signature; since the signatures will 118 almost always be substantially different, it is anticipated that only 119 the first several bytes of a signature will be needed for 120 disambiguating results. 122 4. Definition 124 This memo adds to the "Email Authentication Method Name Registry", 125 created by IANA upon publication of [AUTHRES], the "header.b" 126 reporting item. The value associated with this item in the header 127 field MUST be at least the first eight characters of the digital 128 signature (the "b=" tag from a DKIM-Signature) for which a result is 129 being relayed, and MUST be long enough to be unique among the results 130 being reported. Where the total length of the digital signature is 131 fewer than eight characters, the entire signature MUST be included. 132 Matching of the value of this item against the signature itself MUST 133 be case-sensitive. 135 If an evaluating agent observes that, despite the use of this 136 disambiguating tag, unequal authentication results are offered about 137 the same signature from the same trusted authserv-id, that agent 138 SHOULD ignore all such results. 140 5. IANA Considerations 142 Per [IANA-CONSIDERATIONS], the following item is added to the "Email 143 Authentication Method Name Registry": 145 +------------+----------+--------+----------------+-----------------+ 146 | Method | Defined | ptype | property | value | 147 +------------+----------+--------+----------------+-----------------+ 148 | dkim | RFC4871 | header | b | full or partial | 149 | | | | | value of | 150 | | | | | signature "b" | 151 | | | | | tag | 152 +------------+----------+--------+----------------+-----------------+ 154 6. Security Considerations 156 [AUTHRES] discussed general security considerations regarding the use 157 of this header field. The following new security considerations 158 apply when adding or processing this new ptype/property combination: 160 6.1. Improvement 162 Rather than introducing a new security issue, this can be seen to fix 163 a security weakness of the original specification: Useful information 164 can now be obtained from results that could previously have been 165 ambiguous and thus obscured or, worse, misinterpreted. 167 6.2. Result Forgeries 169 An attacker could copy a valid signature and add it to a message in 170 transit, modifying some portion of it. This could cause two results 171 to be provided for the same "header.b" value even if the entire "b=" 172 string is used in an attempt to differentiate the results. This 173 attack could cause an ambiguous result to be relayed and possibly 174 neutralize any benefit given to a "pass" result that would have 175 otherwise occurred, possibly impacting the delivery of valid 176 messages. 178 It is worth noting, however, that a false negative ("fail") can be 179 generated in this way, but it is extremely difficult to create a 180 false positive ("pass") through such an attack. Thus, a cautious 181 implementation could discard the false negative in that instance. 183 6.3. New Schemes with Small Signatures 185 Should a new signing scheme be introduced with a signature whose 186 length is less than eight characters, Section 4 specifies that the 187 entire signature must be used. The obvious concern in such a case 188 would be that the signature scheme is itself prone to collisions, 189 making the the value reported by this field not useful. In such 190 cases, the risk is created by the likelihood of collisions and not by 191 this mechanism; furthermore, Section 4 recommends the results be 192 ignored if that were to occur, preventing the application of an 193 ambiguous result. 195 7. References 197 7.1. Normative References 199 [AUTHRES] Kucherawy, M., "Message Header Field for 200 Indicating Message Authentication Status", 201 RFC 5451, April 2009. 203 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, 204 M., Fenton, J., and M. Thomas, "DomainKeys 205 Identified Mail (DKIM) Signatures", RFC 4871, 206 May 2007. 208 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 209 Indicate Requirement Levels", BCP 14, 210 RFC 2119, March 1997. 212 7.2. Informative References 214 [HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on 215 Cryptographic Hashes in Internet Protocols", 216 RFC 4270, November 2005. 218 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 219 Writing an IANA Considerations Section in 220 RFCs", BCP 26, RFC 5226, May 2008. 222 Appendix A. Authentication-Results Examples 224 This section presents an example of the use of this new item header 225 field to indicate unambiguous authentication results. 227 A.1. Multiple DKIM Signatures with One Failure 229 A message that had two DKIM signatures applied by the same domain, 230 one of which failed: 232 Authentication-Results: mail-router.example.net; 233 dkim=pass (good signature) header.d=newyork.example.com 234 header.b=oINEO8hg; 235 dkim=fail (bad signature) header.d=newyork.example.com 236 header.b=EToRSuvU 237 Received: from newyork.example.com 238 (newyork.example.com [192.0.2.250]) 239 by mail-router.example.net (8.11.6/8.11.6) 240 for 241 with ESMTP id i7PK0sH7021929; 242 Fri, Feb 15 2002 17:19:22 -0800 243 DKIM-Signature: v=1; a=rsa-sha256; s=rashani; 244 d=newyork.example.com; 245 t=1188964191; c=relaxed/simple; 246 h=From:Date:To:Message-Id:Subject; 247 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 248 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 249 DKIM-Signature: v=1; a=rsa-sha256; s=rashani; 250 d=newyork.example.com; 251 t=1188964191; c=simple/simple; 252 h=From:Date:To:Message-Id:Subject; 253 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 254 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 255 From: sender@newyork.example.com 256 Date: Fri, Feb 15 2002 16:54:30 -0800 257 To: meetings@example.net 258 Message-Id: <12345.abc@newyork.example.com> 259 Subject: here's a sample 261 Example 1: Header field reporting results from multiple signatures 262 added at initial signing 264 Here we see an example of a message that was signed twice at by the 265 author's ADMD. One signature used "relaxed" header canonicalization 266 and the other used "simple" header canonicalization; both used 267 "simple" body canonicalization. 269 Presumably due to a change in one of the five header fields covered 270 by the two signatures, the former signature failed to verify while 271 the latter passed. In particular, the "relaxed" header 272 canonicalization of [DKIM] is resilient to changes in whitespace in 273 the header while "simple" is not, and the latter is the one that 274 failed in this example. 276 The item registered by this memo allows an evaluation module to 277 determine which DKIM result goes with which signature. Without the 278 "header.b" portion of the result, it is unclear which one passed and 279 which one failed. 281 Appendix B. Acknowledgements 283 The author wishes to acknowledge the following for their review and 284 constructive criticism of this proposal: Dave Crocker, Tony Hansen, 285 Eliot Lear, S. Moonesamy, Alessandro Vesely. 287 Author's Address 289 Murray S. Kucherawy 290 Cloudmark, Inc. 291 128 King St., 2nd Floor 292 San Francisco, CA 94107 293 US 295 Phone: +1 415 946 3800 296 EMail: msk@cloudmark.com