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