An offline discussion with Steve Atkins has been helpful in highlighting a two
distinctions in function and implementation design that the group should
consider. He pressed quite hard, for some of what follows, but I won't claim
that I'm speaking on his behalf; I just want to make sure it's clear that I
didn't "invent" any of this:
1. Internal vs. External
The difference between recruiting the recipient to enforce origin-side
policies concerning origin-side participants, versus enabling the recipient to
detect misbehaviors by actors external to the origin-side.
I think a simple and appropriate model, here, is that the receive-side
should be given information that permits it to detect external attacks -- that
is, misbehaviors by actors external to the origin-side.
The receive-side should *not* be recruited to enforce policies pertaining
to participants within the origin-side environment. The latter is strictly
the job of the origin-side organization.
2. Practice vs. Publication
Classically, this is the "what vs. how" distinction.
What is the information that the 'sender' or signer wants to communicate
to the receiver? Distinct from this is the means by which it is communicated.
The two obvious choices for communicating anything involving DKIM are:
a) DNS publication, versus
b) inclusion in the signed message, either as an enhancement to an
existing header field, or as a new field.
Of course each of these has notable benefits and limitations
DNS queries have particular performance characteristics, concerning cost,
reliability and latency. Its major benefit is that it is an out-of-band
channel. Where that is essential -- such as communicating information that
can be applied to unsigned messages -- then it is what should be used.
However if the information is from a signer -- and it does not somehow
require independent trust, such as obtaining it from a third-party service --
then it can be included in the message.
Steve pointed out to me that a basic challenge, here, is that DKIM does
not define a signature as meaning that the signer is asserting the
truthfulness of any particular bit of information in the message. That's the
inherent difference between the mild "taking responsibility" semantics that we
have given to a DKIM signature, versus "asserting correctness" or the like.
My suggestion to deal with this is to define the basic DKIM sematnic that
all DKIM-* headers are asserted to be valid, if they are included in the
signature.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html