[ietf-dkim] 5 outstanding issues with the threat review
dotis at mail-abuse.org
Wed Mar 15 10:07:51 PST 2006
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.
More information about the ietf-dkim