[ietf-dkim] Keys vs. Reputation
dotis at mail-abuse.org
Mon Aug 21 19:04:22 PDT 2006
On Aug 21, 2006, at 5:19 PM, Dave Crocker wrote:
>>> It seems too early to know how key selectors might be used,
> No it doesn't.
> A selector adds one level of name granularity. So does a regular
> sub-domain name.
> If the purpose of an extra level of granularity is semantic, then
> it belongs in the actual name. That is, it belongs in the d= string.
There are likely practical considerations that will affect the
general application of this rule.
Big-Bank.com has a few thousand email-addresses assigned to employees
and specialized services all under their parent domain of:
local-part at Big-Bank.com
Now Big-Bank.com is told this must change to conform to a "semantic"
requirement of someone's reputation system using the d= parameter
within the DKIM signature header. : (
A major advantage offered by DKIM was-
|o the message signature is written as a message header field so that
| neither human recipients nor existing MUA (Mail User Agent)
| software are confused by signature-related content appearing in
| the message body,
The added security afforded by DKIM was absolutely transparent. That
goal must now be abandoned to support a semantic for a reputation
service that changes the email-addresses being used?
When Big-Bank.com is coerced into using subdomains to partition their
messages, their customers will see more complex domain names within
the email-addresses and might become confused by what they see.
Perhaps this might be subdomains like:
local-part at Employees.Big-Bank.com
local-part at Services.Big-Bank.com
local-part at New-Accounts.Big-Bank.com
local-part at Promotion.Big-Bank.com
local-part at Western-Region.Ads.Big-Bank.com
A profusion of subdomains along with the extra text now must be
carefully examined. This added profusion will likely make Big-
Bank.com an easier phishing target. Will Big-Bank.com's customers
know the difference between a '.' and some other character used in a
domain name? Things like the following may go unnoticed. Poor grandma.
local-part at New-Accounts-Big-Bank.com
local-part at Big-Bank.com
> The construct of selector is for a different purpose. It is an
> administrative construct, not a semantic one.
True. The key selector is allowed to use multiple labels. One of
these labels could be dedicated to the purpose of segregating the
domain without affecting the critical appearance of their email-
address, or requiring everyone to understand that-
Tom.Jones at Big-Bank.com
is now really the same person at
Tom.Jones at New-Accounts.Big-Bank.com
When people already recognize an email-address, changing the email-
address will not improve a recipient's trust with respect to who is
now sending them messages.
>>> Selectors might be used to partition the domain's messages.
> It has been a while since I have quoted my favorite system's
> engineer. His expertise in considering trade-offs has often been
> undervalued, so I tend to make a point of crediting him in these
> "We could do it, but it would be wrong."
> -- R. Nixon; WG Tapes.
“You see things; and you say, 'Why?'
But I dream things that never were; and I say, 'Why not?'
-- George Bernard Shaw
> If you want to partition among messages -- and by this, I assume
> that what was actually meant was to label messages in logically
> different bins, for the purpose of permitting differential
> assessments (reputations) -- then that is what sub-domains are for,
> in the d= parameter.
The d= parameter remains unseen in the DKIM header, which is good.
For the sake of a reputation assessment, this changes the
appearance of the address, which is not good.
> Let me stress a basic point:
> The instant that a selector is used semantically, it becomes
> worthless for its primary purpose, namely support of multiple
> keys for the same d= domain name.
This basic point is very wrong. The s= parameter already supports
multiple labels. Only _one_ label is needed to enable multiple keys
for the same d= domain. For example:
These are examples where the email-address is allowed to remain
unchanged, multiple keys are provided for the same domain, and yet
separate reputation assessments remain possible. Here are examples
of three categories of messages _safe, _promo, and _employee. The
base domain is likely well recognized as their trademark. Flooding
this domain name with subdomains reduces the clarity of the email-
>> Not all users within a domain are equally trustworthy.
> Quite true. And if the signer wants to distinguish among "users"
> by having different signatures, then use different d= sub-domains.
Which subdomain or domain is more trustworthy? Your scheme demands
email-addresses be modified to comply with a reputation scheme. Why
not have the reputation scheme achieve the same goal as that of DKIM
and remain transparent? DKIM will require annotation to convey the
signature results, reputation can be included within this
annotation. The address does not need to change.
>>> This trust may be partitioned by using the 2822.From local-part,
>>> different selectors, or perhaps an r= parameter.
If DKIM does not offer a means to assure the validity of the
2822.From address, then DKIM will have missed an important goal.
Knowing who you are communicating with is an extremely important
aspect of trust. This trust is not improved by changing the email-
addresses being used.
More information about the ietf-dkim