On Jan 1, 2007, at 10:19 PM, Jim Fenton wrote:
1. There is nothing in the base spec that precludes multiple
signatures from being used in this way, except for the requirement
in Section 5.4 that the From header field MUST be signed. So it
wouldn't be possible to detect a modification to the From header
field in this way.
It may prove a mistake mandating the signing of the From header once
internationalization becomes common. The From header mandate
supports a highly dubious anti-spoofing effort based upon visual
recognition. A far more secure alternative applies annotations to
digitally recognized originators. Such an annotation scheme does not
require troublesome From header stipulations and is not susceptible
to various visual exploits, such as the use of look-alikes or cousin
domains.
2. Providing a way to deal with header field modification was the
original intent of the z= tag/value. At the time this was proposed
(prior to the formation of the WG), there was considerable concern
about verifiers using z= to "correct" a modification; since the
spec does not deal with presentation issues at all, there was no
way to indicate this to the recipient. Telling the verifier to
replace header fields with the values from z= seemed heavy-handed,
so instead we got the strong "diagnostic use only" language not to
use the z= values for verification. I would support some gentler
language that permits use of z= in verification, with particular
attention paid to ensuring that a new security vulnerability is not
introduced.
When the MTA is expected to verify DKIM signed messages, then the
issue of signature selection become a fundamental problem not helped
by the base DKIM draft. Delving into how headers might be repaired
only makes this situation worse.
3. All of this is a very incomplete solution to the message
modification problem, since it doesn't address body modification.
We already have a way to tell if a modified body is the cause of a
signature not verifying, because the bh= value won't have the
correct hash. My solution would be for the modifier to sign the
message after modification. The verifier might want to apply
reputation, accreditation, or other things like local whitelists
(all of which are out of scope here) to determine whether they
"like" that modification based on who did the modifying.
As signatures can be replayed, white-listing will likely prove
impossible in many cases. The assumption used in the base draft is
that originating headers can be linked by a common domain. This
assumption may prove wrong, largely due to expenses in uniting email-
address domains with that of the transmitting entities. Transmitting
entities may wish to sign outbound mail to protect their outbound IP
address space. DKIM signed messages are useful for directing abuse
feedback. Some large ISPs already experienced problems adding Sender
headers containing their domain to their customers email messages
containing different email-address domains. Clearly, that is not the
intended use of the Sender headers either.
A rather minor change to the base draft could significantly reduce
the overhead related to signature selection when verification of a
specific originating header is being checked. This significant
reduction remains possible by eliminating a restriction on the 'i='
syntax to permit a linkage between a header and the signature even
when domains differ. DNS records in the header domain can reference
the signing domain as a means to validate the signature. This
approach eliminates a questionable practice of sharing private keys
or delegating domains en-mass, as currently assumed by the DKIM base
draft. This approach provides email-address domain owners greater
freedom of choice, and dramatically improves correlation of the
transmitting entity when commonly represented by the signing domain.
This last point can not be stressed more when there is any
expectation that DKIM might be helpful at reducing abuse.
The use of CNAMEs to bridge domains represents the same overhead used
to establish a relationship using a simple reference. Reference
association can be done autonomously, which means there is less cost
related to deployment, while at the same time the transmitting entity
is afforded greater protection. Removing the restrictions on the
'i=' syntax reduces the validation overhead and thus greatly reduces
DoS risks.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
