One document matched: draft-fenton-identified-mail-00.txt
Network Working Group J. Fenton
Internet-Draft M. Thomas
Expires: November 30, 2004 Cisco Systems, Inc.
June 1, 2004
Identified Internet Mail
draft-fenton-identified-mail-00
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.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
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
verified.
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==";
n:"pZORwkeEetQnTVC7tw5MIE+31ROt/sGv5q+dxuwUIIqu5XKSva4P1/anPgIiz"
"7K8V0MaRDwDjKIuYYGaUO5IdDNfE7WEKe+/r8k3D0lrkNCa8qNPDSKljocN6y"
"d7Wjmx/Hk+tquACcpwhhDyVxzIBcj/A5aCApbeFeRkVvfFH70=";
s:"T3iRhynnuKx8+UNBuxMnDCIFet8RTM+VAs+STKM4P9ZqiEaUmG1rXmeXq3T+8"
"0oHhWtztZob/2twTxiqzgMD5MnFOTaqujJUBOmkIf1VR+ELzKq/vPZ+GmWs+h"
"mtSg3sH7jWrnvYHQpT6yey9TumnJVAdWepPl4budT9GFdpRuw=";
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
encoded.
h: Signing host. This is purely informational and is not used by
IMail.
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
encoded.
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
encodings.
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
here.
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
tom@eng.example.com).
The zone file for a given domain might contain records such as the
following:
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
address.
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
networks.
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:
http://krs2.example.com:378?domain=example.com
&name="john@example.com"
&keyfp="27985A61447CC8B514A82BFA4597174A"
&service="SMTP"
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:
m:"*@example.com"
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
server.
It is implicit in this key management approach that only legitimate
key-to-address bindings may be registered on the key registration
servers.
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
signatures.
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
sections.
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
received.
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
US
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
US
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fenton & Thomas Expires November 30, 2004 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-22 23:00:38 |