ietf-dkim
[Top] [All Lists]

[ietf-dkim] New Issue: ssp-04 Domain/Identity conflict

2008-07-02 20:15:32
Section 3.2 almost gets this right:

3.2.  ADSP Usage

  Depending on the Author Domain(s) and the signatures in a message, a
  recipient gets varying amounts of useful information from each ADSP
  lookup.
...
  o  If a message has a Valid Signature from an Author Domain, ADSP
     provides no benefit relative to that domain since the message is
     already known to be compliant with any possible ADSP for that
     domain.

However section 4.2.1 gets this wrong due to the definition for Author  
Signature:

4.2.1.  Record Syntax
  all  All mail from the domain is signed with an Author
   Signature.

  discardable   All mail from the domain is signed with an Author
   Signature.  Furthermore, if a message arrives without a valid
   Author Signature due to modification in transit, submission via
   a path without access to a signing key, or other reason, the
   domain encourages the recipient(s) to discard it.

2.7.  Author Signature

  An "Author Signature" is any Valid Signature where the identity of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address in the message.

------

When a key that validates a message signature has a restrictive  
template (g= tag and value) that does not match against an Author  
Address, it should not be considered to offer compliance with any ADSP  
assertions, nor be annotated as having a valid signature.  This  
proviso is what section 3.2 fails to make.

When a message contains a signature by a domain (d= tag and value) at  
or above the domain of the Author Address, and where the local-part  
template and signature domain match against the Author Address, then  
Section 3.2 would be accurate.  The default for the local-part  
template is *(_at_)(_dot_)  The default match against the Author Address should 
 
be be *(_at_)[*(_dot_)]<key domain>.  In essence, the current Author Signature  
fails to differentiate between trusted signing, as evidenced by no  
local-part restriction, and untrusted signing as evidenced by a local- 
part restriction.  Keys used by untrusted signing systems are more  
prone to theft since they are also likely employed by mobile users.  A  
security protocol that fails to make this type of distinction, for  
whatever reason, reduces overall security.  It is unlikely that most  
domains will be publishing and/or using ADSP when assessing DKIM  
signatures.  ADSP stipulates a check for a valid domain when accepting  
messages, and would be within the same purview when making an  
assessment of systems that are trusted to ensure domain compliance  
with all signed header fields.

Section 2.7 Author Signature requirement fails to offer any added  
protections, however this awkward strategy might necessitate inclusion  
of two signatures whenever the DKIM signature attempts to affirm an on- 
behalf-of identity not contained within the From header field.  For  
example, an office admin may introduce a message where their name is  
found in the Sender header field, and where the Author of the message  
purports to be that of their supervisor.  The policy applied by the  
signing domain might be able to determine through an authentication  
process, the identity of the office admin, and can check that they are  
permitted to send messages on behalf of their supervisor.  Accurately  
recording who was authenticated (the on-behalf-of identity) and adding  
a signature by the domain should be compliant with an assertion that  
messages are always signed by the domain.  Unfortunately, section 2.7  
would make such a signature non-complaint. : (

There is no reason to expect that multiple signatures should be added,  
nor that this requirement makes signature assessments easier.   
Instead, this strategy creates a significant security flaw where  
highly deceptive messages might be annotated as signed, rather than  
simply excluding local-part restrictive signatures that do not match  
against the Author Address from ever being considered valid for the  
purpose of ADSP compliance, or signature annotation.  This might mean  
this could be optimized by passing a list of From email-addresses to  
the signature validation process.

The current strategy also further weakens security in two other ways:

It increases the number of signatures that might be otherwise  
legitimately used. This creates an added overhead exposure when  
invalid signatures are added by bad actors.

Eliminates standardized use of the DKIM identity parameter from  
containing an opaque identity that might help track 0wned systems  
whenever DKIM is used in conjunction with ADSP.  Providers will be  
unwilling to affirm the identity contained within From header fields,  
however they may be willing to include an opaque value derived from  
their Radius server (RFC2865), for example.  Such use could greatly  
help in the correlation of bot-net related activity, and the indirect  
identification of 0wned systems.  As currently defined, two signatures  
would be needed, one required to be ambiguous about the on-behalf-of  
identity, and one that offers a specific identifier that is not the  
Author Address.

Change Author Signature to:

A Valid Author Signature is any message signature which correctly  
verifies using procedures described in section 6.1 of [RFC4871], and  
where the local-part template, the key g= tag and value, and the Key  
Domain, match against the Author Address.  The default match against  
the Author Address would be be *(_at_)[*(_dot_)]<key domain>. DKIM's identity  
parameters related to the author address are decisive only when a  
corresponding DKIM key local-part template precludes an author  
address. DKIM in conjunction with ADSP is to provide methods for  
detecting the spoofing of known domains, but not for making strong  
assertions about the identity of the message author.

Add to Security Consideration section:

DKIM keys with a restrictive local-part template in the g= tag and  
value are likely to be employed for untrusted systems that are beyond  
the direct control of the Author Key Domain. As a result, additional  
care should be taken when a restrictive local-part template does not  
match against the Author Address. Signatures, where a restrictive  
local-part key g= tag and value and the Key Domain do not match  
against the Author Addresses, should not be considered valid.

Signatures with restrictive local-part keys where the signing address  
is not that of the Author Address will be deceptive when marked as  
valid. Recipients are often unaware of the signature's on behalf of  
identity that is not normally displayed. In addition, these keys are  
prone to theft since they are also likely to be used by less secure  
mobile users, for example.

Signatures with DKIM keys lacking a restrictive local-part template  
are only safely added when the Author Key Domain is able to directly  
evaluate signed header fields and content. Recognition of directly  
controlled signing improves security in several ways:

- Discerns potentially deceptive signatures independent of ADSP  
Discovery.

- Permits the accurate indication of on whose behalf the signature was  
added, even when not on behalf of the Author Address.

- Permits the on behalf of identity to be derived from an account  
instead of being omitted when the Author Key Domain is unable or  
unwilling to affirm the identity of the Author Address.

- Permits the identity to track either the author or the account used.  
This ability can be useful to third-parties who are attempting to  
isolate bot-net 0wned systems. In response to a growing portion of the  
IP address space being blocked, bot-nets increasingly send their mail  
through a provider's outbound server after obtaining access to valid  
accounts.

It is likely that DKIM's and ADSP's combined roles will be to prevent  
deception when used in conjunction with automated folder placement of  
domains considered trustworthy.

To ensure message reception remains viable for crucial systems when  
DNS fails, the IP addresses of crucial SMTP clients should be white- 
listed. This will allow ADSP and DKIM to be selectively bypassed  
during such events.

-Doug





_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] New Issue: ssp-04 Domain/Identity conflict, Douglas Otis <=