Re: [ietf-dkim] Choices about Practice vs. Publication

On Jul 8, 2007, at 11:42 AM, Dave Crocker wrote:

> 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.
There will not be much sympathy for having bounced replay abuse, when  
the victim is also the signing domain.  Be aware that IP reputation  
schemes may not be generous to those bouncing the message.  In  
addition, there are many domains where "same-domain" replay abuse  
might become problematic.  Those forwarding messages into such a  
domain will appear fairly similar to "same-domain" replay abuse.  It  
should not be assumed "same-domain" replay abuse only occurs via a  
spoofed MailFrom addresses where BATV might prove useful.
> 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
DKIM is normally related to the "originating" domain, but DKIM can  
also be added by subsequent domains.  When attempting to ascertain a  
potential for replay abuse, finding the SMTP client within the  
signing domain precludes a replay abuse concern.  When an originating  
email-address domain differs from that of a subsequent signing  
domain, then ONLY WHEN the signing domain has been explicitly  
authorized by the originating domain can replay abuse be excluded.   
Without an ability to preclude possible replay abuse, acceptance will  
likely remain based upon the reputation of the SMTP client's IP address.
Transparent authorization accomplished through an exchange of keys  
defeats being able to preclude the potential for replay abuse.  Even  
when the originator and the subsequent provider both sign, explicit  
authorization is needed to permit the SMTP client to be within the  
signing domain of the originating email-address.  An explicit  
authorization via a DNS record can provide such authorization by- 
name.  The method can be very scalable and within a single  
transaction which is likely needed anyway.
Relying upon SPF/Sender-ID as a type of authorization places DNS  
itself at risk where this scheme might incur many additional  
transactions.  In addition, SPF/Sender-ID is based upon constructing  
comprehensive IP address lists.  As IPv6 use increases, IP addresses  
will become fairly dynamic as well.
When the message is unsigned, the check will be for a normal SSP RR.   
When the message is signed, a check could be for a TPA-SSP RR  
instead.  Even a subsequent transaction for the SSP RR could be  
eliminated by a wildcard below the SSP record.  Even so, wildcard  
records should be avoided.  The next transaction will likely check  
the existence of an MX or A RRs to validate the email-address  
domain.  This approach precludes transactions traversing the entire  
domain.
>         b) inclusion in the signed message, either as an  
> enhancement to an existing header field, or as a new field.
A signing domain may wish to make assurances related to the validity  
of the MailFrom address.  Such an assurance may improve the integrity  
of DSNs when the MailFrom email-address differs from that of the 'i='  
parameter.  Such a header could also assure "authorized" domains  
which might differ entirely from that of the signing domain.  Such a  
feature could also assist with "same-domain" replay abuse resulting  
from spoofed bounce addresses.  In this case, the header would not  
need to be standardized.
> 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.
This would be true except when dealing with possible replay abuse.   
When the ability to replay DKIM messages is exploited, deliverability  
of a message may depend upon being able to determine a relationship  
between the SMTP client and that of the signing domain.  Otherwise,  
the IP address used by the client remains the only safe reference to  
base reputations.
>   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.
This assertion in many cases would need to exclude the From address,  
but this header is required to be signed.  Use of the "i=' parameter  
is likely the only positive means to communicate such an assurance  
and is already defined within DKIM base.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html