| 
 
 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>
 |  
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP	record does not exist?, (continued)
 
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?, Earl Hood
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?, Earl Hood
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?, Earl Hood
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does	not exist?,
Douglas Otis <=
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Scott Kitterman
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Scott Kitterman
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Scott Kitterman
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Scott Kitterman
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does	not exist?, Douglas Otis
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does not exist?, Scott Kitterman
 - Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record	does not exist?, Douglas Otis
 
 
 |  
  
 | 
 
 
 |