[ietf-dkim] What's a replay?
dotis at mail-abuse.org
Tue Aug 9 15:21:44 PDT 2005
On Aug 9, 2005, at 1:23 PM, Dave Crocker wrote:
> On Mon, 08 Aug 2005 19:46:24 -0700, Douglas Otis wrote:
>> A replay would be both a valuable feature of DKIM
> I have no idea what this means.
> "a replay"?
> "a feature of dkim"?
Signed messages reintroduced from different servers with different
RCPT TO parameters.
The domain that introduced the signed message and provided the public
key used for verification.
An opaque identifier added by the accountable domain and used to
revoke the related account's authorization.
A set of domain labels at the accountable domain that return 'A'
resource records with the address value 127/8. These labels
correspond to revocation-identifiers which are no longer authorized.
DKIM's common feature:
DKIM authenticates the accountable domain while allowing the same
message to be reintroduced from different servers with different RCPT
TO parameters. This valuable feature supports forwarding, while, at
the same time, permits a mode where abusive messages may be
replicated and sent to an unlimited number of recipients. Abusive
messages could be considered those that are undesired and are
disproportionately in the sender's interest.
As a secondary feature, some wish to bind the Sender or From mailbox
domain with the accountable domain. This secondary feature requires
the optional application of domain-wide policy assertions.
Describing the binding of the Sender or From mailbox domain with the
accountable domain an "anti-phishing" measure would likely become
contentious. This is due to variations in what may be exposed to the
recipient, together with social engineering ploys that remain possible.
It would also be contentious to consider DKIM a means to assure the
local-part of a mailbox address. While there is a provision within
DKIM to specifically limit the validity of a key to that of a
specific local-part, such user-keys create other concerns with
respect to DNS suitability and possible misuse. The assurance of the
local-part also has similar problems related to defining what is
exposed to the recipient. Such full mailbox address verification
would also clearly overlap S/MIME as well.
Improving upon the common feature of DKIM:
Without reputation being considered, there is no method to control
abuse. Authentication of the accountable entity keeps reputation
information from being corrupted and causing onerous support issues.
The accountable domain provided by DKIM is extremely important with
respect to ensuring safe and fair reputation assessments. Without
reputation services however, there also has been general agreement an
authenticated accountable domain offers little on its own to reduce
abusive email. After all, abusers can easily sign their own
messages. Another concern arises from the fact that the normal means
to monitor and limit abusive accounts is seriously hampered by the
ability of signed messages to be replayed.
DKIM must consider optionally adding a revocation-identifier as a
means to defend larger domains who will need to deal with abusive
accounts on a regular basis. Without providing a means to control
abusive replay, a domain administrator would be unable to demonstrate
any cooperation in abating abuse issues as they are reported. The
revocation-identifier mechanism, as suggested, would permit a means
to terminate abuse as it happens, and even squelch messages that may
remain in transit.
Not solving the replay issue, and considering a greater value is
found by protecting the local-part in conjunction with the use of
user-keys raises serious questions as to the goal of DKIM. If this
is the case, then DKIM should be dropped and S/MIME's signature
methods should be modified instead.
More information about the ietf-dkim