[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

[Jim Fenton]

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