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