On Thu, 2006-01-12 at 16:49 -0800, Jim Fenton wrote:
Stephen Farrell wrote:
I don't think the term authorization is being properly applied
there. To me at least authorization is what's happening when
a policy enforcement point uses a policy decision point to get
a yes/no answer about some requested action.
I agree with Stephen; my disagreements over the use of the term
"authorization" for this are:
Let's compare DKIM without SSP with DKIM+SSP. DKIM-base makes a
positive statement about messages that are signed. Not that they're
"good" messages, but that the signing domain actually signed them. If
the signature address matches some other header in the message, it's
claiming that it had that role -- sender, resender or "from" (presumably
the originator of the message).
The signature itself proclaims the role of being accountable for the
message. A signing-domain matching the domain of some email-address
does not mean the signing-domain has verified permissions for the email-
address. In addition, the 'i=' parameter does not need to exist or
match any email-address. When the 'i=' parameter does match some
address, reliance upon this parameter must be conditioned upon whether
the key is delegated, and whether the header is included within the
signature.
SSP adds the ability to provide some advice on what to do about unsigned
messages.
It doesn't authorize anything -- depending on the policy, it
may determine that certain messages are "suspicious". It never makes a
positive assertion. A "signs some" policy is the same as not having SSP
at all; the other policies are more restrictive.
This is really a matter of semantics. The glass half full or empty, or
in this case, affirmed acceptable (authorized) or not.
When the signing-domain matches the email-address domain, the SSP record
plays no role. The SSP record may affirm that the message is still
acceptable when the email-address domain owner approves the lack of
signatures or the signatures of foreign domains.
The threats here go something like this:
1. Attacker finds a domain that publishes a "signs some" policy (or
doesn't publish a policy at all, since this is the default, currently at
least). Attacker spoofs these addresses, since it isn't possible for
the recipient to know whether they should have been signed. This attack
exists whether or not SSP exists.
A default for when the record does not exist still does not change the
affirmation that a lack of signatures or foreign signatures are
acceptable. Unfortunately, because this record may also remove the
affirmation, there is some risk to email-address domain owner of being
inappropriately held accountable, as affirmation may permit possible
abuse by third-parties.
2. Attacker finds a domain that publishes a "-" policy (allows
signatures from other domains). Attacker registers a disposable domain
and signs messages "from" the found domain using the disposable domain.
Attacker may even add headers pretending that the disposable domain is a
mailing list or similar role. The messages will appear to be legitimate
to the verifier, unless the verifier uses a reputation system (either
local or shared) to determine that the signing domain does this sort of
thing.
It is rather meaningless to offer such policy distinction. A bad actor
can sign messages. If the message goes through a mediator, the
signature could be damaged and thus considered to not exist. This
policy makes little sense.
3. Attacker registers a bunch of domains to do attack #2. This is more
of an attack on the reputation system than on DKIM itself.
So, to summarize, SSP only makes negative assertions: it calls certain
messages "suspicious". Calling it an authorization system distorts its
role.
DKIM can not instantly proclaim all messages must be signed by a
matching domain. Of course this mechanism could be viewed as _only_
offering "must be signed by a matching domain" proclamation. If that
were true, there would be much less concern about the possible misuse of
this record. However, this record can also proclaim and affirm that the
lack of a signature or a foreign signature is completely and absolutely
acceptable!
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org