[ietf-dkim] 5 outstanding issues with the threat review

[Douglas Otis]

On Mar 15, 2006, at 6:06 AM, Barry Leiba wrote:

>>> Providers offering low cost or free services will not be able to  
>>> adequately vet their many users, who often number in the  
>>> millions.  This same provider may wish to send messages from the  
>>> same domain and have these messages receive a trustworthy  
>>> evaluation.  Perhaps these would be messages from a system  
>>> administrator indicating that the user's system appears  
>>> compromised or that their payment information is no longer  
>>> valid.  The use of trusted/non-trusted keys would permit the  
>>> signing domain to both retain their trustworthy status and  
>>> prevent un-vetted users within the same domain from spoofing with  
>>> "trusted" messages.
>>>
>> That's largely sales talk and I can't see any valid issue applying  
>> to the threats draft. Another expedient assessment.
>
> It's definitely not relevant to the threats doc, but I do think it  
> could be a useful discussion to have about the base doc.

The threat is to the trust value afforded by a DKIM signature.   
Creating sub-domains to isolate messages with different levels of  
trust is hazardous as this _will_ confuse many users.  Which domain  
should be trusted and which should be evaluated?  Don't forget many  
users also don't know the difference between "." and "-".  A  
proliferation in the use of sub-domains threatens the trust one may  
have in the message, as this expects the user to make assumptions  
about the delegation of domain zones.  This of course is a problem  
shared by the 'i=' construct in the signature header field.

> We've suggested that domains that want to divide their reputation  
> create subdomains (the sort of thing like  
> "official.bigbank.example" vs "users.bigbank.example"), but for  
> various reasons not all domains want to do that.  It would be a  
> reasonable discussion to have if one wanted to propose a tag in the  
> key that defined the level of "officialness" or "trust" or some  
> such that the signing domain places on the use of this key.  That  
> allows the domain to use selectors, rather than subdomains, to make  
> this division.

Explaining the threat to establishing trust still seems to belong in  
a threat document.  Details of a solution belongs in the base document.

-Doug