ietf-dkim
[Top] [All Lists]

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

2006-03-15 11:23:15

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

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html