Douglas Otis wrote: > 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. > I'm not sure how one tells that the key is delegated, nor why that is relevant to the verifier. > > >> 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. > I basically agree. It's a fine point, but what the email-address domain is actually doing is describing its practices, since it doesn't have any standing to approve anything for the verifier. > > >> 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. > As I mentioned above, I'm not sure how accurate it is to characterize the SSP record as an "affirmation" -- it's a description of what an email domain does. > > >> 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. > This is a good topic for discussion when we are discussing SSP itself, not the threats document. > > >> 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! > Again, this is more relevant to the design of SSP (or the wording of the -ssp document) than to the threats document. Hopefully my comments above explain my position.
-Jim _______________________________________________ ietf-dkim mailing list http://dkim.org
