[ietf-dkim] Choices about Practice vs. Publication

[Dave Crocker]

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