ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-19 17:26:24

On Aug 19, 2005, at 12:42 PM, Earl Hood wrote:

On August 19, 2005 at 01:03, Douglas Otis wrote:


Is your view in a nutshell (of what DKIM should be):  When a domain
signs a message, it is saying, "Here is what I got and transmitted."
DKIM only provides a verifiable trace of a message.


The signature indicates a specific message has been transmitted by a
specific administrative domain, to be held accountable for the access
thereby granted.  Additional properties must be premised upon the
governance demonstrated by the accountable domain.


Okay, but I am having some trouble in how accountable a domain will be.
Mail transmission is not necessarily point-to-point, with a message
potentially going through multiple domains before reaching its
final destination.  When a domain signs a message, what level
of accountability is the domain stating?  Can there be different
levels depending on the role the domain plays in the transmission of
the message?


Different levels seem to suggest shifting accountability to coincident mailbox-domains, or even listed mailbox-domains, when accountability is not fully attributed to the signing domain. Mailbox-domain selection and related permission structures will prove disruptive and problematic. In effect, mail will simply not function properly, while creating significant risk depending upon how accountability is dispersed within a multi-level scheme. Simple non- header assertions are possible where DKIM ignores the mailbox-address entirely.

There should, and can, be a single level of accountability for the domain. This single level can only be achieved when the domain is able to control abusive message replay. For example, a revocation mechanism could be based upon an opaque identifier added by the signing domain. Signatures provide value to such an identifier, that without the signature, such an identifier would have much less worth. Unlike a mailbox-address, an opaque identifier can be assured to uniquely reflect the source. The need to query the revocation mechanism may be mitigated by HELO being within the domain of the signature, or perhaps even a RCPT TO list captured as a hash. When the message appears outside the administrative control of the signing domain, a lookup would occur to determine whether an 'A' record was published revoking the authorization for the specific opaque identifier.

Such a mechanism would permit the accountable domain to _always_ be able to squelch on-going abuse, irrespective of subsequent servers. In effect, by virtue of the revocation mechanism, the domain _can_ be held accountable for any abuse allowed to continue once reported. The revocation mechanism would also provide feed-back to reporting agents that corrective actions were or were not taken by the accountable domain.

With ubiquitous presence of zombie systems, a strategy must be in place to cope with this situation. The opaque identifier would permit a reduction in expensive correlation efforts needed for assessing abuse, and simplify locating relevant logs when confirming sources. This would greatly facilitate the effective relationships between reporting services and email providers who normally wish to retain favorable treatment by recipients.

So to answer your question, once the domain signs the message, it becomes _fully_ accountable for taking corrective action should the signed messages later prove abusive. This would not expect a domain to be able to fully assure the behavior of those granted access. However, these domains should take swift actions in response to reported abuse. The rate of corrective actions should be balanced against the size of the domain, but should this become excessive from that perspective, changes in their operation may be required.



Yes.  The "originating domain" is the first domain to handle the
message.  The sender of the message obtained authorization from the
originating domain to transmit the message.

Since you mention accountability, I believe there should be a different
level of accountability from the originating domain from subsequent
domains that may handle a message during transit.


By authenticating the HELO, name based reputation could substantially replace IP address based reputations. Even so, there will be either a HELO or IP address level of defense guarding against DoS attack, where the last hop always remains evaluated. When DKIM becomes widely deployed, tolerance at the last hop may improve, as DKIM plays a greater role with it being much closer to the source, and therefore more effective at controlling abuse.


When the initial domain signs a message, it is saying, "Here is what
the domain-authorized sender submitted to me for
transmission."


Again, I don't understand what is implied by "domain-authorized sender." Is this suggesting a provider must query the domain in a mailbox- address for a specific "sender" authorization prior to transmitting the message?


I am talking about the relationship between the domain and the mailbox
users it services.  For a mailbox user to send out a message (through
the given domain), the domain must grant permission for the mailbox
user to do this.  Therefore, the sender is "domain-authorized" to
send messages originating from the given domain.

Correlating mailbox-address, user accounts, and email providers offers complexity that nonetheless may not resolve to single source or entity. The ability to resolve down to the problem is not assured with an email address:
 - multiple accounts could use the same email address
 - email address could be used with multiple providers

Defensive strategies must find a different identifier assured by the domain as a unique basis for locating trouble. This is simply being pragmatic, but this new identifier will not impact the way email operates, as would adding constraints on the mailbox-domains. MASS should adhere to an oath that above all, do no harm to remove all excuses. : )

-Doug





_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>