[ietf-dkim] What's a replay?

[Douglas Otis]

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"?


Message Replay:

Signed messages reintroduced from different servers with different  
RCPT TO parameters.


Accountable Domain:

The domain that introduced the signed message and provided the public  
key used for verification.


Revocation-Identifier:

An opaque identifier added by the accountable domain and used to  
revoke the related account's authorization.


Bad-List:

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.


Potential mires:

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.

-Doug