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:
[EMAIL PROTECTED]
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-
DKIM Base:
,---
|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:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
etc.
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.
[EMAIL PROTECTED]
instead of
[EMAIL PROTECTED]
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-
[EMAIL PROTECTED]
is now really the same person at
[EMAIL PROTECTED]
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
circumstances:
"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:
d=example.com
s=summer._safe
summer._safe._domainkey.example.com key
s=winter._safe
winter._safe._domainkey.example.com key
s=fall._promo
fall._promo._domainkey.example.com key
s=spring._employee
spring._employee._domainkey.example.com key
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-
address.
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.
No.
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
