[ietf-dkim] Choices about Practice vs. Publication

[Michael Thomas]

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