Section 3.2 overlooks hazards related to stolen or misused private
DKIM keys likely offered to mobile users that have restrictive local-
part templates imposed by a public key's “g=” tag and value. In such
cases, the domain is indicating their lack of trust in a key's use.
Any annotation indicating a message has a valid signature when the
Author Address fails to match against a restrictive local-part
template and domain encourages the exploitation of these likely
vulnerable keys, and leaves recipients prone to deception.
,---
|3.2. ADSP Usage
|...
| 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.
'---
Change to:
---
o If a message has a Valid Signature from an Author Domain, and where
a key's restrictive local-part template and domain does not preclude
the Author Address, ADSP provides no benefit relative to that domain
since the message is compliant with any possible ADSP assertion.
---
The definition for Author Signature also needs modification:
,---
|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.
'---
Change to:
---
An "Author Signature" is any Valid Signature where an Author Address
matches against the key's local-part template and domain. A match
is determined by construction of a template composed of the key's
“g=” tag and value and domain as denoted in the signature's “d=” tag
and value in the form <g value | * >@[*.]<d value>. The default for
the key's local-part template value when it is not present is “*”.
---
Many large ISPs will benefit by being able to offer an “on-behalf-of”
identity as defined by the signature's “i=” value that may not be
found within the From header field or elsewhere within the message.
An ISP's authentication process may not correspond directly with email-
addresses their customer's use. In some cases, it will be easier, and
will offer greater privacy, when the “i=” is permitted to be an opaque
value derived from the ISP's authentication servers referenced from
either an account or customer systems, rather than a specific author.
By allowing large ISPs this freedom, recipients are far more likely to
obtain an identifier that can be used to block abuse emerging from
large domains where completely blocking the domain would not be
practical. Few ISPs are likely willing to affirm an identity of the
Author, but might be more willing to offer a surrogate identity
instead. After all, the WG charter precludes DKIM from being used to
make strong assertions about Authors. However, the aggregation of the
“on-behalf-of” information, whether it is that of Authors or their
surrogate identity, will allow third-parties a means to isolate
systems likely 0wned by bot-nets.
Not changing the Author Signature definition will necessitate use of
multiple signatures (which increases receiving systems DDoS exposure
when these allowances need to be made), or cause ISPs to leave the “on-
behalf-of” identity in an ambiguous state by not including the “i=”
tag and value at all.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html