idnits 2.17.1 draft-fenton-identified-mail-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 824. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 840), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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: ---------------------------------------------------------------------------- == 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.) ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... characters, but SHOULD be limited to ...' RFC 2119 keyword, line 146: '...g an unknown tag MUST silently discard...' RFC 2119 keyword, line 162: '... above MUST be interpreted as that c...' RFC 2119 keyword, line 163: '...esent. Encoders MUST translate all sp...' RFC 2119 keyword, line 164: '...ed form. Decoders MUST reject strings...' (39 more instances...) 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 (June 1, 2004) is 7268 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2822 (ref. '1') (Obsoleted by RFC 5322) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Fenton 2 Internet-Draft M. Thomas 3 Expires: November 30, 2004 Cisco Systems, Inc. 4 June 1, 2004 6 Identified Internet Mail 7 draft-fenton-identified-mail-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes extensions to the format of electronic mail 41 messages and a public-key infrastructure to permit verification of 42 the source of messages by either mail transport agents (MTAs) or mail 43 user agents (MUAs). This may be used to implement a policy which, 44 for example, favors the delivery of identified messages over messages 45 lacking signatures or having incorrect signatures. Mechanisms by 46 which signing of messages and verification of signatures can be 47 performed by a trusted MTA, in order to minimize impact on the user, 48 are also presented. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1 Identified Mail Tag Syntax . . . . . . . . . . . . . . . . 5 55 2.2 The Signature Header . . . . . . . . . . . . . . . . . . . 6 56 2.3 The Verification Header . . . . . . . . . . . . . . . . . 7 57 2.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 8 58 2.5 Use of From header . . . . . . . . . . . . . . . . . . . . 9 59 3. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.1 Key Registration . . . . . . . . . . . . . . . . . . . . . 10 61 3.2 Key Verification . . . . . . . . . . . . . . . . . . . . . 11 62 3.3 Address ratings . . . . . . . . . . . . . . . . . . . . . 13 63 4. Policy Options . . . . . . . . . . . . . . . . . . . . . . . . 15 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 5.1 Potential Attacks . . . . . . . . . . . . . . . . . . . . 17 66 5.1.1 Key Registration Server DoS Attack . . . . . . . . . . 17 67 5.1.2 Key Registration Server Stall Tactic . . . . . . . . . 17 68 5.1.3 Misappropriated private key . . . . . . . . . . . . . 18 69 5.1.4 Message Replay Attack . . . . . . . . . . . . . . . . 18 70 5.2 Other Considerations . . . . . . . . . . . . . . . . . . . 19 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 74 7.2 Informative References . . . . . . . . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 76 Intellectual Property and Copyright Statements . . . . . . . . 22 78 1. Introduction 80 Internet users have recently been subjected to a torrent of unwanted 81 email messages. These generally take two forms: 82 1. Messages originated by "spammers" to send advertising or 83 solicitation, or as part of a confidence scheme 84 2. Messages sent automatically by worms and other malware attempting 85 to infect additional systems 87 In both cases, a large proportion of the messages attempt to disguise 88 their true source, to frustrate attempts to shut down the spammer, to 89 disguise the identity of the infected system sending the message, or 90 to support a social-engineering goal. Since SMTP permits senders to 91 use any return address they wish, the addition of a signature to 92 messages limits the opportunity of spammers or malware to forge 93 return addresses, and thus provides some degree of accountability for 94 the source of email messages. 96 As currently used, message signatures such as those generated by PGP 97 cover only the body of a message. It is therefore possible for 98 anyone to forward a signed PGP message, although of course the 99 identity in the signature remains that of the original signer. The 100 intent here is somewhat different: we want to identify the actual 101 sender of a message and associate the signature with the message 102 itself. For that reason, the signature will be encapsulated in the 103 message differently than in a signed PGP message. The public key 104 used to sign the message will be included in the header, and its 105 binding with the envelope-from address of the message will be 106 verified. 108 The email identification problem is characterized by extreme 109 scalability requirements. There are currently on the order of 30 110 million domains and a much larger number of individual addresses. It 111 is important to preserve the positive aspects of current email 112 infrastructure, which include the ability for anyone to communicate 113 with anyone else without introduction. This contrasts with PGP's use 114 of trusted introducers to vouch for the authenticity of keys. Key 115 management based on introducers would have difficulty scaling to the 116 large number of addresses in use and retain the degree of 117 connectivity that email provides. 119 What is presented here is not a complete solution to the spam 120 problem. The intent is to give tools to the user to allow the 121 classification and prioritization of desired mail. Since much of the 122 undesirable mail is characterized by forged return addresses, the 123 identification of such messages is a major focus of this effort. 124 Some degree of accountability for the source of email messages will 125 also result, although spammers will still have the ability to operate 126 their own domains and key registration servers and create large 127 numbers of bogus identities. It is hoped that through tools such as 128 this that facilitate message classification, spam and 129 malware-generated messages may eventually be marginalized to the 130 point that they are irrelevant. 132 2. Message Format 134 An identified internet mail message is in much the same format as a 135 conventional mail message as defined in RFC 2822 [1]. Two new 136 headers, referred to as the signature and the verification header, 137 are defined. 139 2.1 Identified Mail Tag Syntax 141 Identified Mail uses a common encoding for the signature header 142 (X-IMAIL-SIG), the verification header (X-IMAIL-VERIFY), as well as 143 the KRS response. A line is composed of a set of tags delimited by a 144 ":" followed by a single value delimited by a ";". Tags may be any 145 number of alphanumeric characters, but SHOULD be limited to a single 146 character. A receiver decoding an unknown tag MUST silently discard 147 the tag and value. Values are similar to C quoted strings in that 148 each value starts and ends with a double quote. Special characters 149 are escaped by preceding them with a single backslash followed by the 150 encoded character. 152 The following escaped characters are currently recognized: 154 \n: an ascii newline (0x0A) 155 \r: an ascii carriage return (0x0D) 156 \f: an ascii form feed (0x0E) 157 \v: an ascii vertical tab (0x0B) 158 \\: the backslash character itself 159 \": the double quote character itself 161 A backslash followed by a character which doesn't have significance 162 above MUST be interpreted as that character as if the preceding 163 backslash was not present. Encoders MUST translate all special 164 characters into their escaped form. Decoders MUST reject strings 165 which span line breaks as the meaning is ambiguous given the way that 166 mail header continuation lines are formed. 168 In addition, each value MAY be split into multiple lines by as series 169 of quoted strings. Decoders MUST interpret multiple quoted strings 170 in a value as if they were all part of a single quoted line. 172 Values may be any value with the exception of ':', ';' and '"'. Any 173 value which cannot be represented in this way MUST be quoted and 174 escaped in the normal C string convention. Lines SHOULD be broken 175 apart for legibility and MUST NOT exceed the line length limits 176 specified in RFC 2822, section 2.1.1. 178 2.2 The Signature Header 180 The Signature header MUST be included in a message in order for it to 181 be considered an identified mail message. It has the syntax: 183 signature = "X-IMAIL-SIG:" signature-text CRLF 185 The signature-text contains a number of fields which represent the 186 signature itself, a public key used to create the signature, and 187 related information. An example of a signature is as follows: 189 X-IMAIL-SIG: v:"1"; h:"thomasm-u1"; d:"cisco.com"; 190 t:"1080771772.862325"; x:"1081203772"; a:"rsa-sha1"; e:"Iw=="; 191 n:"pZORwkeEetQnTVC7tw5MIE+31ROt/sGv5q+dxuwUIIqu5XKSva4P1/anPgIiz" 192 "7K8V0MaRDwDjKIuYYGaUO5IdDNfE7WEKe+/r8k3D0lrkNCa8qNPDSKljocN6y" 193 "d7Wjmx/Hk+tquACcpwhhDyVxzIBcj/A5aCApbeFeRkVvfFH70="; 194 s:"T3iRhynnuKx8+UNBuxMnDCIFet8RTM+VAs+STKM4P9ZqiEaUmG1rXmeXq3T+8" 195 "0oHhWtztZob/2twTxiqzgMD5MnFOTaqujJUBOmkIf1VR+ELzKq/vPZ+GmWs+h" 196 "mtSg3sH7jWrnvYHQpT6yey9TumnJVAdWepPl4budT9GFdpRuw="; 197 c:"Subject: new tags" 199 All tags and their values in the X-IMAIL-SIG line are included into 200 the cryptographic hash with the sole exception of the s: (signature) 201 tag and its value. The tags and their values are simply concatenated 202 to each other when forming the cryptograhic hash in the order they 203 are present in the X-IMAIL-SIG line. That is: 204 "v1hthomasm-u1dcisco.com[...]" Syntactic markers are NOT included and 205 the value used in the hash is before encoding/after decoding. The 206 final hash algorithm is as follows: 208 TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12) 210 where SIGTAGVALS is the encoding described above for the header tags/ 211 values and BODY is the SHA-1 hash of the body of the email itself. 212 Note that SHA-1 value of the body uses the full 16 bytes of the hash 213 (i.e., not truncated). 215 The tags used in the signature are as follows: 216 a: Algorithm. One-way hash and public key algorithm. Currently 217 this MUST be rsa-sha1. 218 c: Copied header. A copied header is a header which the sender 219 would like to cryptographically sign. Note that IMail does not 220 include any other headers into the cryptograhic hash. The headers 221 which are copied into the signature line are purely at the 222 discretion and local policy of the signer but SHOULD include the 223 Subject, From, and Date headers. Receiving MTAs and/or MUAs MAY 224 choose to replace the unsigned headers with headers which have 225 been signed so as to present untampered with headers to the user, 226 typically the headers copied from the originating domain. If such 227 a replacement is performed, the unsigned headers SHOULD be 228 preserved in the message (e.g., X-UNSIGNED-HEADER). 229 Note: For the hash calculation, the value MUST be encoded as the 230 copied header followed by a colon (":"), followed by a single 231 space, followed by the rest of value of the copied header. That 232 is, for hash calculation it looks like: 234 Subject: Hello World! 236 d: Domain of signer. This tag denotes the signing domain. It is 237 used to inform the receiver of the appropriate level of address 238 that is considered the authoritative domain in this context. For 239 example, if a message is received from jdoe@eng.example.com, the 240 d: tag might indicate that the domain is example.com or 241 eng.example.com. If this tag does not correspond to either the 242 hostname of the envelope-from address or a higher-level domain, 243 the signature MUST be ignored. 244 e: The RSA public exponent of the supplied signing key, base 64 245 encoded. 246 h: Signing host. This is purely informational and is not used by 247 IMail. 248 n: The RSA public modulus of the supplied signing key, base 64 249 encoded. Note that the key length is implicit with the number of 250 decoded bits in the modulus. Signers MUST support 1024 bits and 251 SHOULD support 768 and 1536 bits. Receivers MUST support 768, 252 1024 and 1536 bits. 253 s: The RSA signature over the computed one-way hash, base 64 254 encoded. 255 t: Timestamp. The time that this signature was created. The 256 format is the standard Unix seconds-since-1970 followed by a 257 fractional number which MUST be guaranteed to be unique for this 258 signing key. The intent of the fraction is to the guarantee the 259 uniqueness of any given signature at any particular instance. The 260 value is expressed as an unsigned integer. 261 x: Signature expiration in seconds-since-1970 format. Signatures 262 MUST NOT be considered valid if the current time at the receiver 263 is past the expiration date. The value is expressed as an 264 unsigned integer. 265 v: Version of these tags. This MUST be set to "1". The value is 266 expressed as an unsigned integer. 268 2.3 The Verification Header 270 The verification header is an optional header which is used to convey 271 the verification of a message from an MTA to an MUA or another MTA 272 within the same trust domain. If used, it is applied by an MTA that 273 is close to the point where an MTA or the recipient's MUA applies 274 policy based on the verification status of the message. 276 The verification header indicates whether an MTA was able to 277 successfully verify the message according to whatever policies it 278 decides to use. A recipient MUA or MTA MAY decide to rely on the 279 presence of a verification header in applying policy to the message 280 (e.g., moving an unverified message to a lower-priority folder), or 281 it may do such verification locally. 283 The verification header is not cryptographically protected, in order 284 to avoid the need to manage keys for MTAs. The verification header 285 SHOULD be deleted from the header when the message is sent via SMTP 286 outside the trust domain of the sender, and it MUST be discarded if 287 it received from an SMTP peer that is not trusted by the recipient 288 (normally one that is within the recipient's administrative control). 289 There MUST be at most one verification header in a message; MTAs 290 which perform message verification MUST ensure that they either agree 291 with the contents of an existing verification header, or replace it 292 with a new one. 294 An example of a verification header is as follows: 296 X-IMAIL-VERIFY: s:"y"; v:"y"; r:"68"; h:"imail.cisco.com" 298 The tags and values used by the verification header are as follows: 299 s: Signature. The value is "y" if there is a signature line from 300 the sending domain (ie, the domain suffix in the envelope from). 301 Otherwise the value is "n". 302 v: Verify. The value is "y" if the home domain's signature is 303 both present and the public key operation verifies correctly. 304 r: Rating. The value here is between -127 and 127 with negative 305 values expressing an adverse rating, zero being neutral and 306 positive values indicating a favorable rating. The rating value 307 is completely at the discretion of the entity supplying the 308 X-IMAIL-VERIFY header and MAY take into account many different 309 factors including the rating supplied by the home domain's KRS, 310 local and third party ratings, and any other factors the verifying 311 entity considers relevant. 312 h: Host. This is the fully qualified domain name of the MTA that 313 performed the verification. It should be noted that since the 314 X-IMAIL-VERIFY header is not cryptographically protected, users or 315 subsequent MTAs which make use of the X-IMAIL-VERIFY header must 316 independently ensure that it is not subject to tampering. 318 2.4 Canonicalization 320 In order to minimize the possibility of signature breakage due to 321 message or header rewriting while passing through the mail system, 322 mail agents which apply an Identified Mail signature MUST take steps 323 to ensure that the message is in a canonical form prior to signing 324 the message. Messages containing only 7-bit characters and lines of 325 78 characters or less MAY be sent without conversion. 327 Messages which do not meet both of these requirements MUST be 328 converted to MIME format, and the resulting MIME body is constrained 329 to 7 bits -- that is, the use of material requiring either 8bit or 330 binary transfer-encoding is NOT allowed. Such 8bit or binary 331 material MUST be encoded using either the quoted-printable or base64 332 encodings. 334 2.5 Use of From header 336 Identified Mail associates the key in the message with the 337 Envelope-from address of the message. This is done to allow mailing 338 lists which re-originate messages with their own envelope-from 339 address (but retain the original sender's address) to sign the 340 re-originated messages. However, it is the From address that is most 341 commonly seen by the recipient, and it is important that it not be 342 inconsistent with the Envelope-From address. 344 In order to retain the current semantics and visibility of the From 345 header, verifying mail agents SHOULD rewrite the From header if the 346 From address is not the same as the Envelope-from address, by 347 appending "via" and the Envelope-from address to the From header. 348 For example: 350 From: fenton@cisco.com via asrg-admin@ietf.org 352 This sort of address inconsistency is expected for mailing lists, but 353 might be otherwise used to mislead the recipient, for example if a 354 message supposedly from administration@your-bank.com had an 355 envelope-from address of fraud@badguy.com. 357 In order to prevent this rewriting of the From address from 358 interfering with subsequent reverification of the message if the From 359 header is signed, verifying MTAs MUST consider a From address which 360 differs from the signature header by the addition of "via" and the 361 envelope-from address to be valid. 363 3. Key Management 365 In order for these signatures to be meaningful, a trusted database of 366 public keys needs to be available to verify message signatures. The 367 PGP approach to this issue of trust is through the use of trusted 368 introducers, where individual keys are signed by others that may be 369 trusted by the user of the public key. Due to the large amount of 370 connectivity required in email and the (perhaps) lower standard of 371 trust required to accept an email message rather than, for example, 372 process a financial transaction, we present an alternative model 373 here. 375 3.1 Key Registration 377 In order to receive email messages, domains typically use one or more 378 MX (mail exchanger) resource records to indicate to where mail for 379 that domain should be directed. Similarly, DNS resource records can 380 be used to locate one or more hosts, referred to as Key Registration 381 Servers (KRSes), which may be considered authoritative to verify the 382 association of a key with an email addresses in the domain. To 383 locate the KRS, the verifying MTA/MUA queries DNS with the hostname 384 part of the envelope-from email address (e.g., eng.example.com for 385 tom@eng.example.com). 387 The zone file for a given domain might contain records such as the 388 following: 390 example.com. IN MX 10 mail.example.com. 391 example.com. IN MX 10 mail2.example.com. 392 _krs._tcp.example.com. IN SRV 10 10 378 krs.example.com. 393 _krs._tcp.example.com. IN SRV 10 10 378 krs2.example.com. 395 Key registration servers confirm (or deny) the binding between the 396 envelope-from email address used by the message and the key used to 397 sign the message. It does so by receiving a query containing the key 398 fingerprint and the envelope-from email address. It returns a 399 numerical value based on the policy of the sending domain as to 400 whether the key is authorized to be used in sending a message from 401 the specified address. One such policy might be as follows: 402 +127: Key is recognized and acceptable for the given address 403 0: Key is unrecognized 404 -127: Key is known to have been compromised; do not accept it 406 The outgoing MTA for a domain is most likely to perform rewriting, if 407 any, of the envelope-from address of the message (for example, to 408 remove an unnecessary subdomain). Since the KRS and the outgoing MTA 409 are usually under common administration, the KRS can be configured to 410 respond appropriately to expected rewritings of the envelope-from 411 address. 413 The following are some excerpts from a hypothetical KRS database: 415 #Rating TTL Address Key Fingerprint 416 100 86400 tom@eng.example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC 417 # Tom's usual address 418 100 86400 tom@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC 419 # Rewriting of Tom's address 420 100 86400 dick@example.com 91881749E520D8F53B0B91BBD8963D0D 421 # Dick's PC 422 100 86400 dick@example.com 549D8949351DDA4E7C961E0F58727795 423 # Dick's PDA 424 -100 864000 harry@example.com 8C8252070CA9ED401DD2EE2A7B31A8CF 425 # Harry's stolen PC 426 100 86400 harry@example.com 17E64AC44DD5F8891560919D3FC6EA52 427 # Harry's new PC 428 100 86400 harry@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC 429 # Tom is Harry's adminstrative 430 # assistant, so Harry allows Tom 431 # to originate mail for him. 432 100 604800 *@example.com 27985A61447CC8B514A82BFA4597174A 433 # Outgoing MTA key. MTA keys are 434 # less likely to require rapid 435 # revocation, hence the longer TTL. 436 100 86400 nobody@example.com * 437 # Any key will work for this address 438 # NOT RECOMMENDED! 440 The ability to configure multiple key registration servers for a 441 given domain is intended to provide a degree of fault-tolerance and 442 distribution of the key-verification load. The availability 443 requirement for key registration servers is somewhat higher than for 444 mail exchangers (and probably more comparable to that of domain name 445 servers) because real-time access to the key registration servers is 446 often required at the time an email message is received or relayed. 447 Accordingly, each domain defining key registration servers SHOULD 448 define at least two, and they SHOULD be located on different 449 networks. 451 The key registration servers for a domain need to be kept in as close 452 synchronization as possible. In particular, any key revocations that 453 take place MUST be reflected immediately in all key registration 454 servers for the domain. 456 3.2 Key Verification 458 Verification of public keys from key registration servers is 459 accomplished via a properly-formatted HTTP request. A sample request 460 might be formatted as follows: 462 http://krs2.example.com:378?domain=example.com 463 &name="john@example.com" 464 &keyfp="27985A61447CC8B514A82BFA4597174A" 465 &service="SMTP" 467 The fields in the query are as follows: 468 name: The envelope_from of the incoming mail. 469 keyfp: The public key fingerprint that was supplied in the 470 X-IMAIL-SIG line. The fingerprint is created as follows: create 471 the binary representation of the RSA exponent and modulus and 472 concatenate them as e|n. Run this value through SHA1 over the 473 full length and convert the first 12 bytes of the output of the 474 SHA1 operation to base 64. That is: 476 base64 (TRUNC (SHA1 ((e|n)), 12) 478 domain: The domain corresponding to the query to be performed. 479 This is used primarily to allow a single KRS to support multiple 480 domains, with each domain database being independently maintained. 481 This value corresponds to the d: value in the signature being 482 checked; it MUST be the same as or a superdomain of the 483 envelope-from address of the message. 484 service: The service for which the query is requested. Currently 485 the only valid service is "SMTP", though this may be expanded in 486 the future. 488 The KRS response is the IMAIL standard tag/value syntax with the 489 following tags/values defined: 490 s: status. Follows the general convention of SMTP/HTTP status 491 values (eg, 200, 300, 400, 500 semantics) with the following 492 values defined: 494 200: the lookup succeeded. 495 201: the lookup succeeded, but the keyfp/name combination was not found 496 500: any permanent failure. 498 t: Time to live. Responses SHOULD be cached on the receiver so as 499 to reduce the query/response load back to the KRS. Time to live 500 is expressed in seconds from when the query was sent. 501 r: Rating: like rating in the X-IMAIL-VERIFY, an integer between 502 -127 and 127 which as the sole discretion of the entity producing 503 the rating. Normally, revoked keys from the home KRS would be 504 given a (very) negative rating. 505 m: Matches. Some key fingerprints may in fact sign for more than 506 the single address that is present in the query. In order cut 507 down trips to the KRS, the Matches field describes with normal 508 Unix wildcard syntax what envelope_from patterns match this key 509 fingerprint. For example: 511 m:"*@example.com" 513 would inform the cache logic of the requestor that future queries 514 from example.com with this key fingerprint be given the same 515 rating and time to live. 516 Note that while the syntax of the matching pattern uses normal 517 unix wildcard syntax, the semantics of the wildcarding are 518 actually constrained to be a "longest prefix match" algorithm 519 where the prefix components are allowed to be either the left hand 520 side of the envelope_from, or the successive subdomain components. 521 In all cases, a matches value MUST NOT exceed the prefix of the 522 envelope from. That is, an entity from example.com cannot say 523 that it matches *@*.com since it is not authorized to sign for the 524 entire .com domain. 525 c: Comment. This is a free form string intended to convey a human 526 readable comment about the operation. This is typically used to 527 send diagnostic information for failed operations, etc. 528 v: Version of the responses. Currently this MUST be set to "1". 529 The value is expressed as an unsigned integer. 531 The key registration servers must use a mechanism that ensures that 532 only authorized users are able to deposit key fingerprints on the 533 server and revoke them. This may involve a mechanism such as an 534 authenticated HTTP exchange that requires the user's password in 535 order to register a public key fingerprint for that user on the 536 server. 538 It is implicit in this key management approach that only legitimate 539 key-to-address bindings may be registered on the key registration 540 servers. 542 In order to prevent harvesting of email addresses, KRSes MUST NOT 543 respond with any email address other than that presented in the query 544 or a more general address (for example, when the key fingerprint 545 corresponds to a domain MTA). 547 3.3 Address ratings 549 It is helpful, but probably not sufficient to confirm that a message 550 was signed using a key authorized for the stated address. This fact 551 alone says nothing about the security of the originating domain's key 552 registration servers, the method used to identify message senders 553 prior to MTA message signing, and the overall character of the 554 domain. Senders of spam are free to register domains and set up key 555 registration servers for those domains. Domains might also be set up 556 with explicitly open key registration policies, to permit anonymous 557 exchange of signed messages among groups of people. In either case, 558 mail from such domains might be less valued than from domains known 559 to be reliable. 561 The address rating service fulfills the need to distinguish domains 562 with differing registration policies and/or user behavior. The 563 rating service is envisioned as a third-party service, somewhat 564 analogous to a credit bureau, which the verifier of an identified 565 mail message MAY use to obtain a relative evaluation of the sending 566 address based on criteria established by the rating bureau. Ratings 567 will normally be granular to the domain of the sending address, but 568 may also give information on individual addresses. 570 A hypothetical ratings database might look something like this: 572 90 responsible-isp.com /* ISP with good security and policies */ 573 40 flaky-isp.com /* ISP that isn't very responsive */ 574 80 tom@flaky-isp.com /* Known good user at flaky ISP */ 575 0 spam-marketing.com /* Known source of UCE */ 577 Entries in the ratings database should be returned on the basis of 578 longest-match. In the example above, the address "tom@flaky-isp.com" 579 should return a rating of 80, not the value of 40 used for all other 580 addresses in the domain. 582 4. Policy Options 584 Identified Mail by itself introduces no new policy with respect to 585 handling email. However, the benefit of using Identified Mail lies 586 with the widespread deployment of policy which encourages the signing 587 of email and eventually marginalizes unsigned messages. 589 One place where policy can be implemented is at the receiving user. 590 The user can verify the signatures of messages as they are received, 591 and place unsigned messages in a "bulk mail" or similar folder to be 592 read (if at all) on a lower-priority basis. This would typically be 593 done through an enhancement to the mail user agent, probably at the 594 time messages are downloaded via a protocol such as POP. Since the 595 user must contact the key registration servers for all keys not in 596 the user's key cache, this could lengthen message downloading times, 597 and may present a problem for transitory users such as those on 598 dial-up lines. 600 The service provider (or enterprise) has the option of adding a 601 verification header to incoming messages. This considerably 602 simplifies things for the user, who can now use an existing mail user 603 agent. Most MUAs have the ability to filter messages based on 604 message headers or content; these filters would be used to implement 605 whatever policy the user wishes with respect to unsigned mail. 607 The service provider itself can implement a policy with respect to 608 unsigned mail, provided that the mail transfer agents have the 609 ability to verify signatures (regardless of whether or not they apply 610 the verification header to signed messages). Separate policies may 611 be defined for unsigned messages, messages with incorrect signatures, 612 and in cases where the signature cannot be verified, for example if 613 all the key registration servers are unreachable. 615 In the course of receiving a message, the service provider can 616 retrieve the public key of the sender from one of the designated 617 keyservers or from a local cache, and check the signature on the 618 message. If policy dictates, the service provider might reject the 619 message with an error such as: 621 5yx Unsigned messages not accepted 622 5uv Message signature incorrect 624 If the key registration server is not available, a temporary failure 625 message could be generated, such as: 627 4yx Unable to verify signature - key registration server unavailable 629 Policies of this sort naturally assume the widespread use of message 630 signatures. 632 5. Security Considerations 634 Fundamentally, the addition of signatures to email messages is all 635 about security, although not in the usual way of ensuring the secrecy 636 of data. 638 5.1 Potential Attacks 640 It has been observed that any mechanism that is introduced which 641 attempts to stem the flow of spam is subject to intensive attack. 642 Identified mail needs to be carefully scrutinized to identify 643 potential attack vectors and the vulnerability to each. Some of the 644 attacks that have been considered are described in the following 645 sections. 647 5.1.1 Key Registration Server DoS Attack 649 Since the key registration servers are distributed (potentially 650 separate for each domain), the number of servers that would need to 651 be attacked to defeat this mechanism on an Internet-wide basis is 652 very large. Nevertheless, key registration servers for individual 653 domains could be attacked, impeding the verification of messages from 654 that domain. This is not significantly different from the ability of 655 an attacker to deny service to the mail exchangers for a given 656 domain, although it affects outgoing, not incoming, mail. 658 A variation on this attack is that if a very large amount of mail 659 were to be sent using spoofed addresses from a given domain, the key 660 registration servers for that domain could be overwhelmed with 661 requests. However, given the low overhead of HTTP requests to the 662 KRSes relative to handling of the email message itself, such an 663 attack would be difficult to mount. 665 5.1.2 Key Registration Server Stall Tactic 667 An attacker trying to "jam" the signature mechanism might set up a 668 key registration server for a domain they control that responds very 669 slowly or perhaps not at all. They then send a large number of 670 messages from that domain, in an attempt to bring the signature 671 verification mechanism to a crawl and get domains to turn it off. 672 This could be mitigated by the use of appropriate timeouts on key 673 lookups and possibly by adapting these timeouts to message load. 674 Note that it is considerably easier to mitigate this attack when the 675 signature check is done by the terminating MTA than the MUA because 676 of the MTA's ability to return a temporary failure when the key can't 677 be retrieved. 679 5.1.3 Misappropriated private key 681 If the private key for a user is resident on their computer and is 682 not protected by an appropriately secure passphrase, it is possible 683 for malware to send mail as that user. The malware would, however, 684 not be able to spoof other senders' addresses, which would aid in 685 identification of the infected user and would limit the possibilities 686 for certain types of attacks involving socially-engineered messages. 687 For example, the malware would not be able to pose as the Microsoft 688 Windows Update distribution center. 690 A larger problem occurs if malware on many users' computers obtains 691 the private keys for those users and transmits them via a covert 692 channel to a site where they may be shared. The compromised users 693 would likely not know of the misappropriation until they receive 694 "bounce" messages from messages they are supposed to have sent. Many 695 users may not understand the significance of these bounce messages 696 and would not take action. 698 One countermeasure is to use a passphrase, although users tend to 699 choose weak passphrases. Nevertheless, the decoded private key might 700 be briefly available to compromise by malware when it is entered, or 701 might be discovered via keystroke logging. The added complexity of 702 entering a passphrase each time one sends a message would also tend 703 to discourage the use of a secure passphrase. 705 A somewhat more effective countermeasure is to send messages through 706 an outgoing MTA that can authenticate the sender and will sign the 707 message using its key which is normally authorized for all addresses 708 in the domain. Such an MTA can also apply controls on the volume of 709 outgoing mail each user is permitted to originate in order to further 710 limit the ability of malware to generate bulk email. 712 5.1.4 Message Replay Attack 714 In this attack, a spammer sends a message to be spammed to an 715 accomplice, which results in the message being signed by the 716 originating MTA (presuming that the sender doesn't have a valid 717 individual key for the domain). The accomplice resends the message, 718 including the original signature, to a large number of recipients, 719 possibly by sending the message to many compromised machines that act 720 as MTAs. The messages, not having been modified by the accomplice, 721 have valid signatures. 723 Several techniques for dealing with this type of attack have been 724 considered. One is to include in the request to the KRS not only the 725 fingerprint of the signing key but also a fingerprint of the 726 signature which would allow the KRS to detect, and flag as 727 unauthorized, the use of the same signature a very large number of 728 times. This would require the KRS to maintain a cache of signature 729 fingerprints, and would make caching of key registration data by 730 verifying MTAs and MUAs impossible. Both of these factors are very 731 undesirable from a performance standpoint. In addition, some 732 checking of message date/time fields would need to be introduced in 733 order to allow aging of the signature cache, where currently there is 734 no assumption that the sender have a valid real-time clock. 736 A similar approach is for verifying MTAs and MUAs to cache the 737 signatures themselves and detect duplications. However, only large 738 recipient MTAs are likely to process enough of the spam messages in 739 order to detect the duplications. Furthermore, there are legitimate 740 use cases involving mail forwarding where the same message might take 741 different paths to the same MTA, so this can only be applied in cases 742 where unexpectedly large numbers of duplicate signatures are 743 received. 745 Other partial solutions to this problem involve the use of rating 746 services to convey the fact that the specific envelope-from address 747 is being used for spam, and that messages from that sender are likely 748 to be spam. This requires a real-time detection mechanism (such as 749 detection by the KRS as described above) in order to react quickly 750 enough. However, such measures might be prone to abuse, if for 751 example an attacker resent a large number of messages received from a 752 victim in order to make them appear to be a spammer. 754 5.2 Other Considerations 756 At present, a message can be forwarded giving the sender no 757 indication as to the recipient's actual location (IP address, domain, 758 or eventual email address) on the Internet. A sender monitoring 759 queries to its KRS might be able to infer some of this when the 760 recipient's MTA, or even the actual recipient, checks the 761 identification of incoming messages. In cases where this may be 762 sensitive, trusted proxies SHOULD be employed by the recipient and/or 763 their domain. 765 6. Acknowledgements 767 Dave Rossetti provided much of the original motivation to address 768 this problem. In addition, thanks to Fred Baker, Mark Baugher, 769 Patrik Faltstrom, Don Johnsen, Dave Oran, and Dan Wing for their 770 suggestions and much helpful discussion around this issue. 772 7. References 774 7.1 Normative References 776 [1] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 778 7.2 Informative References 780 Authors' Addresses 782 Jim Fenton 783 Cisco Systems, Inc. 784 MS SJ-24/2 785 170 W. Tasman Drive 786 San Jose, CA 95134-1706 787 US 789 Phone: +1 408 526 5914 790 EMail: fenton@cisco.com 792 Michael Thomas 793 Cisco Systems, Inc. 794 MS SJ-21/3 795 170 W. Tasman Drive 796 San Jose, CA 95134-1706 797 US 799 Phone: +1 408 525 5386 800 EMail: mat@cisco.com 802 Intellectual Property Statement 804 The IETF takes no position regarding the validity or scope of any 805 Intellectual Property Rights or other rights that might be claimed to 806 pertain to the implementation or use of the technology described in 807 this document or the extent to which any license under such rights 808 might or might not be available; nor does it represent that it has 809 made any independent effort to identify any such rights. Information 810 on the procedures with respect to rights in RFC documents can be 811 found in BCP 78 and BCP 79. 813 Copies of IPR disclosures made to the IETF Secretariat and any 814 assurances of licenses to be made available, or the result of an 815 attempt made to obtain a general license or permission for the use of 816 such proprietary rights by implementers or users of this 817 specification can be obtained from the IETF on-line IPR repository at 818 http://www.ietf.org/ipr. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights that may cover technology that may be required to implement 823 this standard. Please address the information to the IETF at 824 ietf-ipr@ietf.org. 826 Disclaimer of Validity 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 831 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 832 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 833 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Copyright Statement 838 Copyright (C) The Internet Society (2004). This document is subject 839 to the rights, licenses and restrictions contained in BCP 78, and 840 except as set forth therein, the authors retain all their rights. 842 Acknowledgment 844 Funding for the RFC Editor function is currently provided by the 845 Internet Society.