[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02

Network Working Group                                          J. Fenton
Internet-Draft                                                 M. Thomas
Expires: November 30, 2004                           Cisco Systems, Inc.
                                                            June 1, 2004

                        Identified Internet Mail

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 30, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   This document describes extensions to the format of electronic mail
   messages and a public-key infrastructure to permit verification of
   the source of messages by either mail transport agents (MTAs) or mail
   user agents (MUAs).  This may be used to implement a policy which,
   for example, favors the delivery of identified messages over messages
   lacking signatures or having incorrect signatures.  Mechanisms by
   which signing of messages and verification of signatures can be
   performed by a trusted MTA, in order to minimize impact on the user,
   are also presented.

Fenton & Thomas        Expires November 30, 2004                [Page 1]

Internet-Draft          Identified Internet Mail               June 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Message Format . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Identified Mail Tag Syntax . . . . . . . . . . . . . . . .  5
     2.2   The Signature Header . . . . . . . . . . . . . . . . . . .  6
     2.3   The Verification Header  . . . . . . . . . . . . . . . . .  7
     2.4   Canonicalization . . . . . . . . . . . . . . . . . . . . .  8
     2.5   Use of From header . . . . . . . . . . . . . . . . . . . .  9
   3.  Key Management . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1   Key Registration . . . . . . . . . . . . . . . . . . . . . 10
     3.2   Key Verification . . . . . . . . . . . . . . . . . . . . . 11
     3.3   Address ratings  . . . . . . . . . . . . . . . . . . . . . 13
   4.  Policy Options . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     5.1   Potential Attacks  . . . . . . . . . . . . . . . . . . . . 17
       5.1.1   Key Registration Server DoS Attack . . . . . . . . . . 17
       5.1.2   Key Registration Server Stall Tactic . . . . . . . . . 17
       5.1.3   Misappropriated private key  . . . . . . . . . . . . . 18
       5.1.4   Message Replay Attack  . . . . . . . . . . . . . . . . 18
     5.2   Other Considerations . . . . . . . . . . . . . . . . . . . 19
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 21
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 22

Fenton & Thomas        Expires November 30, 2004                [Page 2]

Internet-Draft          Identified Internet Mail               June 2004

1.  Introduction

   Internet users have recently been subjected to a torrent of unwanted
   email messages.  These generally take two forms:
   1.  Messages originated by "spammers" to send advertising or
       solicitation, or as part of a confidence scheme
   2.  Messages sent automatically by worms and other malware attempting
       to infect additional systems

   In both cases, a large proportion of the messages attempt to disguise
   their true source, to frustrate attempts to shut down the spammer, to
   disguise the identity of the infected system sending the message, or
   to support a social-engineering goal.  Since SMTP permits senders to
   use any return address they wish, the addition of a signature to
   messages limits the opportunity of spammers or malware to forge
   return addresses, and thus provides some degree of accountability for
   the source of email messages.

   As currently used, message signatures such as those generated by PGP
   cover only the body of a message.  It is therefore possible for
   anyone to forward a signed PGP message, although of course the
   identity in the signature remains that of the original signer.  The
   intent here is somewhat different: we want to identify the actual
   sender of a message and associate the signature with the message
   itself.  For that reason, the signature will be encapsulated in the
   message differently than in a signed PGP message.  The public key
   used to sign the message will be included in the header, and its
   binding with the envelope-from address of the message will be

   The email identification problem is characterized by extreme
   scalability requirements.  There are currently on the order of 30
   million domains and a much larger number of individual addresses.  It
   is important to preserve the positive aspects of current email
   infrastructure, which include the ability for anyone to communicate
   with anyone else without introduction.  This contrasts with PGP's use
   of trusted introducers to vouch for the authenticity of keys.  Key
   management based on introducers would have difficulty scaling to the
   large number of addresses in use and retain the degree of
   connectivity that email provides.

   What is presented here is not a complete solution to the spam
   problem.  The intent is to give tools to the user to allow the
   classification and prioritization of desired mail.  Since much of the
   undesirable mail is characterized by forged return addresses, the
   identification of such messages is a major focus of this effort.
   Some degree of accountability for the source of email messages will
   also result, although spammers will still have the ability to operate

Fenton & Thomas        Expires November 30, 2004                [Page 3]

Internet-Draft          Identified Internet Mail               June 2004

   their own domains and key registration servers and create large
   numbers of bogus identities.  It is hoped that through tools such as
   this that facilitate message classification, spam and
   malware-generated messages may eventually be marginalized to the
   point that they are irrelevant.

Fenton & Thomas        Expires November 30, 2004                [Page 4]

Internet-Draft          Identified Internet Mail               June 2004

2.  Message Format

   An identified internet mail message is in much the same format as a
   conventional mail message as defined in RFC 2822 [1].  Two new
   headers, referred to as the signature and the verification header,
   are defined.

2.1  Identified Mail Tag Syntax

   Identified Mail uses a common encoding for the signature header
   (X-IMAIL-SIG), the verification header (X-IMAIL-VERIFY), as well as
   the KRS response.  A line is composed of a set of tags delimited by a
   ":" followed by a single value delimited by a ";".  Tags may be any
   number of alphanumeric characters, but SHOULD be limited to a single
   character.  A receiver decoding an unknown tag MUST silently discard
   the tag and value.  Values are similar to C quoted strings in that
   each value starts and ends with a double quote.  Special characters
   are escaped by preceding them with a single backslash followed by the
   encoded character.

   The following escaped characters are currently recognized:

     \n: an ascii newline (0x0A)
     \r: an ascii carriage return (0x0D)
     \f: an ascii form feed (0x0E)
     \v: an ascii vertical tab (0x0B)
     \\: the backslash character itself
     \": the double quote character itself

   A backslash followed by a character which doesn't have significance
   above MUST be interpreted as that character as if the preceding
   backslash was not present.  Encoders MUST translate all special
   characters into their escaped form.  Decoders MUST reject strings
   which span line breaks as the meaning is ambiguous given the way that
   mail header continuation lines are formed.

   In addition, each value MAY be split into multiple lines by as series
   of quoted strings.  Decoders MUST interpret multiple quoted strings
   in a value as if they were all part of a single quoted line.

   Values may be any value with the exception of ':', ';' and '"'.  Any
   value which cannot be represented in this way MUST be quoted and
   escaped in the normal C string convention.  Lines SHOULD be broken
   apart for legibility and MUST NOT exceed the line length limits
   specified in RFC 2822, section 2.1.1.

Fenton & Thomas        Expires November 30, 2004                [Page 5]

Internet-Draft          Identified Internet Mail               June 2004

2.2  The Signature Header

   The Signature header MUST be included in a message in order for it to
   be considered an identified mail message.  It has the syntax:

   signature = "X-IMAIL-SIG:" signature-text CRLF

   The signature-text contains a number of fields which represent the
   signature itself, a public key used to create the signature, and
   related information.  An example of a signature is as follows:

   X-IMAIL-SIG: v:"1"; h:"thomasm-u1"; d:"cisco.com";
        t:"1080771772.862325"; x:"1081203772"; a:"rsa-sha1"; e:"Iw==";
        c:"Subject: new tags"

   All tags and their values in the X-IMAIL-SIG line are included into
   the cryptographic hash with the sole exception of the s: (signature)
   tag and its value.  The tags and their values are simply concatenated
   to each other when forming the cryptograhic hash in the order they
   are present in the X-IMAIL-SIG line.  That is:
   "v1hthomasm-u1dcisco.com[...]" Syntactic markers are NOT included and
   the value used in the hash is before encoding/after decoding.  The
   final hash algorithm is as follows:

        TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12)

   where SIGTAGVALS is the encoding described above for the header tags/
   values and BODY is the SHA-1 hash of the body of the email itself.
   Note that SHA-1 value of the body uses the full 16 bytes of the hash
   (i.e., not truncated).

   The tags used in the signature are as follows:
      a: Algorithm.  One-way hash and public key algorithm.  Currently
      this MUST be rsa-sha1.
      c: Copied header.  A copied header is a header which the sender
      would like to cryptographically sign.  Note that IMail does not
      include any other headers into the cryptograhic hash.  The headers
      which are copied into the signature line are purely at the
      discretion and local policy of the signer but SHOULD include the
      Subject, From, and Date headers.  Receiving MTAs and/or MUAs MAY
      choose to replace the unsigned headers with headers which have
      been signed so as to present untampered with headers to the user,

