I'll stick t o inline comments at the risk of this getting confusing.
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Tuesday, January 06, 2009 8:20 PM
To: MH Michael Hammer (5304)
Cc: John L; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
Hi, Mike...comments inline:
MH Michael Hammer (5304) wrote:
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Tuesday, January 06, 2009 6:10 PM
To: MH Michael Hammer (5304)
Cc: John L; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
It really applies to the implementation of the checker, and not to
the
publication of ADSP records.
At the risk of repeating myself, here's an example of when it's
important. Suppose the ietf.org mailing list manager signs its
mail
using i=ietf(_at_)ietf(_dot_)org(_dot_) The IETF Chair sends a message to
the list,
using From: <chair(_at_)ietf(_dot_)org>. I contend it would be bad for the
mailing
list manager signature to be confused with an author signature.
But in terms of the receiving domain checking, why would they make a
distinction from an ADSP perspective? The question at hand is
whether
all email from a particular (sub) domain is signed. If a domain is
making this type of assertion, then it is looking at ietf.org and
shouldn't really care whether the user is chair@ or ietf(_at_)(_dot_) If you
are
asserting that one might be signed and the other not then I think
there
is an issue. If you assert that both are signed but the signatures
might
be different (within the same domain but with different selectors
for
example then I'm going to say fine because if ietf.org asserts it
signs
all mail then it still works. It is the domain that is important,
not
the user part for the all assertion.
Suppose that ietf.org asserts an ADSP record but doesn't require
signatures on incoming messages, even from its own domain (there's no
requirement that they do). Someone spoofs a message from
chair(_at_)ietf(_dot_)org, which is of course unsigned. The message coming
out
of
the list looks like it has an author signature. I have a problem with
that.
If ietf.org is willing to put it's signature on the spoof message I
would assert that it has a DKIM problem more than an ADSP problem.
Either the message has a valid signature or it does not. If there is a
valid signature then ietf.org is claiming responsibility. If it doesn't
have a valid signature....then not so much. If ietf.org is sending out
spoofed messages spoofing a "from" then it has a problem regardless of
whether it DKIM signs, uses ADSP or does anything else..
In this situation, we could require that the mailing list manager not
apply a signature if it might be confused with an author signature,
but
then there's no way for it to apply a signature representing the list.
Then perhaps ietf.org should reconsider whether or how it DKIM signs,
whether it is a suitable candidate for ADSP and how it manages it's
lists.
By DKIM signing ietf.org is claiming responsibility for the mail - good
bad or indifferent. If it fixes the problem quickly and otherwise it has
a good reputation then it maintains it's reputation. If it consistently
signs problem mail then it may lose it's reputation.
This example involves the use of local-parts, but one could also
come
up
with (somewhat more contrived) examples where the mailing list
manager
is at lists.example.com and some users are at users.example.com.
If
the
keys are published in the example.com domain (d=example.com) and i=
isn't being used, it isn't possible to distinguish author
signatures
and
list signatures.
Distinguish to what purpose Jim?
Either they are signed or they aren't signed from an ADSP
perspective.
If distinguishing at this granularity is important then publish ADSP
for
lists.example.com/DKIM sign for that domain (d=) and publish ADSP
for
users.example.com/DKIM sign for that domain (d=). The author
signatures
are clearly distinguished from the list signatures.
But they are all domain signatures. If you go back and look at the
discussion that took place before I suggested the name Author Domain
Signing Policy, I pointed out that authors don't sign, domains do
(unless an author also has control of DNS for a domain).
The d=/i= distinction was originally created to simplify key
management
by domains having many subdomains, in that they could publish the keys
in a parent domain (d=) while signing for a subdomain (i=). You're
basically suggesting that we abandon that optimization so that we can
use the d= domain rather than the i= domain for ADSP.
I'm too tired to wade back through the list to find the discussion that
included statements from receivers that for the most part the finer
granularity desired by some senders was not necessarily useful from the
receiver perspective. I'm not going to argue with receivers. I sign
email with DKIM because it helps them identify legitimate mail from our
domains vs the spoofed mail. For my use case I try to keep it as simple
as possible.
Other than hypotheticals I haven't heard any implementers on the sending
side indicating this is an issue. I can only speak from my experience
which is 5 domains with roughly 750 million signed emails in the past
year.
Remember that the lookup address for ADSP is always the domain of the
From address (users.example.com) and not the d=domain. In this
situation ADSP records for lists.example.com and for example.com would
never be referenced.
d=users.example.com
d=lists.example.com
You look at the lack of optimization. I look at where you are going and
wonder why someone with lots of subdomains is going to turn to ADSP in
the first place.
I sign for sub.sub.sub.domain.com but I don't sign for
sub.sub.domain.com but I sign for sub.domain.com but I don't want to
publish ADSP for this.
I sign and I want to publish ADSP discardable for
sub.sub.sub.domain.com. I think I know where and how I send email but
I'm not really sure. Right. This is not an organization that is a
suitable candidate for publishing ADSP.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html