[ietf-dkim] Choices about Practice vs. Publication

[Dave Crocker]

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