Fenton & Thomas        Expires November 30, 2004                [Page 6]

Internet-Draft          Identified Internet Mail               June 2004

      typically the headers copied from the originating domain.  If such
      a replacement is performed, the unsigned headers SHOULD be
      preserved in the message (e.g., X-UNSIGNED-HEADER).
      Note: For the hash calculation, the value MUST be encoded as the
      copied header followed by a colon (":"), followed by a single
      space, followed by the rest of value of the copied header.  That
      is, for hash calculation it looks like:

         Subject: Hello World!

      d: Domain of signer.  This tag denotes the signing domain.  It is
      used to inform the receiver of the appropriate level of address
      that is considered the authoritative domain in this context.  For
      example, if a message is received from jdoe@eng.example.com, the
      d: tag might indicate that the domain is example.com or
      eng.example.com.  If this tag does not correspond to either the
      hostname of the envelope-from address or a higher-level domain,
      the signature MUST be ignored.
      e: The RSA public exponent of the supplied signing key, base 64
      h: Signing host.  This is purely informational and is not used by
      n: The RSA public modulus of the supplied signing key, base 64
      encoded.  Note that the key length is implicit with the number of
      decoded bits in the modulus.  Signers MUST support 1024 bits and
      SHOULD support 768 and 1536 bits.  Receivers MUST support 768,
      1024 and 1536 bits.
      s: The RSA signature over the computed one-way hash, base 64
      t: Timestamp.  The time that this signature was created.  The
      format is the standard Unix seconds-since-1970 followed by a
      fractional number which MUST be guaranteed to be unique for this
      signing key.  The intent of the fraction is to the guarantee the
      uniqueness of any given signature at any particular instance.  The
      value is expressed as an unsigned integer.
      x: Signature expiration in seconds-since-1970 format.  Signatures
      MUST NOT be considered valid if the current time at the receiver
      is past the expiration date.  The value is expressed as an
      unsigned integer.
      v: Version of these tags.  This MUST be set to "1".  The value is
      expressed as an unsigned integer.

