[ietf-dkim] Responsibility vs. Validity

[Douglas Otis]

On Nov 28, 2007, at 5:35 AM, Charles Lindsey wrote:

> On Tue, 27 Nov 2007 20:21:32 -0000, Douglas Otis <dotis at mail- 
> abuse.org> wrote:
>
>> Not exactly.
>>
>> -------
>> 3.5 The DKIM-Signature Header Field
>> ...
>> [Regarding i= tag]
>>
>> INFORMATIVE NOTE: The local-part of the "i=" tag is optional  
>> because in some cases a signer may not be able to establish a  
>> verified individual identity. In such cases, the signer may wish to  
>> assert that although it is willing to go as far as signing for the  
>> domain, it is unable or unwilling to commit to an individual user  
>> name within their domain. It can do so by including the domain part  
>> but not the local-part of the identity.
>>
>> INFORMATIVE DISCUSSION: This document does not require the value of  
>> the "i=" tag to match the identity in any message header fields.  
>> This is considered to be a verifier policy issue. Constraints  
>> between the value of the "i=" tag and other identities in other  
>> header fields seek to apply basic authentication into the semantics  
>> of trust associated with a role such as content author. Trust is a  
>> broad and complex topic and trust mechanisms are subject to highly  
>> creative attacks. The real-world efficacy of any but the most basic  
>> bindings between the "i=" value and other identities is not well  
>> established, nor is its vulnerability to subversion by an attacker.  
>> Hence reliance on the use of these options should be strictly  
>> limited. In particular, it is not at all clear to what extent a  
>> typical end-user recipient can rely on any assurances that might be  
>> made by successful use of the "i=" options.
>
> That almost, but not quite, says the right thing.
>
> Essentially, the signature MUST include the From header (others are  
> at the signer's discretion). So, at a minimum, the signer is  
> asserting that this message came into bis possession via a route  
> that indicacted that its origin was within the domain within the  
> From (mailing list signatures excepted, of course). If the signer is  
> not prepared to vouch for that, then he has no business signing it.

Many providers do a good job, and only ensure behaviour of those  
granted access.  These providers might not require From email-address  
vetting equivalent to that of S/MIME certificates before granting  
access.  Such a provider may wish to ensure recipients that their  
outbound SMTP clients sign _all_ outbound messages.  If this assurance  
were possible, it could avoid complaints related to any spoofing which  
does not include their signature.  This is different from saying that  
all email-addresses within the From header are assured to belong to  
the purported author, as some might wish to assume.  SSP does _not_  
allow this distinction.  SSP policy is From domain centric, rather  
than from the perspective of the SMTP client.

This is a important distinction.  The provider might only vouch for  
the behaviour of their users, and not the accuracy of the From  
header.  Spam is defined based upon behaviour and not content, after  
all.

This becomes problematic when large providers using DKIM end up  
signing a fair amount of spam.  The proper way to handle this spam  
will depend upon knowing whether there are restrictions placed upon  
the use of the From email-address.

Unfortunately, providers may assert an SSP "all" to mitigate spoofing  
related complaints for messages they did not originate from their SMTP  
clients.  Before making this assertion, the provider instructs their  
customers to submit using only their outbound servers without imposing  
other restrictions.  This provider might even assign keys with "g=* 
+<group-number>" (based upon RFC 3598 sub-address extension)  
restrictions for MUA signed by customers who complain they don't  
always have access to the outbound servers.  And yes, some firewalls  
block port 587 for strange reasons.

When there are no or only limited restrictions on the From email- 
address use, the email-address in conjunction with the signing-domain  
should not be used as a basis for filtering spam.  A method to handle  
a situation of non-restricted From email-addresses being exploited by  
bots would be to include an opaque identifier based upon the account  
granted access.  An opaque identifier could track bot compromised  
systems independently from that of the From address.  An Opaque  
Identifier might be something as simple as u=<account-number> added to  
the DKIM signature.

DKIM must ensure correct identities are used to block spam.  For large  
domains, blocking can not always be done at the signing domain due to  
high levels of collateral blocking.

> Likewise, if he goes to the trouble of including an "i=foo at bar.com",  
> then he is asserting that foo at bar.com had played some part in  
> introducing the message into his system. Otherwise, he should not  
> have included that tag.

The i= parameter include the localpart to enable a key assigned to a  
group of users using the g= wildcard feature.  The i= syntax has been  
made necessary for a type of key which does not assure a unique  
identity.  Requiring the g= mask to be copied within the i= parameter  
would be a change to the DKIM base specification.  Not having the g=  
parameter contained within the message makes spam related filtering  
based upon the i= problematic.

> So if the present documents do not make these things clear, then we  
> need a further (BCP?) document that sets out, in the form of a Code  
> of Practice, just what obligations are entailed by creating such a  
> signature.

There remains a problem related to a provider's desire to avoid costly  
unwarranted complaints.  SSP currently does not offer an SMTP client  
centric policy assertion.  This limitation will tend to distort how  
Form header policy will be defined.  This situation requires that  
email-address restrictions must be made extremely clear.  Expecting  
this clarity based upon i= semantics remains problematic.  The TPA-SSP  
draft adds a scope= parameter that can be added to the non-TPA SSP  
record to make this assertion explicit.

-Doug