[ietf-dkim] What's a replay?

[Douglas Otis]

On Aug 11, 2005, at 7:59 AM, Paul Maddox wrote:
>
> Douglas Otis, wrote:
>
>
>> The concern is rather simple.  DKIM as it currently stands, only
>> offers per-user-keys as a possible solution to control replay abuse.
>>
>
> I'm having trouble seeing the threat with replay..  Can someone help
> differentiate these two scenarios:
>
> 1. Replay
> 2. Sending mail from that domain from within the organisation (Eg. An
> employee sending thousands of emails through Outlook)
>
> Is the replayer and rogue employee the only problem in both cases?

Any message initially being signed would not be a "message replay".   
Rogue accounts or employees could send themselves messages, perhaps  
to different accounts, which can then be used to stage "message  
replay."  The motivations for doing so would be to avoid normal  
controls available to the "accountable domain."

>
> If DKIM is supposed to make domain owners responsible for the email  
> from
> that domain, should it not be the domain owner preventing replay/ 
> abuse,
> not DKIM?

Yes, indeed.  But the current design of DKIM only provides this level  
of control when separate keys are used for each account where the  
keys also remain held in cache for only a short duration.  This will  
create inordinate DNS burdens.  However, there can be another  
solution that imposes much less load on DNS.

------------
Let me define the terms I will be using again.

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 optionally 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.  Only those labels  
that correspond to revocation-identifiers which are no longer  
authorized, would be published by the domain.  Lookups against  
authorized revocation-identifiers do not return a record.

--------

While DKIM may provide relatively strong authentication of an  
"accountable domain", an inherent feature of a signature permits  
"message relay."  This "message replay" feature makes it difficult to  
hold the domain signing the message actually accountable for ongoing  
abuse.  Without an ability to apply assertions of accountability,  
reputations based upon the "accountable domain" would be meaningless.  
Potentially huge amounts of abuse must be excused due to a normal  
inability of the "accountable domain" to control "message replay."

This will cause any protective mechanism initially intended to be  
based upon the "accountable domain" to instead revert back to the IP  
address.  DKIM offers the possibility of establishing name based  
reputation as a means to prevent collateral damage caused by shared  
IP address space, but without a mechanism to deal with "message  
replay," this advantage is lost.

Not all "message replay" is bad.  Indeed there are times when  
"message replay" is desired, such as when there is a list of  
recipients, or a recipient is using a forwarding account.  One could  
argue mailings lists should adopt a practice of using "message  
replay" instead of applying new domain signatures to provide those on  
the list an assurance of the initial "accountable domain" for the  
message.

Holding the "accountable domain" accountable demands a mechanism  
where this "accountable domain" can prevent "message replay" when  
reports are received with evidence of abuse.  For those within a  
large domain or where users are not always within a protected  
network, it would be prudent to add a mark, a "revocation- 
identifier," that indicates which account was used to gain access to  
the email system.

I am advocating making this already common practice in such  
situations, an optional convention within DKIM.  In addition, I am  
advocating another convention that allows those domains that adopt  
the "revocation-identifier" convention, a means to retract  
authorization based upon the "revocation-identifier."  The  
"accountable domain" would publish "bad-list" records for "revocation- 
identifiers" associated with accounts terminated due to reports of  
abuse.

This would allow only a few DKIM keys be used for the entire domain.   
It would also allow a reasonable duration within the DNS cache where  
this would be less likely to create undue burdens upon the DNS  
infrastructure.


-----
(Poor attempt as devils advocate.)

Those looking for justification for DKIM without there being a means  
to control "message replay" tend to suggest the following:

1) Acceptance will be predicated upon a white-list that is-
    a) Comprised of both the local-part and the signing domain
       (assumes local-part is normally constrained by domain).
    b) Comprised of user-keys.
    c) Comprised of the signing domain
       (ignores message replay abuse and likely fails).

If DKIM becomes a new way to sign a message with user-keys, then due  
to the lack of suitability of user-keys for email within DNS, S/MIME  
should be modified instead where key servers are already employed.   
After all, user-keys enable message encryption only understood by the  
recipient, and this is already accommodated in S/MIME. User-keys  
would provide assurances to both the author and recipient of both  
identity and privacy.

With market advantages for user-keys, is it safe to start a practice  
of publishing user-keys in DNS?  Would calling DKIM a domain key with  
a "limited" use of user-keys really be just a guise to really provide  
everyone user-keys, when there is no other mechanism to control  
message replay abuse?
---

DKIM can be a tremendous asset to email, provided it allows a  
response to message replay abuse.  Key abuse should also be  
prohibited by way of design.  This means user-keys, at any level,  
should not be used.  The justification for employing user-keys fall  
flat when assessed against a goal of ensuring reputation protection  
for the _domain_.  The domain would be far better protected with a  
practice that constrains less trustworthy keys to sub-domains.  By  
establishing policies able to constrain "third-party" signing to sub- 
domains, the reputation of the domain is far far better protected.

The debate about whether keys should constrain the local-part place  
great value in the protection of the local-part, but then completely  
dismiss the lack of protection for the domain's reputation.   
Constraining the local-part of a message offers only token  
protections that a key will not be abused.  Third-party signatures  
will become common practice, and recipients will be aware which DKIM  
verified domain they are actually trusting.  DKIM message should make  
people keenly aware the entire message's content (everything) is  
fully dependent upon the constraints established by the domain.   
DKIM's only role is to assure the recipient of just the domain.

Recipients are trusting the authentications required to access the  
specific domain.  The level authentication varies widely.  Should  
mobile-users.acme.com gain a bad reputation due to a lapse of  
attention (perhaps a Trojan in a salesperson's notebook), then  
acme.com's reputation still permits normal commerce.  The salesperson  
could still use their email address at acme.com's offices.  The  
mobile key should be used as a third-party sub-domain signature.

The goal for DKIM should be to protect the domain's reputation.  DKIM  
provides for safe name based reputations and eliminates IP address  
space collateral damage and related IP address weaknesses.  The  
significant remaining threat is message replay abuse.

-Doug