[ietf-dkim] Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP)

[Jim Fenton]

Douglas Otis wrote:

> This chart also needs to be updated...

I'm trying not to have the SSP design discussion yet.  While I like the
chart in general, I'm not sure I agree with all of the entries in it
either.  I don't think it's necessary to correct it in order to have the
threat analysis discussion.

>
>
>> It's true that there is no reporting address associated with the 
>> signer (there is the n= (notes) field in the key record, but no 
>> guidance about putting a reporting address there).  That is perhaps 
>> something that should be added; do you think it belongs in the key 
>> record or in the signature itself?'
>
>
> Perhaps it would make sense to establish a convention, DKIM-
> POSTMASTER@ perhaps.  If this seems too rigid, perhaps an entry in 
> the key, but this makes the key even larger.  Adding the reporting 
> address within the header could be problematic for delegated keys.

Good point here:  If it's important that the domain owner control the
reporting address so that the user of a delegated key can't specify any
reporting address they want, then it needs to be in the key record
rather than the signature.  But let's defer that decision until we're
actively discussing the -base document.  I have asked that this be
tracked as an open issue so that we don't forget.

>
>> With respect to the replay issue, I only want to point out that  DKIM
>> does not need to operate in a vacuum.  I do not want to tie it  to
>> any other message authentication technology.
>
>
> Keep in mind there is a header selection conflict between DKIM and 
> Sender-ID.  The conclusion reached more than a year ago, "open-ended" 
> authorizations are worthless.  As the only safe policy to publish is 
> "closed," this suggests the PRA algorithm should be re-examined, 
> especially if Sender-ID is considered a means to offer replay 
> protections.  There is also an alternative to the authorization 
> scheme that offers better protections.  CSV and In-Channel checks 
> could be yet another alternative for message replay abuse.  Leave the 
> email-address domain owner harmless.  Only the administrator knows 
> who is using the email-address.

Let's have this discussion when we're actively discussing SSP.

>
>
>> The "hapless" email-address domain owner has the option of not 
>> publishing a contact address (r= in the SSP is optional).
>
>
> But the hapless email-address domain owner can not control those 
> administrators willing to equivocate about source identifiers.   The 
> 'r=' suggests this is the entity that is seen as accountable.  Not 
> publishing the SSP record offers more protection than not publishing 
> an 'r=' parameter.

There are no semantics defined for the r= tag; it is just a "reporting
address" and might not even be a person, so I wouldn't call it accountable.

>
>>> "DKIM is effective in mitigating against the use of addresses not 
>>> controlled by bad actors,..."
>>
>
> This is the portion of the statement that is highly misleading.  DKIM 
> is not effective at mitigating the use of addresses not controlled by 
> bad actors unless a "closed" authorization is used such as '!' or 
> '.'.   A clarification that a "closed" authorization is not 
> compatible with many common uses of email would also ensure that 
> someone reading this would not be dramatically mislead.

I guess it depends on what you consider to be a "mitigation".  Note that
it does not say that it prevents the use.

-Jim