[ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Douglas Otis]

On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote:

> 3.  Scope and scale of query traffic
>
> SSP originally was constrained to apply only to unsigned mail.  The  
> current specification applies to unsigned messages *and* signed  
> messages where the DKIM i= domain name does not match the  
> rfc2822.From <addr-spec> domain.  This is a considerable change in  
> the nature -- and potentially a considerable change in the amount of  
> query traffic -- that SSP causes.

The desire here is to qualify the From header for transactional  
messages.

> The draft does note that initial receive-side adopters of SSP will  
> find no SSP DNS record.  However the draft does not address the  
> adoption and use impact of being expected to make a query that will  
> almost always fail for a significant number of years into the future.

A policy statement that can be applied more broadly, where benefits  
extend beyond just qualifying the From header, would suit more than  
transactional messages.  Adding Scope to policy could more broadly  
apply to all originating headers when handling "normal" messages.   
This policy could also clarify what is implied by use of the i=  
parameter.

The current use of the i= parameter is clumsy.  Matching the i=  
parameter precludes use of a g= restricted keys from signing Sender  
headers to spoof a From header.  The ALL or STRICT assertions must  
constrain the i= parameter to disqualify restricted keys not signing  
the From header.  Adding scope can eliminate these constraints.

Attempts at providing a minimal set of assertions has lead to this  
very sub-optimal policy mechanism this is only suitable for  
transactional messages.  Most domains use the full set of originating  
headers.  There is also a need to partition policy to suit how email  
is being used.  Who is signing is the place to establish such a  
partition.  Users SHOULD NOT see well-known domains use other domains  
to establish different policies.  Policy partitions can transparent by  
introducing Scope and a TPA-SSP label.  These two changes offer  
significant benefits.

-Doug