Michael Thomas wrote:
Dave Crocker wrote:
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.
...
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.
You might be referring to a different issue, but I think the i= parameter
makes this particular issue moot. Might have been an interesting discussion
about 2 years ago, but not so much now.
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.
If the message is unsigned, then it is not a candidate for carrying DKIM
information, is it? Note that my list was about *mechanisms* for carrying
information, not (at this point) about what might dictate the choice.
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.
Well, you are certainly stating a very simple and clear rule. However I don't
recall that being discussed by the working group or there being any clear
understanding among the group that that is the design policy.
In any event, what my interaction with Steve did was suggest a related, but
somewhat different policy basis. Note that an SSP record in the DNS, to cover
unsigned messages, does not fit your policy rule.
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"
Concern for being gamed is certainly required.
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.
"Useful information to a receiver can only be of the "negative" variety"
strikes me as a pretty remarkable assertion, given that DKIM is far more about
establishing positive trust than negative.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html