[ietf-dkim] New Issue: Do we need SSP record for DKIM=unknown?

[Douglas Otis]

On Dec 24, 2007, at 2:12 PM, Jim Fenton wrote:

> The cases where this might be beneficial are when there is an  
> invalid Author signature or when there's another signature, valid or  
> invalid, in the Author's domain, in all cases referencing a valid  
> selector.

Presence of a public key at a selector plays an insignificant role in  
a signature's validity.  While the SSP draft currently attempts to use  
"on-behalf-of" the author to distinguish when SSP records are to be  
retrieved, the resulting added criteria for when a signature is valid  
is likely to be unnecessarily disruptive.

A message can be assumed to comply with either "all" or "strict" when  
the message has:

  1) A valid unrestricted signature at or above any Author's domain

  2) A valid restricted signature on-behalf-of the From header

This two part definition ensures legitimate messages with valid  
signatures are not unnecessarily classified as having invalid  
signatures.  Signing domains should not assume SSP will be applied.   
When a signing domain does not want messages to be accepted based upon  
which header their signature was on-behalf-of, the domain should not  
permit such message to be emitted.

A message sent by an office administrator on behalf of a From author  
and then signed with an unrestricted key should be seen as within the  
signing domain control and therefore compliant with any of their  
policies.  Without modifying message handling defined in DKIM base,  
signing is done by applying a signature on behalf of the Sender  
header.  This mode of handling is important, especially when only a  
Sender header is associated with an identity authenticated by the  
signing domain.  The logic of your first sentence requires an SSP  
"compliant" signature change DKIM base handling to:

  1) remain ambiguous about which header is being signed on-behalf-of
  2) lie about which header contains an authenticated identity
  3) apply two signatures, where one lies or remains ambiguous

> The invalid Author signature case will probably be relatively  
> common, but signatures from other addresses in the domain less so.

Agreed.  Why not presume when signed with an unrestricted key of the  
same domain as found in the From header, the message is to be  
considered compliant with any this domains SSP policies?

> It does seem that this might reduce the number of SSP lookups a bit,  
> however it would be necessary for a domain using this extension to  
> ensure that the SSP information in all key records is consistent  
> with that of the domain's SSP record.

You are describing a "scope" parameter added to Key records that  
restricts which headers are valid for the signature to be on-behalf- 
of.  When private keys are deployed beyond the direct control of the  
signing domain, not only a restriction on the local-part is needed,  
but that of the scope of headers signed as well.  Thus a restricted  
key (g=<local-part>) might represent an "assumed" scope parameter, as  
even a valid signature might not be compliant with a domain's desired  
policy.  An explicit scope placed within a key record could clarify  
which headers are valid for a particular key, but this would be  
unnecessary.

While appropriate for SSP compliance to limit the scope of  
"restricted" key's to being on-behalf-of just the From header, it is  
inappropriate for unrestricted key's scope to be limited in either  
which header or which local-part is signed.   In other words, SSP  
should not attempt to dictate how the i= parameter is to be used.  An  
unrestricted key should be assumed to be within the direct control of  
the signing domain, where the signing domain _MUST_ ensure their  
messages are _NEVER_ in conflict with any of their own policies.   
Policy enforcement of valid signatures by unrestricted keys is the  
sole job of the signing domain, and never something the receiving  
domain should be expected to implement.  The signing domain _MUST_  
enforce their own on-behalf-of policies when using unrestricted keys.

-Doug