HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:43:01 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 20 Mar 1996 23:00:00 GMT ETag: "2e98ad-abe1-31508df0" Accept-Ranges: bytes Content-Length: 44001 Connection: close Content-Type: text/plain INTERNET-DRAFT Donald E. Eastlake 3rd CyberCash Expires: 20 September 1996 21 March 1996 Mail Ubiquitous Security Extensions (MUSE) ---- ---------- -------- ---------- ------ Status of This Document This draft is file name draft-eastlake-muse-00.txt. Distribution of this document is unlimited. Comments should be sent to the ietf- muse@imc.org mailing list or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). D. Eastlake [Page 1] INTERNET-DRAFT MUSE 21 March 1996 Abstract Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming increasingly important as the Internet expands. However, use of secure mail is still rare due to the problems of key distribution and lack of migration to secure mail enabled user agents. This draft proposes partial solutions to these two problems by using coarser grained identity to permit authentication and confidentiality without user agent change, and DNS security for key distribution. Acknowledgments The contributions of the following persons to this draft are gratefully acknowledged: [to be added] (Spam is also the trademark name of a meat product by Hormel.) D. Eastlake [Page 2] INTERNET-DRAFT MUSE 21 March 1996 Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgments............................................2 Table of Contents..........................................3 1. Introduction............................................4 1.1 So Why Isn't Secure Mail Used?.........................4 1.2 Overview Of The MUSE Solution..........................5 1.3 So Why Might MUSE Succeed?.............................5 2. Bypassing the Requirement for User Agent Migration......6 2.1 Host Level Mail Security...............................7 2.1.1 MUSE Policies........................................7 2.1.2 Detailed MUSE Processing.............................9 2.1.2.1 Outgoing Mail Processing..........................10 2.1.2.2 Incoming Mail Processing..........................11 2.1.2.3 Local Mail........................................13 2.1.2.4 Transit Mail......................................14 2.2 Gateway Level Mail Security...........................14 2.3 Summary of MUSE Headers...............................15 2.4. Processing Load Considerations.......................16 3. Using DNS Security for Key Distribution................18 4. Security Considerations................................19 References................................................20 Author's Address..........................................20 Expiration and File Name..................................20 Appendix A: Policy Syntax.................................21 D. Eastlake [Page 3] INTERNET-DRAFT MUSE 21 March 1996 1. Introduction [This is an early draft and needs work...] Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming more important as the Internet expands. Increasingly critical and sensitive mail is being passed over the network making protection of the mail contents and verification of its origin ever more important. In addition, increasing amounts of "spam" (unsolicited junk messages, sometimes with false "from" and/or "to" addresses) and forged mail are plaguing the network. Critical and sensitive email could be better protected and spam could be more reliably filtered if the use of secure mail were ubiquitous. Two generations of Internet standard secure mail have been developed. The Privacy Enhanced Mail (PEM) is defined in RFCs 1421, 1422, 1423, and 1424. Just recently, the MIME security multiparts have been defined in RFC 1847 and secure mail derived by the generalization of PEM and use of MIME multiparts (MOSS) has been specified in RFC 1848. In the mean time, the most widely adopted secure mail on the Internet has been become PGP (Pretty Good Privacy, by Phil Zimmerman) and numerous other secure mail systems have been proposed and in some cases achieved limited deployment. Throughout this document, host are assumed to be identified by domain name and users are assumed to be identified by email address of the form user-name followed by an "@" followed by a domain name. These are the normal identifiers that are actually in use in the Internet. 1.1 So Why Isn't Secure Mail Used? Why has secure mail been so slow to be adopted? There are probably many reasons but one of the strongest is the problem of user agent migration. All of the systems mentioned above were initially designed with the idea that the end users who sent and received secure mail would use specially adapted mail programs and, in fact, they usually assumed the same special adaptations at each end. But many users are attached by circumstance or habit to a mail user agent that is not capable of producing or properly validating and/or decrypting secure mail. Even if their mail user agent is security capable, many users are not sufficiently motivated to make use of its security features. A second problem is that of key distribution. Most of these systems assume public key technology which requires each party to securely determine the public key of the other. (In some cases, secret key D. Eastlake [Page 4] INTERNET-DRAFT MUSE 21 March 1996 technology can be used. This requires each party to securely learn the secret key to be used and is thus no better from the point of view of key distribution.) Methods to obtain keys on line, such as the PGP key servers and inclusion of certificates from a hierarchy or web, have been limited and do not provide any assurance that the keying material obtained can be authenticated by the user's mail agent. 1.2 Overview Of The MUSE Solution MUSE partially solves the user agent migration problem by providing significant optional security at the host and mail gateway levels as described in section 2 below. MUSE partially solves the key distribution problem by supplementing existing techniques with key distribution via secure DNS as described in section 3 below. 1.3 So Why Might MUSE Succeed? Implementation of MUSE does not depend on end user action. It can be deployed by host, mail gateway, and DNS server administrators. These are the people who have to deal with security breakdowns, complaints about spam, etc., and are thus motivated to improve security. In addition, MUSE gives organizations a limited ability to enforce policies that require or prohibit the transmission or reception by that organization of encrypted and/or authenticated mail. Many organizations will choose not to impose such policies but any that wish to will be motivated to install MUSE. D. Eastlake [Page 5] INTERNET-DRAFT MUSE 21 March 1996 2. Bypassing the Requirement for User Agent Migration Current implementations of email security use special mail user agents (MUAs) although in some cases this can be accomplished with a security "plug-in" or, with enough user effort, by a separate application. This can be good because you want the security operations of signing and/or encrypting at the origin of the message and authenticating and/or decrypting at the destination to be as close to the user as possible. This minimizes the extent of the transmission path during which the mail is unprotected. In fact, you would really want the MUA in some single-user hardware (perhaps a laptop computer) which the user keeps under their physical control for maximum security. However, there are a tremendous number of mail user agents (MUAs) and many of them do not support secure mail. In some cases users are very attached to their MUA or do not have another easily available and do not want to or will not change. Even when a user has an MUA that supports security, many users just find it to be too much trouble to use. In such cases, the user will not get the best security available but they can still be provided significant security, through MUSE, by using coarser grained identity for authentication and encryption as explained below. Note that some users run their MUA to send and receive mail on multi-user computer systems which places them at the mercy of the computer operating system and ultimately gives them little more host level security in any case. The structure of the Internet for user to user mail between organizations, say X and Y, is now typically as shown below: +-------->The Internet<-------+ | | v v Firewall/Gateway X Firewall/Gateway Y | | | | | | | | user 1 System.A user 4 System.B laptop | \ laptop | \ | \ | \ user 2 user 3 user 5 user 6 laptop laptop MAIL STRUCTURE DIAGRAM [need to add references back to this diagram below...] Of course there are many variation on the above including multiple levels of firewall and directly connected systems with no firewall. D. Eastlake [Page 6] INTERNET-DRAFT MUSE 21 March 1996 2.1 Host Level Mail Security Simple mail security can be provided at the host level of granularity. How to do this is generally described below in this introduction to section 2.1. Subsequent sections describe how to specify MUSE policy and give the details of the processing. Basically, hosts can provide mail security as follows: Authentication: Outgoing mail can be signed by the host by signing the mail as a message/rfc822 object with the key for the host. A key for "system.organization.tld" for example if mail is being send by user@system.organization.tld. Confidentiality: For encryption, if an authenticated mail confidentiality key is accessible for the remote user or host, the message can be encrypted directly to them by the host level mail transport software. On receipt at a host, mail would be checked to see if it is encrypted to that host. If so, it would be decrypted before being delivered. In addition, if it is signed by the source host or user, that signature could be validated. The mail could be bounced or flagged if the validation fails or flagged if validation succeeds. All such verification processing is security policy dependent. 2.1.1 MUSE Policies The above description is highly simplified. It does not describe any means for the user or host administrator to control the host level mail security processing or for the user of an mail user agent to be made aware that mail received has been authenticated. Different hosts will have different policies. In addition, different users will have different policies (although sometimes such policies will be subordinated to their host's policy). There are four possible sources for MUSE policy: (1) the global MUSE default policy defined in this draft, (2) the host's MUSE policy, (3) the sender's static MUSE policy, and (4) the sender's per message policy as indicated by the "muse-policy: " header in an outgoing message. Policies 2 and 3 would normally be defined by a per host and per user file. This file contains simple text each line of which is interpreted as if it appeared in a "muse-policy:" header. The location and name of this file is system dependent. [Probably ".muse-policy" on UNIX like systems.] Each policy component consists of a policy category followed by a verb and possibly additional modifiers. The categories are: D. Eastlake [Page 7] INTERNET-DRAFT MUSE 21 March 1996 "encrypt", "sign", "verify", and "strip". The "sign" and "encrypt" categories control host level authentication and host executed encryption of outgoing messages. The "verify" and "strip" categories control the handling on incoming signed messages. Incoming messages encrypted to a host must always be decrypted because only the host will have access to its private key. Delivering such an encrypted- to-host message to a user without decrypting it would be useless. If a category appears more than once in a single policy file or in the headers of a single messages, the policy specification last appearing for that category prevails. The verbs available in each category are: "always", "once", and "never". Possible modifiers are "mandatory", "requested", "host", and "user". In the absence of modifiers, policies are treated as if the defaults "requested" and "user" appeared. Multiple policies can appear in a "muse-policy:" header or line in a policy file if separated by commas. Policy files lines may include parenthesized comments and be wrapped as in RFC822 headers. [do we need to add "filters" such that policy could be different for different senders/destinations? could be per policy line and of the form to restrict be sender and to restrict by destination. this would requiring adding an optional number or the like to muse-policy header lines to specify ordering] [do we need to add hooks in the policy syntax to invoke external programs at various steps during the MUSE processing so you could, for example, run a virus checker on incoming mail... ?] The following definitions are used in explaining the effect of MUSE policies verbs and modifiers: Signed: For the purposes of this draft, mail is signed if the outer MIME type is a proper multipart/signed. This means that the body interior to the first part of the multipart/signed has been signed. (MUSE implementations MAY also recognize as signed PEM, PGP, or other non-MIME formatted types of signed but not encrypted messages messages.) Encrypted: For the purposes of this draft, mail is encrypted if the outer MIME type, ignoring any number of completely enwrapping multipart/signed structures, is a proper multipart/encrypted. This means that the part of the message interior to the second part of the multipart/encrypted has been encrypted. (MUSE implementations MAY recognize PEM, PGP, or other non-MIME formatted types of encrypted messages and enwrapping signed strucutures.) The host level policy is the MUSE global default except as overridden by a host policy file. If the host policy has the modifier "host" D. Eastlake [Page 8] INTERNET-DRAFT MUSE 21 March 1996 for any category, the host policy prevails and any user specified policy for that category is ignored. If the host policy file includes the modifier "user" for any category or has neither the "user" or "host" modifiers, then the host policy is overridden by the user's policy if there is one. The user's policy is as specified in the user's policy file except that for outgoing messages sent by the user, a "muse-policy:" header or headers in the message override the user's policy file. "user" or "host" modifiers are ignored in user MUSE policy. The global policy defaults for MUSE are as follows: encrypt never requested user sign once requested user verify always requested user strip never requested user These MUSE standard defaults are biased against encryption and in favor of authentication. Authentication only implementations of MUSE, without confidentiality, are permitted. 2.1.2 Detailed MUSE Processing The following definitions are useful in describing MUSE mail processing in detail: Origination MUSE Header Processing: Find and parse any "muse- policy:" headers at the top level of the message removing them. Determine and remember the MUSE policy based on any host, user, and message header MUSE policy declarations. Suppress any "muse- authenticated:", "muse-confidentiality:", "muse-not-authentic:", and "muse-sender:" headers by prefixing them with "muse-bogus: by /host/ at /dt/ " where /host/ is the fully qualified domain name of the host doing the processing and /dt/ is the date and time of processing in RFC822 format. Destination MUSE Header Processing: Suppress any "muse- confidentiality:", "muse-authenticated:", "muse-not-authentic:", "muse-policy:", and "muse-sender:" headers by prefixing them with "muse-bogus: by /host/ at /dt/ " as above. Signature Processing: Add a "muse-sender: /rfc822-address/ at /dt/" header and then sign the resulting message/rfc822 object. (SMTP/RFC822 permits an arbitrary "from:" address to be specified D. Eastlake [Page 9] INTERNET-DRAFT MUSE 21 March 1996 in a message. MUSE does not interfere with that feature but authenticates what will be the SMTP envelope sender address by including it within the signed portion of the message. As a local mater, the local user name that is sending the message must be securely communicated to the MUSE equipped MTA. This name is then extended with the hosts fully qualified domain name.) Copy all headers from the signed object to the new outer message except "muse-" and "content-" headers. There should be no "muse-" headers in the outer message and its "content-" header should be appropriate for the multipart/signed type it carries. Encryption Processing: Encrypt mail as a message/rfc822 object under the destination key. Add a pseudo-cc to musemaster@host where "host" is the host where encryption is being done. (This is necessary so that the copy of the message in any bounces that are received can be decrypted.) Only required mail routing headers are copied to the new outer message and supplemented by a new "date:" header and by "content-" headers appropriate for the multipart/encrypted type. Destination Key: This key is determined by looking for a key for the destination user (see section 3). If none is available, then looking for a key for the destination user's email address domain name part. The first applicable key found above is the destination key. If none is found, there is no destination key. If the implementation of MUSE does not include confidentiality, proceed as if there were no destination key. If key access attempts time out or otherwise fail in a transient fashion, the mail SHOULD be queued in a manner similar to transient delivery failure queuing. 2.1.2.1 Outgoing Mail Processing The following steps describe the MUSE processing of outgoing mail. This processing may be organized or performed in any order provided the result is the same as the following organization and order: (1) Do origination MUSE header processing. (2) Confidentiality Processing: (2a) If the policy is "never requested" go to step 3. (2b) Determine the Destination Key as described above. (2c) Perform actions as per policy below: encrypt always requested: Perform encryption processing under the D. Eastlake [Page 10] INTERNET-DRAFT MUSE 21 March 1996 destination key or pass on mail unencrypted if there is no destination key. (This may result in superencryption.) encrypt always mandatory: Perform encryption processing under the destination key or bounce it back to the originator if there is no destination key. (This may result in superencryption.) encrypt once requested: If the mail is encrypted, do nothing. If the mail is not encrypted, perform encryption processing under the destination key or pass on mail unencrypted if there is no destination key. encrypt once mandatory: If the mail is encrypted, do nothing. If the mail is not encrypted perform encryption processing under the destination key or bounce it back to the originator if there is no destination key. encrypt never mandatory: Pass the mail on if it is unencrypted or bounce it back to the originator if it is encrypted. (3) Authentication Processing. Perform actions as per policy below: sign always: Perform signature processing with the host key. (The "mandatory"/"request" modifier is ignored. This may result in nested signatures.) sign once: Perform signature processing with the host key unless the message is already signed. (The "mandatory"/"request" modifier is ignored.) sign never requested: Pass on the mail without signature processing. sign never mandatory: Strip off and discard any completely enwrapping signatures, saving any "receive:" lines add adding them back after removing the surrounding multipart/signed, and then pass on the resulting message. (4) Perform remainder of standard non-MUSE mail processing, including addition of a "received:" header. 2.1.2.2 Incoming Mail Processing (1) Do Destination MUSE Header Processing. (2) Determine if message is encrypted to host. If not, go to step 3. In making this determination, after checking to see if the entire message is encrypted, recursively examine all visible MIME parts to see if any is encrypted. (This is necessary, for example, to find D. Eastlake [Page 11] INTERNET-DRAFT MUSE 21 March 1996 and decrypt any bounced messages copies that were encrypted by this host.) If an interior encrypted MIME part is found, decrypt it as below. If the message is encrypted to the host, see if there are any signatures enwrapping the encrypted message (or enwrapping at any higher level the interior encrypted MIME part). If there are and verify policy is anything other than "never", verify as many as possible, remember their signers, and strip them off. If there are and verify policy is "never", just strip these signatures. (Note, the signatures will no longer verify after the encrypted mail they enclose has been decrypted so they will be useless.) When stripping signatures or the headers associated with a multipart/encrypted, also remember any "received:" lines in the stripped headers. Then decrypt the message or interior MIME part, remember that you have done so, and go to step 1 or step 2 depending on whether the resulting decrypted part is at the top level or an interior body, respectively. (A message may have been encrypted and then superencrypted to a host.) (3) Verification Processing. Perform actions as per policy below: verify never: Do nothing. (The "mandatory"/"request" modifier is ignored.) verify once requested: Try to verify the outermost fully enclosing signature if there is one and remember the results. If the message is not signed, got to step 5. verify once mandatory: Try to verify the outermost enclosing signature and remember the results if there is one. If verification is not possible, bounce back to originator or discard as per local policy. verify always requested: Try to verify all fully enclosing signatures and remember the results for each. If the message is not signed, go to step 5. verify always mandatory: Try to verify all fully enclosing signatures and remember the results for each. If verification is not possible, bounce back to originator or discard as per local policy. (4) Strip Processing. Perform actions as per policy below. (The "mandatory"/"request" modifier is ignored in all cases.) strip never: Do nothing. strip once: Strip the outermost enwrapping signature and perform D. Eastlake [Page 12] INTERNET-DRAFT MUSE 21 March 1996 destination MUSE header processing on the result, if there is such a signature. Remember any "received:" headers that are removed. strip always: Strip all enwrapping signatures and perform destination MUSE header processing on the result, if there were any such signatures. Remember any "received:" headers that are removed. (5) Header Injection. Add a muse-authenticated: from /sender/ by /checker/ at /dt/ or muse-not-authentic: claimed from /sender/ by /checker/ at /dt/ header for each enwrapping signature found in steps 2 and 3 that was verified or which could not be verified, respectively. [Should header distinguish between a verfication that could not complete and one that found the signature to definitely be bad?] /checker/ is the domain name of the host that performed the authentication. /sender/ is the email address from the "muse-sender:" header protected by the authenticated signature. /dt/ is the RFC822 format date and time that the verification was performed. Add a muse-confidential: to /decryptor/ at /dt/ header for encryption removed in step 2. /decryptor/ is the domain name of the host to which the message had been encrypted and which performed the decryption. /dt/ is the RFC822 format date and time at which the decryption was performed. Restore any "received:" header removed in steps 2 and 4. (6) Perform remainder of standard non-MUSE mail processing including addition of a "received:" header. 2.1.2.3 Local Mail Mail that that is sent locally on a MUSE equipped host should be processed as if it went through the outgoing mail processing and then the incoming mail processing. However, enormous efficiencies in processor time can be achieved by making a few special test as follows: (1) If the MUSE policy and Destination Key situation would call for encrypting the mail to the current host, then don't bother. It will take a lot of computation and you'll just have to decrypt it again. In this case, the "muse-confidential:" header that would have resulted from the encryption and then decryption SHOULD be added. D. Eastlake [Page 13] INTERNET-DRAFT MUSE 21 March 1996 (If the policy and destination key are such that the mail would be encrypted to the destination user, then this encryption SHOULD be performed. Mail in the user's "in box" will be less vulnerable if encrypted.) (2) If the MUSE policy is such that the message would be authenticated and then that signature verified and stripped off, then don't bother. It will take a lot of computation for no good purpose. If the policy is such that a signature would be added and not stripped, then it MUST be added, even if the mail is local. In either case, a "muse-authenticated:" header that would have resulted from the signing and verification MUST be added if verification policy calls for it. 2.1.2.4 Transit Mail Transit mail is mail that neither originates nor terminates at the host in question unless that host is acting as a mail gateway as described in section 2.2. Ordinary non-MUSE mail processing is performed on transit mail, including addition of a "received:" header. No special MUSE processing is done. 2.2 Gateway Level Mail Security A number of steps must be taken to properly handle MUSE mail at a gateway. (A mail gateway is also a host and performs the processing specified in 2.1 above for locally originated and locally terminating mail.) For gateway mail policy, a gateway mail host has two additional policy files [.muse-gateway-out, .muse-gateway-in]. The gateway can not access the remote user policy file but does take into account any "muse-policy:" header it finds at the top level of an outgoing message (and removes them to the extent it can do so without breaking retained signatures). For outgoing gateway mail, the situation is somewhat simpler. Hosts that send mail out through the gateway are normally manually configured to do so. A local gateway policy, not specified by MUSE, must be adopted as to what evidence MUSE will accept at the gateway to trust that it knows the host that the mail is originating from. This could be IP address but the recommended technique is to have all hosts forwarding to the gateway have a "sign always" policy and use these signatures to verify that the outgoing mail is coming from within the domain. Gateways MUST not sign mail whose sender they can not authenticate according to their local policy. The verify and D. Eastlake [Page 14] INTERNET-DRAFT MUSE 21 March 1996 sign parts of the outgoing gateway policy are first applied, then the sign and encrypt parts. For incoming gateway mail, the situation is somewhat more complex. If the incoming gateway is implemented invisibly, by rewriting the addresses of outgoing messages to encourage replies to go directly to the gateway, etc., the it is a matter of local knowledge at the incoming gateway that it is a gateway and when it should apply host MUSE policy or incoming gateway MUSE policy. In this case, to senders, it appears to be the destination host. However, in the case where an incoming gateway is implemented by MX records, MUSE processing can not be done to it. [well, you sort of could if you waited until you actually knew which host you were going to SMTP the message to and then included that host as the final step in the Destination Key determination... but that would be a pain as you could encrypt the mail to the MX host, fail during transmission, find it has gone away, and have to discard the encrypted mail and re- encrypt to the next MX host, etc] The verify and sign parts of the incoming gateway policy are first applied then the sign and encrypt parts. Hosts receiving incoming mail that they trust is from a gateway modify their destination MUST header processing to retain any "must-authenticated:", "muse-confidential:", and "must-not- authentic:" headers from the gateway they encounter that they would otherwise declare bogus. It is recommended that such hosts use the gateway signature to confirm that mail is from the gateway and that gateway incoming policy include "sign always". 2.3 Summary of MUSE Headers All header lines beginning with "muse-" are reserved for use by MUSE or future extensions thereof. The six such headers defined in this draft are briefly explained below in alphabetic order: muse-authenticated: from /sender/ by /checker/ at /dt/ Indicates that an incoming message has been comfirmed as from the RFC822 address /sender/ with the verification done by host /checked/. /dt/ is the RFC822 formatted date and time of this verification. muse-bogus: by /host/ at /dt/ /bogus-muse-header/ This header is used to prefix other apparent muse headers (the /bogus-muse-header/) when received from an untrusted or inappropriate source. This stops the /bogus-muse-header/ from being recognized or trusted. /host/ is the fully qualified domain name of the host adding the muse-bogus prefix and /dt/ is the RFC822 formatted date and time of prefixing. D. Eastlake [Page 15] INTERNET-DRAFT MUSE 21 March 1996 muse-confidential: to /decryptor/ at /dt/ This header indicates that an incoming message was successfully decrypted at the host whose fully qualified domain name is /decryptor/. /dt/ is the RFC822 formatted time the decryption occurred. muse-not-authentic: claimed from /sender/, bad by /checker/ at /dt/ This header indicates that an incoming signature and signed "muse-sender:" could not be verified. /sender/ was the claimed sender in the unverified "muse-sender:" header. /checker/ is the domain name of the host that performed the failing verification and /dt/ is the RFC22 formatted date and time of the check. muse-policy: // This header is used by a user to state its requested MUSE policy to their local host (and outgoing gateway if the local host is configured not to strip out "muse-policy:" headers). /policies/ are the policy statements as per Appendix A. muse-sender: /rfc822-address/ at /dt/ This header is added to mail by a MUSE host or gateway just before signing the message. It causes the authentic local or trusted SMTP envelope sender address to be incorporated into the authenticated message/rfc822 body part. /dt/ is the RFC822 formatted date and time that the muse-sender header is added. 2.4. Processing Load Considerations The cryptographic calculations involved in signing and/or encrypting messages can impose substantial processing loads. Installing MUSE software on an existing host with high mail traffic or a busy mail gateway may produce congestion and make it impossible to keep up with the mail flow. The largest part of this load will normally be public key computations which are per message. This additional processing time will be affected by message length only as a second order effect. There are only 86,400 seconds in a day. Assuming a gateway or host took an average of 2 seconds per message to sign/encrypt/verify/decrypt, the maximum it could possibly hand would be 43,200. In fact, due to variations from hour to hour and from day to day, periodic congestion could begin at around an average of 6,000 messages a day for such a gateway. [anyone have a better rule of thumb than monthly volume being 100 time the busy hour?] Because this is primarily a computational load due to multi-precision arithmetic, processors that are faster and/or have wider arithmetic are the best solution. For example, a 100 megahertz 32 bit processor D. Eastlake [Page 16] INTERNET-DRAFT MUSE 21 March 1996 would, for this application, have roughly a quarter the capacity of a 200 megahertz 64 bit processor. D. Eastlake [Page 17] INTERNET-DRAFT MUSE 21 March 1996 3. Using DNS Security for Key Distribution Section 2 above does not address the 2nd problem holding back ubiquitous secure mail, the problem of key distribution. The private keys for signing/decrypting at a host or gateway are normally configured on line at that host or gateway and thus available. But how do you find the public key, or determine the lack of such a key, for a remote user, host, or gateway for encrypting/verifying? The answer is DNS Security as described in draft-ietf-dnssec-secext- *.txt. You can find a key for a user or host by looking for authenticated KEY RRs whose owner name is that host's domain name or user's email address mapped into a domain name. If the retrieval fails hard, then there is no KEY in the DNS for that user. If the retrieval times out, you do not know. If one or more KEY RRs are returned, MUSE software must examine them to see that at least one has the appropriate flag bits to indicate that it is a user KEY authorized for use in mail. If an appropriate KEY is found, depending on additional KEY flag bits, for a destination user or host, it can be used to encrypt mail being sent to that destination. If a signed message has been received and an appropriate key is found for the signer, depending on additional KEY flag bits, then the signature can be authenticated. Authentication of retrieved KEY RRs is provided automatically by security aware DNS resolvers which must be used on MUSE equipped hosts that perform encryption or signature verification. A MUSE implementation that only signs and/or decrypts messages does not need to access remote keys. D. Eastlake [Page 18] INTERNET-DRAFT MUSE 21 March 1996 4. Security Considerations The use of coarser grained identification and partial path encryption for email security provides a lower level of security than direct user to user authentication and encryption. In the case of host level mail security, the difference may not be large if the user was dependent on host security in any case. But gateway level mail security, while better than nothing, is noticeable less security than user level security. While security can be improved by the used of the techniques described in this draft, failure to secure other parts of the mail process can negate such improvements. For example, using MUSE to add host level authentication and verification does no good if the user receives and transmits mail via an insecure link between a personal computer client and the MUSE enhanced software on their mail server host. While MUSE is biased towards providing externally visible authentication of messages, this has little effect on any anonymity desired by the user. Any authentication added by MUSE is at the host or gateway level and does not reveal individual identity which was used, for example, to sign the original message inside a layer of encryption. Thus, in terms of anonymity, MUSE does approximately what increasing the security of some of the "received" header lines would do. MUSE provides policy options which can attempt to filter out encryption, block encrypted mail, strip off authentication, etc. These policies only work to the entent that such encryption or authentication is based on the MIME security multiparts or other syntax recognized by the MUSE implementation. Encryption or authentication could by marked as a MIME application type or other nono-RFC1827 formatting and encrypted messages can be hidden by stegeographic techniques. Such techniques would typcially not be recognized by MUSE. Policies which mandatorially add authentication or confidentially can be enforced but policies to block encrypted or authenticated mail are not reliably enforceable. The use of headers, such as "muse-authenticated:", without any inherent security, to control or flag the results of mail security is a potential weakness. Great care must be taken in configuration and user education to avoid insecure configurations and excessive user confidence in spoofable MUSE headers. D. Eastlake [Page 19] INTERNET-DRAFT MUSE 21 March 1996 References RFC822 - D. Crocker, "Standard for the format of ARPA Internet text messages", 08/13/1982. RFC1034 - P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. RFC1035 - P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. RFC1521 - N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 09/23/1993. RFC1522 - K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993. RFC1847 - J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 10/03/1995. draft-ietf-dnssec-secext-*.txt Author's Address Donald E. Eastlake, 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508-287-4877 +1 508-371-7148 (fax) +1 703-620-4200 (main office, Reston, Virginia, USA) email: dee@cybercash.com Expiration and File Name This draft expires 20 September 1996. Its file name is draft-eastlake-muse-00.txt. D. Eastlake [Page 20] INTERNET-DRAFT MUSE 21 March 1996 Appendix A: Policy Syntax ::= encrypt | sign | verify | strip ::= always | never | once ::= mandatory | requested | user | host ::= *( ) ::= *(,) Comments are parenthesized and lines may be wrapped as in RFC822 headers. D. Eastlake [Page 21]