Dave Crocker wrote:
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.
In which case, the bob and jane @ earthlink problem is really earthlink's
to deal with. I think that's entirely appropriate; it is completely within
earthlink's capability to, say, use SMTP AUTH to gate users to deal with
this attack.
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.
There's really a third dimension too: the "unsigned" message problem.
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.
The subdivision of labor with DKIM has pretty much been: if it's
something that constrains a key, then it goes in the DNS record.
Everything else goes in the signature header. This seems pretty
clean.
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.
I'm not really sure where you're going with this, and I don't
think I like the implications. If a signer asserts something, it's
motivation for asserting it has to always be viewed with the
possibility of being gamed. So I don't know what "valid"
means through that lens. Useful information to a receiver can
only be of the "negative" variety; economists probably have
language for this, but information that there is no incentive for
the signer to lie about. Typically these are things that constrain
the degrees of freedom rather than increase them, which is
exactly what the current crop of tags in DKIM do.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html