2.3  The Verification Header

   The verification header is an optional header which is used to convey
   the verification of a message from an MTA to an MUA or another MTA
   within the same trust domain.  If used, it is applied by an MTA that
   is close to the point where an MTA or the recipient's MUA applies

Fenton & Thomas        Expires November 30, 2004                [Page 7]

Internet-Draft          Identified Internet Mail               June 2004

   policy based on the verification status of the message.

   The verification header indicates whether an MTA was able to
   successfully verify the message according to whatever policies it
   decides to use.  A recipient MUA or MTA MAY decide to rely on the
   presence of a verification header in applying policy to the message
   (e.g., moving an unverified message to a lower-priority folder), or
   it may do such verification locally.

   The verification header is not cryptographically protected, in order
   to avoid the need to manage keys for MTAs.  The verification header
   SHOULD be deleted from the header when the message is sent via SMTP
   outside the trust domain of the sender, and it MUST be discarded if
   it received from an SMTP peer that is not trusted by the recipient
   (normally one that is within the recipient's administrative control).
   There MUST be at most one verification header in a message; MTAs
   which perform message verification MUST ensure that they either agree
   with the contents of an existing verification header, or replace it
   with a new one.

   An example of a verification header is as follows:

   X-IMAIL-VERIFY: s:"y"; v:"y"; r:"68"; h:"imail.cisco.com"

   The tags and values used by the verification header are as follows:
      s: Signature.  The value is "y" if there is a signature line from
      the sending domain (ie, the domain suffix in the envelope from).
      Otherwise the value is "n".
      v: Verify.  The value is "y" if the home domain's signature is
      both present and the public key operation verifies correctly.
      r: Rating.  The value here is between -127 and 127 with negative
      values expressing an adverse rating, zero being neutral and
      positive values indicating a favorable rating.  The rating value
      is completely at the discretion of the entity supplying the
      X-IMAIL-VERIFY header and MAY take into account many different
      factors including the rating supplied by the home domain's KRS,
      local and third party ratings, and any other factors the verifying
      entity considers relevant.
      h: Host.  This is the fully qualified domain name of the MTA that
      performed the verification.  It should be noted that since the
      X-IMAIL-VERIFY header is not cryptographically protected, users or
      subsequent MTAs which make use of the X-IMAIL-VERIFY header must
      independently ensure that it is not subject to tampering.

2.4  Canonicalization

   In order to minimize the possibility of signature breakage due to
   message or header rewriting while passing through the mail system,

Fenton & Thomas        Expires November 30, 2004                [Page 8]

Internet-Draft          Identified Internet Mail               June 2004

   mail agents which apply an Identified Mail signature MUST take steps
   to ensure that the message is in a canonical form prior to signing
   the message.  Messages containing only 7-bit characters and lines of
   78 characters or less MAY be sent without conversion.

   Messages which do not meet both of these requirements MUST be
   converted to MIME format, and the resulting MIME body is constrained
   to 7 bits -- that is, the use of material requiring either 8bit or
   binary transfer-encoding is NOT allowed.  Such 8bit or binary
   material MUST be encoded using either the quoted-printable or base64

2.5  Use of From header

   Identified Mail associates the key in the message with the
   Envelope-from address of the message.  This is done to allow mailing
   lists which re-originate messages with their own envelope-from
   address (but retain the original sender's address) to sign the
   re-originated messages.  However, it is the From address that is most
   commonly seen by the recipient, and it is important that it not be
   inconsistent with the Envelope-From address.

   In order to retain the current semantics and visibility of the From
   header, verifying mail agents SHOULD rewrite the From header if the
   From address is not the same as the Envelope-from address, by
   appending "via" and the Envelope-from address to the From header.
   For example:

   From: fenton@cisco.com via asrg-admin@ietf.org

   This sort of address inconsistency is expected for mailing lists, but
   might be otherwise used to mislead the recipient, for example if a
   message supposedly from administration@your-bank.com had an
   envelope-from address of fraud@badguy.com.

   In order to prevent this rewriting of the From address from
   interfering with subsequent reverification of the message if the From
   header is signed, verifying MTAs MUST consider a From address which
   differs from the signature header by the addition of "via" and the
   envelope-from address to be valid.

Fenton & Thomas        Expires November 30, 2004                [Page 9]

Internet-Draft          Identified Internet Mail               June 2004

3.  Key Management

   In order for these signatures to be meaningful, a trusted database of
   public keys needs to be available to verify message signatures.  The
   PGP approach to this issue of trust is through the use of trusted
   introducers, where individual keys are signed by others that may be
   trusted by the user of the public key.  Due to the large amount of
   connectivity required in email and the (perhaps) lower standard of
   trust required to accept an email message rather than, for example,
   process a financial transaction, we present an alternative model

3.1  Key Registration

   In order to receive email messages, domains typically use one or more
   MX (mail exchanger) resource records to indicate to where mail for
   that domain should be directed.  Similarly, DNS resource records can
   be used to locate one or more hosts, referred to as Key Registration
   Servers (KRSes), which may be considered authoritative to verify the
   association of a key with an email addresses in the domain.  To
   locate the KRS, the verifying MTA/MUA queries DNS with the hostname
   part of the envelope-from email address (e.g., eng.example.com for

   The zone file for a given domain might contain records such as the

   example.com.   IN    MX    10      mail.example.com.
   example.com.   IN    MX    10      mail2.example.com.
   _krs._tcp.example.com. IN SRV 10 10 378 krs.example.com.
   _krs._tcp.example.com. IN SRV 10 10 378 krs2.example.com.

   Key registration servers confirm (or deny) the binding between the
   envelope-from email address used by the message and the key used to
   sign the message.  It does so by receiving a query containing the key
   fingerprint and the envelope-from email address.  It returns a
   numerical value based on the policy of the sending domain as to
   whether the key is authorized to be used in sending a message from
   the specified address.  One such policy might be as follows:
      +127: Key is recognized and acceptable for the given address
      0: Key is unrecognized
      -127: Key is known to have been compromised; do not accept it

   The outgoing MTA for a domain is most likely to perform rewriting, if
   any, of the envelope-from address of the message (for example, to
   remove an unnecessary subdomain).  Since the KRS and the outgoing MTA
   are usually under common administration, the KRS can be configured to
   respond appropriately to expected rewritings of the envelope-from

Fenton & Thomas        Expires November 30, 2004               [Page 10]

Internet-Draft          Identified Internet Mail               June 2004


   The following are some excerpts from a hypothetical KRS database:

   #Rating TTL    Address             Key Fingerprint
   100     86400  tom@eng.example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC
                                       # Tom's usual address
   100     86400  tom@example.com     073FDD7DD6D6EF6D1413FD7B3C577EFC
                                       # Rewriting of Tom's address
   100     86400  dick@example.com    91881749E520D8F53B0B91BBD8963D0D
                                       # Dick's PC
   100     86400  dick@example.com    549D8949351DDA4E7C961E0F58727795
                                       # Dick's PDA
   -100    864000 harry@example.com   8C8252070CA9ED401DD2EE2A7B31A8CF
                                       # Harry's stolen PC
   100     86400  harry@example.com   17E64AC44DD5F8891560919D3FC6EA52
                                       # Harry's new PC
   100     86400  harry@example.com   073FDD7DD6D6EF6D1413FD7B3C577EFC
                                       # Tom is Harry's adminstrative
                                       # assistant, so Harry allows Tom
                                       # to originate mail for him.
   100     604800 *@example.com       27985A61447CC8B514A82BFA4597174A
                                       # Outgoing MTA key.  MTA keys are
                                       # less likely to require rapid
                                    # revocation, hence the longer TTL.
   100     86400  nobody@example.com  *
                                        # Any key will work for this address
                                        # NOT RECOMMENDED!

   The ability to configure multiple key registration servers for a
   given domain is intended to provide a degree of fault-tolerance and
   distribution of the key-verification load.  The availability
   requirement for key registration servers is somewhat higher than for
   mail exchangers (and probably more comparable to that of domain name
   servers) because real-time access to the key registration servers is
   often required at the time an email message is received or relayed.
   Accordingly, each domain defining key registration servers SHOULD
   define at least two, and they SHOULD be located on different

   The key registration servers for a domain need to be kept in as close
   synchronization as possible.  In particular, any key revocations that
   take place MUST be reflected immediately in all key registration
   servers for the domain.

3.2  Key Verification

   Verification of public keys from key registration servers is

Fenton & Thomas        Expires November 30, 2004               [Page 11]

Internet-Draft          Identified Internet Mail               June 2004

   accomplished via a properly-formatted HTTP request.  A sample request
   might be formatted as follows:


   The fields in the query are as follows:
      name: The envelope_from of the incoming mail.
      keyfp: The public key fingerprint that was supplied in the
      X-IMAIL-SIG line.  The fingerprint is created as follows: create
      the binary representation of the RSA exponent and modulus and
      concatenate them as e|n.  Run this value through SHA1 over the
      full length and convert the first 12 bytes of the output of the
      SHA1 operation to base 64.  That is:

               base64 (TRUNC (SHA1 ((e|n)), 12)

      domain: The domain corresponding to the query to be performed.
      This is used primarily to allow a single KRS to support multiple
      domains, with each domain database being independently maintained.
      This value corresponds to the d: value in the signature being
      checked; it MUST be the same as or a superdomain of the
      envelope-from address of the message.
      service: The service for which the query is requested.  Currently
      the only valid service is "SMTP", though this may be expanded in
      the future.

   The KRS response is the IMAIL standard tag/value syntax with the
   following tags/values defined:
      s: status.  Follows the general convention of SMTP/HTTP status
      values (eg, 200, 300, 400, 500 semantics) with the following
      values defined:

      200: the lookup succeeded.
      201: the lookup succeeded, but the keyfp/name combination was not found
      500: any permanent failure.

      t: Time to live.  Responses SHOULD be cached on the receiver so as
      to reduce the query/response load back to the KRS.  Time to live
      is expressed in seconds from when the query was sent.
      r: Rating: like rating in the X-IMAIL-VERIFY, an integer between
      -127 and 127 which as the sole discretion of the entity producing
      the rating.  Normally, revoked keys from the home KRS would be
      given a (very) negative rating.
      m: Matches.  Some key fingerprints may in fact sign for more than
      the single address that is present in the query.  In order cut

Fenton & Thomas        Expires November 30, 2004               [Page 12]

Internet-Draft          Identified Internet Mail               June 2004

      down trips to the KRS, the Matches field describes with normal
      Unix wildcard syntax what envelope_from patterns match this key
      fingerprint.  For example:


      would inform the cache logic of the requestor that future queries
      from example.com with this key fingerprint be given the same
      rating and time to live.
      Note that while the syntax of the matching pattern uses normal
      unix wildcard syntax, the semantics of the wildcarding are
      actually constrained to be a "longest prefix match" algorithm
      where the prefix components are allowed to be either the left hand
      side of the envelope_from, or the successive subdomain components.
      In all cases, a matches value MUST NOT exceed the prefix of the
      envelope from.  That is, an entity from example.com cannot say
      that it matches *@*.com since it is not authorized to sign for the
      entire .com domain.
      c: Comment.  This is a free form string intended to convey a human
      readable comment about the operation.  This is typically used to
      send diagnostic information for failed operations, etc.
      v: Version of the responses.  Currently this MUST be set to "1".
      The value is expressed as an unsigned integer.

   The key registration servers must use a mechanism that ensures that
   only authorized users are able to deposit key fingerprints on the
   server and revoke them.  This may involve a mechanism such as an
   authenticated HTTP exchange that requires the user's password in
   order to register a public key fingerprint for that user on the

   It is implicit in this key management approach that only legitimate
   key-to-address bindings may be registered on the key registration

   In order to prevent harvesting of email addresses, KRSes MUST NOT
   respond with any email address other than that presented in the query
   or a more general address (for example, when the key fingerprint
   corresponds to a domain MTA).

3.3  Address ratings

   It is helpful, but probably not sufficient to confirm that a message
   was signed using a key authorized for the stated address.  This fact
   alone says nothing about the security of the originating domain's key
   registration servers, the method used to identify message senders
   prior to MTA message signing, and the overall character of the
   domain.  Senders of spam are free to register domains and set up key

Fenton & Thomas        Expires November 30, 2004               [Page 13]

Internet-Draft          Identified Internet Mail               June 2004

   registration servers for those domains.  Domains might also be set up
   with explicitly open key registration policies, to permit anonymous
   exchange of signed messages among groups of people.  In either case,
   mail from such domains might be less valued than from domains known
   to be reliable.

   The address rating service fulfills the need to distinguish domains
   with differing registration policies and/or user behavior.  The
   rating service is envisioned as a third-party service, somewhat
   analogous to a credit bureau, which the verifier of an identified
   mail message MAY use to obtain a relative evaluation of the sending
   address based on criteria established by the rating bureau.  Ratings
   will normally be granular to the domain of the sending address, but
   may also give information on individual addresses.

   A hypothetical ratings database might look something like this:

   90     responsible-isp.com   /* ISP with good security and policies */
   40     flaky-isp.com         /* ISP that isn't very responsive */
   80     tom@flaky-isp.com     /* Known good user at flaky ISP */
   0      spam-marketing.com    /* Known source of UCE */

   Entries in the ratings database should be returned on the basis of
   longest-match.  In the example above, the address "tom@flaky-isp.com"
   should return a rating of 80, not the value of 40 used for all other
   addresses in the domain.

Fenton & Thomas        Expires November 30, 2004               [Page 14]

Internet-Draft          Identified Internet Mail               June 2004

4.  Policy Options

   Identified Mail by itself introduces no new policy with respect to
   handling email.  However, the benefit of using Identified Mail lies
   with the widespread deployment of policy which encourages the signing
   of email and eventually marginalizes unsigned messages.

   One place where policy can be implemented is at the receiving user.
   The user can verify the signatures of messages as they are received,
   and place unsigned messages in a "bulk mail" or similar folder to be
   read (if at all) on a lower-priority basis.  This would typically be
   done through an enhancement to the mail user agent, probably at the
   time messages are downloaded via a protocol such as POP.  Since the
   user must contact the key registration servers for all keys not in
   the user's key cache, this could lengthen message downloading times,
   and may present a problem for transitory users such as those on
   dial-up lines.

   The service provider (or enterprise) has the option of adding a
   verification header to incoming messages.  This considerably
   simplifies things for the user, who can now use an existing mail user
   agent.  Most MUAs have the ability to filter messages based on
   message headers or content; these filters would be used to implement
   whatever policy the user wishes with respect to unsigned mail.

   The service provider itself can implement a policy with respect to
   unsigned mail, provided that the mail transfer agents have the
   ability to verify signatures (regardless of whether or not they apply
   the verification header to signed messages).  Separate policies may
   be defined for unsigned messages, messages with incorrect signatures,
   and in cases where the signature cannot be verified, for example if
   all the key registration servers are unreachable.

   In the course of receiving a message, the service provider can
   retrieve the public key of the sender from one of the designated
   keyservers or from a local cache, and check the signature on the
   message.  If policy dictates, the service provider might reject the
   message with an error such as:

   5yx Unsigned messages not accepted
   5uv Message signature incorrect

   If the key registration server is not available, a temporary failure
   message could be generated, such as:

   4yx Unable to verify signature - key registration server unavailable

   Policies of this sort naturally assume the widespread use of message

Fenton & Thomas        Expires November 30, 2004               [Page 15]

Internet-Draft          Identified Internet Mail               June 2004


Fenton & Thomas        Expires November 30, 2004               [Page 16]

Internet-Draft          Identified Internet Mail               June 2004

5.  Security Considerations

   Fundamentally, the addition of signatures to email messages is all
   about security, although not in the usual way of ensuring the secrecy
   of data.

5.1  Potential Attacks

   It has been observed that any mechanism that is introduced which
   attempts to stem the flow of spam is subject to intensive attack.
   Identified mail needs to be carefully scrutinized to identify
   potential attack vectors and the vulnerability to each.  Some of the
   attacks that have been considered are described in the following

5.1.1  Key Registration Server DoS Attack

   Since the key registration servers are distributed (potentially
   separate for each domain), the number of servers that would need to
   be attacked to defeat this mechanism on an Internet-wide basis is
   very large.  Nevertheless, key registration servers for individual
   domains could be attacked, impeding the verification of messages from
   that domain.  This is not significantly different from the ability of
   an attacker to deny service to the mail exchangers for a given
   domain, although it affects outgoing, not incoming, mail.

   A variation on this attack is that if a very large amount of mail
   were to be sent using spoofed addresses from a given domain, the key
   registration servers for that domain could be overwhelmed with
   requests.  However, given the low overhead of HTTP requests to the
   KRSes relative to handling of the email message itself, such an
   attack would be difficult to mount.

5.1.2  Key Registration Server Stall Tactic

   An attacker trying to "jam" the signature mechanism might set up a
   key registration server for a domain they control that responds very
   slowly or perhaps not at all.  They then send a large number of
   messages from that domain, in an attempt to bring the signature
   verification mechanism to a crawl and get domains to turn it off.
   This could be mitigated by the use of appropriate timeouts on key
   lookups and possibly by adapting these timeouts to message load.
   Note that it is considerably easier to mitigate this attack when the
   signature check is done by the terminating MTA than the MUA because
   of the MTA's ability to return a temporary failure when the key can't
   be retrieved.

Fenton & Thomas        Expires November 30, 2004               [Page 17]

Internet-Draft          Identified Internet Mail               June 2004

5.1.3  Misappropriated private key

   If the private key for a user is resident on their computer and is
   not protected by an appropriately secure passphrase, it is possible
   for malware to send mail as that user.  The malware would, however,
   not be able to spoof other senders' addresses, which would aid in
   identification of the infected user and would limit the possibilities
   for certain types of attacks involving socially-engineered messages.
   For example, the malware would not be able to pose as the Microsoft
   Windows Update distribution center.

   A larger problem occurs if malware on many users' computers obtains
   the private keys for those users and transmits them via a covert
   channel to a site where they may be shared.  The compromised users
   would likely not know of the misappropriation until they receive
   "bounce" messages from messages they are supposed to have sent.  Many
   users may not understand the significance of these bounce messages
   and would not take action.

   One countermeasure is to use a passphrase, although users tend to
   choose weak passphrases.  Nevertheless, the decoded private key might
   be briefly available to compromise by malware when it is entered, or
   might be discovered via keystroke logging.  The added complexity of
   entering a passphrase each time one sends a message would also tend
   to discourage the use of a secure passphrase.

   A somewhat more effective countermeasure is to send messages through
   an outgoing MTA that can authenticate the sender and will sign the
   message using its key which is normally authorized for all addresses
   in the domain.  Such an MTA can also apply controls on the volume of
   outgoing mail each user is permitted to originate in order to further
   limit the ability of malware to generate bulk email.

5.1.4  Message Replay Attack

   In this attack, a spammer sends a message to be spammed to an
   accomplice, which results in the message being signed by the
   originating MTA (presuming that the sender doesn't have a valid
   individual key for the domain).  The accomplice resends the message,
   including the original signature, to a large number of recipients,
   possibly by sending the message to many compromised machines that act
   as MTAs.  The messages, not having been modified by the accomplice,
   have valid signatures.

   Several techniques for dealing with this type of attack have been
   considered.  One is to include in the request to the KRS not only the
   fingerprint of the signing key but also a fingerprint of the
   signature which would allow the KRS to detect, and flag as

Fenton & Thomas        Expires November 30, 2004               [Page 18]

Internet-Draft          Identified Internet Mail               June 2004

   unauthorized, the use of the same signature a very large number of
   times.  This would require the KRS to maintain a cache of signature
   fingerprints, and would make caching of key registration data by
   verifying MTAs and MUAs impossible.  Both of these factors are very
   undesirable from a performance standpoint.  In addition, some
   checking of message date/time fields would need to be introduced in
   order to allow aging of the signature cache, where currently there is
   no assumption that the sender have a valid real-time clock.

   A similar approach is for verifying MTAs and MUAs to cache the
   signatures themselves and detect duplications.  However, only large
   recipient MTAs are likely to process enough of the spam messages in
   order to detect the duplications.  Furthermore, there are legitimate
   use cases involving mail forwarding where the same message might take
   different paths to the same MTA, so this can only be applied in cases
   where unexpectedly large numbers of duplicate signatures are

   Other partial solutions to this problem involve the use of rating
   services to convey the fact that the specific envelope-from address
   is being used for spam, and that messages from that sender are likely
   to be spam.  This requires a real-time detection mechanism (such as
   detection by the KRS as described above) in order to react quickly
   enough.  However, such measures might be prone to abuse, if for
   example an attacker resent a large number of messages received from a
   victim in order to make them appear to be a spammer.

5.2  Other Considerations

   At present, a message can be forwarded giving the sender no
   indication as to the recipient's actual location (IP address, domain,
   or eventual email address) on the Internet.  A sender monitoring
   queries to its KRS might be able to infer some of this when the
   recipient's MTA, or even the actual recipient, checks the
   identification of incoming messages.  In cases where this may be
   sensitive, trusted proxies SHOULD be employed by the recipient and/or
   their domain.

Fenton & Thomas        Expires November 30, 2004               [Page 19]

Internet-Draft          Identified Internet Mail               June 2004

6.  Acknowledgements

   Dave Rossetti provided much of the original motivation to address
   this problem.  In addition, thanks to Fred Baker, Mark Baugher,
   Patrik Faltstrom, Don Johnsen, Dave Oran, and Dan Wing for their
   suggestions and much helpful discussion around this issue.

Fenton & Thomas        Expires November 30, 2004               [Page 20]

Internet-Draft          Identified Internet Mail               June 2004

7.  References

7.1  Normative References

   [1]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

7.2  Informative References

Authors' Addresses

   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-24/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 526 5914
   EMail: fenton@cisco.com

   Michael Thomas
   Cisco Systems, Inc.
   MS SJ-21/3
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 525 5386
   EMail: mat@cisco.com

Fenton & Thomas        Expires November 30, 2004               [Page 21]

Internet-Draft          Identified Internet Mail               June 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Fenton & Thomas        Expires November 30, 2004               [Page 22]

Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/