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