idnits 2.17.1 draft-housley-mass-sec-review-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 276. -- Found old boilerplate from RFC 3978, Section 5.5 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 298. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 7041 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet Draft Vigil Security 4 January 2005 5 Expires in six months 7 Security Review of Two MASS Proposals 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 A small group conducted a speedy security review of two MASS 37 proposals: DomainKeys and Identified Internet Mail (IIM). This short 38 document provides the findings. 40 1. Introduction 42 The MASS effort began with many proposed solutions at the first MASS 43 BoF held at IETF 60. Discussions on the mail list have trimmed the 44 number of proposals considerably. The leading contenders are now 45 DomainKeys [Delany] and Identified Internet Mail (IIM) [Fenton]. 47 A small group was gathered by the Security Area Director to conduct a 48 speedy security review of DomainKeys and Identified Internet Mail 49 (IIM). The group included (in alphabetical order): 51 Steve Bellovin (Columbia University) 52 Matt Fanto (NIST) 53 Sam Hartman (MIT) 54 Russ Housley (Vigil Security) 55 Blake Ramsdell (Sendmail) 56 Neil Rerup (EDS) 57 Jim Schaad (Soaring Hawk) 58 Sam Weiler (SPARTA) 60 2. Security Review 62 The DomainKeys and IIM specifications are both in good shape. They 63 represent a lot of work. This review could not have been conducted 64 without well written specifications as an input. While the syntax 65 and semantics could use some futher clarification, the basic intent 66 is clear. 68 The MASS effort, if it goes forward in the IETF, will specify 69 mechanisms to support the automated reduction of Phishing attacks and 70 Spam. The idea is that the email message can be automatically 71 filtered if the advertised source of the message is not associated 72 with the domain that signed the message. 74 2.1. Spamming Phishing, Authentication, and Privacy 76 Steve Bellovin published an article in the Communication of the ACM 77 [Bellovin] That takes the position that authentication is probably 78 not going to be a silver bullet that solves this problem. The review 79 team agrees; however, Phishing and Spam have reached epidemic 80 proportions, and they demand the attention of the IETF and other 81 Internet-related groups. Further, authentication will provide A 82 valuable input to automated filtering, which could eventually aid all 83 email users. 85 2.2. S/MIME and OpenPGP 87 DomainKeys and IIM claim to be much simpler than S/MIME or OpenPGP. 88 The security review team agrees with this assessment. Since the 89 problem trying to be solved is somewhat simpler than previous 90 efforts, the problem domain is restricted and the solution is 91 simpler. However, we must be careful that requirements are not added 92 during the development process. If this happens, the final outcome 93 could be just as complex (or even more so) than S/MIME and OpenPGP. 95 2.3. Public Key Infrastructure 97 Neither DomainKeys nor IIM makes use of certificates. The goal is to 98 start with something simple; something that does not dependent on the 99 deployment of an infrastructure. The question is: what is simple 100 enough? The solution needs to be complex enough to support the 101 evolution to a supporting infrastructure; however, there are also 102 concerns with incrementally adding things. One must ensure that the 103 final architecture is not more complex than deploying an 104 infrastructure from the beginning. 106 The solution space is discontinuous. Both DomainKeys and IIM seem To 107 have decided that existing certificate-based technologies are too 108 complicated. That is, Certification Authorities (CAs) and 109 certificate revocation are not required by either proposal. They 110 only include a placeholder for the future use of X.509 certificates. 112 This decision may be reasonable. If a mechanism to deal with 113 revocation Is added to the architecture several years after 114 deployment, then the Internet community can probably live with some 115 duplication of effort. However, if two weeks before the MASS RFC is 116 published, the Internet community decides that a revocation mechanism 117 is needed, then everyone will be wondering why RFC 3280 and the other 118 outputs of the PKIX working group were not employed. Such a 119 transition will be very difficult. 121 Overall complexity must be considered. Enhanced deployment may be a 122 reasonable justification for incrementally developing technology. 123 Minimizing specification time at the cost of deployment complexity is 124 not such a justification. 126 Since a transition to X.509 certificates is considered, RFC 2538 127 should at least be considered. 129 3. Cryptography 131 Nieither DomainKeys nor IIM does a good job specifying the 132 Cryptographic algorithms. Both require RSA (probably the PKCS#1 133 version 1.5 variant) and SHA-1. This is a fine choice, but the 134 specification needs to handle other algorithms too. It is not clear 135 how one would migrate to ECDSA with SHA-256, for example. 137 The key sizes specified for use with this system are different than 138 those specified in other IETF applications. No justification is 139 provided. RSA with a key size smaller than 1024 bits clearly needs 140 justification. Migration to an RSA key size of 2048 bits should be 141 expected. 143 No mechanism to facilitate the transition from one signature 144 algorithm to another is included. One approach might be the support 145 for multiple signatures to appear in a message. 147 4. Potential Security Concerns 149 4.1. Replay Attacks 151 One of the MASS goals is to prevent ISPs from having from their 152 addresses forged by spammers. This service would support the 153 construction of a reputation system. Neither DomainKeys nor IIM 154 prevent source address masquerade. It is fairly easy to send Spam 155 with a valid isp.example.com signature by simply getting an account 156 from that ISP and use it to send a Spam message to another account 157 served by another ISP. The received message contains a valid 158 signature for the Spam message. The message can be duplicated and 159 resent to any recipients, and the ISPs signature will be valid. 161 According to the IIM authors, they discuss this attack and some 162 solutions. The solutions all had undesirable properties. 164 In security terms, this is a replay attack. Without replay 165 protection DomainKeys and IIM fail to provide the authentication that 166 being advertised. 168 4.2. Denial of Service Attacks 170 Much more attention needs to be given to denial of service issues. 171 Note that a large number of bogus messages can overload the CPU of a 172 verifier. We have already seen CPU attacks by spammers against anti- 173 spam systems. 175 5. Security Differences 177 5.1. Key Registration Server 179 IIM includes the Key Registration Server (KRS). This provides 180 significant flexibility, without requiring every domain name to 181 deploy a server. This separate server has many properties in common 182 with an OCSP server used in some PKI deployments. 184 It is not as easy to distribute KRS servers as is claimed; they are 185 not serving up simple static pages. 187 The granularity of control offered by the KRS is desirable. However, 188 the complexity raises questions. If this complexity is necessary, 189 what complexity associated with a PKI is really being avoided? 191 The DomainKeys proposal depends entirely on DNS. Of course, the DNS 192 has well known security issues. DNS responses are essentially 193 unauthenticated. Some day, DNSsec will be deployed, but we should 194 not depend on that security solution for the MASS effort. Note that 195 this threat also needs to be discussed in the Security Considerations 196 section. At a minimum, mention DNSsec and point to RFC 3833. 198 The type of DNS attacks that would allow arbitrary public key 199 substitution are claimed to be " uneconomical." This assertion is 200 completely unsupported. The spammers have shown great willingness to 201 engage in many different forms of attack against anti-spam services. 203 KRS involves a reference from the DNS to the KRS server, which is 204 accessed with HTTP. One can either accept a lack of security or 205 provided by DNS as seems to be suggested, or TLS can be used to 206 protect HTTP. However, the use of TLS involve the use of PKI to 207 authenticate the KRS server. This leads to a very big question: 208 which trust anchors are appropriate for use in this application? The 209 answer involves infrastructure deployment. 211 5.2. DomainKeys Signature 213 Crucial semantics are specified in the DomainKey-Signature: line, but 214 it is not covered by the signature. Can an attacker change the one- 215 way hash function (h= portion of the header line)? 217 The document should require the signature algorithm (the default is 218 a=rsa-sha1) to be present in the header line. 220 6. Open Email Issues 222 The DomainKeys and IIM documents employ the same canonicalization 223 approaches. These need further review by the email community. The 224 digital signature processing of DomainKeys and IIM has many 225 similarities with digital signing XML. The canonicalization is very 226 simple, much simpler than MIME. The MIME documents explain mail- 227 mangling quite well, so justification for the simpler 228 canonicalization needed. 230 Several header lines need further investigation. For example, 231 "Resent-*" and the myriad ways that mailing lists mangle email. 232 Mailman, for example, can prepend text to a message as well as append 233 text to a message, but only the latter case is discussed. Also, many 234 mailing list systems modify the Subject: line, which will break 235 signature verification of any messages that covers the Subject: line. 236 Anti-virus and anti-spam packages also make changes to messages. 238 Another mail-related issue is the existence of 239 user+something@example.com Addresses. Are the wildcards proposed for 240 per-user keys sufficient for these addresses? Should the 241 canonicalization algorithm handle this in a special way? 243 7. Deployment Concerns 245 DomainKeys and IIM specify opt-in mechanisms. Therefore, when a a 246 specific domain goes on a black list, a Spammer can simply change 247 domains. If the solution does not achieve full deployment, it is not 248 clear that it will meet the stated objectives. 250 Deployment requires MUAs to be updated; however, updating to accept 251 S/MIME or OpenPGP mail is considered to be too difficult. Since 252 there is already a lot of software for S/MIME and OpenPGP, 253 justification is needed. 255 ISPs need to update all POP/IMAP mail servers to perform signature 256 verification; however, these same servers have not been updated to 257 remove constraints on 7-bit mail. What will make this different? 259 ISPs need to update all mail submission points to generate the 260 signature and authenticate the originator. Yet, many ISPs cannot or 261 will not deploy TLS to protect passwords. What will make this 262 different? 264 8. Security Considerations 266 This document provides a security review of DomainKeys and IIM. The 267 review team hopes that the information here will improve the output 268 of the MASS effort, if a working group is chartered to pursue this 269 work. 271 9. IPR Considerations 273 By submitting this Internet-Draft, I certify that any applicable 274 patent or other IPR claims of which I am aware have been disclosed, 275 or will be disclosed, and any of which I become aware will be 276 disclosed, in accordance with RFC 3668. 278 The IETF takes no position regarding the validity or scope of any 279 Intellectual Property Rights or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; nor does it represent that it has 283 made any independent effort to identify any such rights. Information 284 on the procedures with respect to rights in RFC documents can be 285 found in BCP 78 and BCP 79. 287 Copies of IPR disclosures made to the IETF Secretariat and any 288 assurances of licenses to be made available, or the result of an 289 attempt made to obtain a general license or permission for the use of 290 such proprietary rights by implementers or users of this 291 specification can be obtained from the IETF on-line IPR repository at 292 http://www.ietf.org/ipr. 294 The IETF invites any interested party to bring to its attention any 295 copyrights, patents or patent applications, or other proprietary 296 rights that may cover technology that may be required to implement 297 this standard. Please address the information to the IETF at ietf- 298 ipr@ietf.org. 300 10. Informative References 302 [Bellovin] S. Bellovin. "Spamming, Phishing, Authentication, and 303 Privacy", Communication of the ACM, 47(12):144, 2004. 305 [Delany] M. Delany. Domain-based Email Authentication Using 306 Public-Keys Advertised in the DNS (DomainKeys). August 307 2004. , work in progress. 309 [Fenton] J. Fenton and M. Thomas. Identified Internet Mail. 310 October 2004. , work in 311 progress. 313 11. Authors' Address 315 Russell Housley 316 Vigil Security, LLC 317 918 Spring Knoll Drive 318 Herndon, VA 20170 319 Phone: +1 703-435-1775 320 Email: housley@vigilsec.com 322 12. Full Copyright Statement 324 Copyright (C) The Internet Society (2005). This document is subject 325 to the rights, licenses and restrictions contained in BCP 78, and 326 except as set forth therein, the authors retain all their rights. 328 This document and translations of it may be copied and furnished to 329 others, and derivative works that comment on or otherwise explain it 330 or assist in its implementation may be prepared, copied, published 331 and distributed, in whole or in part, without restriction of any 332 kind, provided that the above copyright notice and this paragraph are 333 included on all such copies and derivative works. However, this 334 document itself may not be modified in any way, such as by removing 335 the copyright notice or references to the Internet Society or other 336 Internet organizations, except as needed for the purpose of 337 developing Internet standards in which case the procedures for 338 copyrights defined in the Internet Standards process must be 339 followed, or as required to translate it into languages other than 340 English. 342 This document and the information contained herein are provided on an 343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 345 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 346 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 347 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.