[ietf-dkim] NEW ISSUE: SSP-02: Policy Scope

[Douglas Otis]

On Feb 13, 2008, at 1:32 PM, Wietse Venema wrote:

> Douglas Otis:
>> The current assumption used when asserting DKIM policy is that this  
>> policy might apply across _all_ protocols used to carry messages  
>> that might contain DKIM signatures.  Either DKIM policy records  
>> need to declare the scope of the protocols covered by the policy,  
>> or the label used to discover a policy should employ different  
>> labels.
>>
>> Add:
>>
>> Policy assertions for _SSP records are limited to messages  
>> exchanged by SMTP.  When other protocols are used to receive  
>> messages, the appropriate policy should be applied upon receipt,  
>> and/or the protocol should be tracked within the message.  One  
>> method for such tracking could be implemented using Authenticated- 
>> Results headers.
>
> Excuse my ignorance, but why limit DKIM (or SSP) to information that  
> is delivered via SMTP? They can work with any transport that uses  
> RFCx822 for content and that uses DNS for name resolution.

Agreed.  DKIM can be employed in conjunction with _many_ transport  
protocols.  While a domain may assert they sign "all" their SMTP  
traffic, they may not be signing other types of traffic that could  
potentially use DKIM signature headers.  How would a domain indicate  
what protocol they cover by their assertion?  It seems logical to  
restrict the _SSP policy to that of SMTP.  Other protocols can define  
where the relevant policy can be found, or they could add a protocol  
policy scope to the record.

The policy should make it clear when it applies to SMTP.  When there  
is also a mandate to publish an MX record while publishing SMTP  
policy, the the following states will have been defined:

SMTP          SMTP/DKIM
DISCOVERY     POLICY
(MX)          (SSP)     State

  NO		NO	0 Status Quo
  YES		NO      1 No Policy Defined
  NO		YES	2 SMTP Disavowed (cease further transactions)
  YES		YES	3 Policy Defined (SMTP/DKIM supported)

For example, when "non-smtp-domain.sld.tld" publishes a SMTP/DKIM  
policy without an MX record resulting in state 2, this halts a  
discovery process from making SSP record queries against "sld", and  
could prevent bogus key record queries from being made against "non- 
smtp-domain.sld.tld".  Being able to disavow having sent a message  
while also curbing some DNS related traffic should provide an  
incentive for domains to publish SMTP/DKIM policy record.  As  
currently defined, only state 2 offers a clear indication of a message  
being disavowed or repudiated.  This repudiation should be even  
stronger evidence than that obtained with an invalid signature.  Those  
that fail to publish MX records in conjunction with SSP policy records  
might find some verifiers consider their SMTP traffic as having been  
disavowed.  This would also be an incentive to publish.

Providing incentives for domains that don't use email to publish  
policy records ensures greater value in bothering to query for the  
record in the first place.  The juice being worth the squeeze.

-Doug