There is some redundant information within domainkeys.
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-02.txt
I assume the following is saying the sending domain has confirmed the
user is entitled to use the local-part of either the Sender or From
header.
|The current valid tags are:
|
| g = granularity of the key. If present with a non-zero length
| value, this value MUST exactly match the local part of the
| sending address. This tag is optional.
|
| The intent of this tag is to constrain which sending address
| can legitimately use this selector. An email with a sending
| address that does not match the value of this tag constitutes
| a failed verification.
. . .
|This base definition of DomainKeys is intended to only enable
|domain-level authenticity; whether a given message is really sent by
|the purported user within the domain is outside the scope of the base
|definition. Having said that, this specification includes the
|possibility that some domains may wish to delegate fine-grained
|authentication to individual users.
If the sending domain has determined the local-part is valid for a user
(perhaps by way of sharing the private key requiring a specific
selector), why is it required that the recipient do any more than
confirm the signature? Why not change this to be a flag that indicates
the domain has confirmed the local-part, and leave the assertion at
that? It seems far wiser to remove this altogether however.
|While the DNS is currently insecure, it is expected that the security
|problems should and will be solved by DNSSEC [DNSSEC], and all users
|of the DNS will reap the benefit of that work.
|
|Secondly, the types of DNS attacks relevant to DomainKeys are very
|costly and are far less rewarding than DNS attacks on other Internet
|applications.
|
|To systematically thwart the intent of DomainKeys, an attacker must
|conduct a very costly and very extensive attack on many parts of the
|DNS over an extended period. No one knows for sure how attackers will
|respond, however the cost/benefit of conducting prolonged DNS attacks
|of this nature is expected to be uneconomical.
I would be careful. By having DNS become a barrier to sending email for
those wishing to abuse the system, DNS attacks become rewarding from
the aspect of gaining credibility. Phishers, for example, wish to be
perceived as credible, and methods for pharming do not compare to the
costs involved with cracking keys. (Except for 512-bit keys perhaps.)
There is something that domainkeys could provide to bolster security
ahead of DNSsec deployment. I would hope to see DNSsec get deployed
quickly, but this requires extensive coordination. A stepping-stone
approach to validate a sequence of keys allows for monitoring as a means
to thwart such attacks and could be done unilaterally, perhaps well
ahead of the pending implementation of DNSsec.
|Finally, DomainKeys is only intended as a "sufficient" method of
|proving authenticity. It is not intended to provide strong
|cryptographic proof about authorship or contents. Other technologies
|such as GnuPG and S/MIME address those requirements.
This statement contradicts the g= feature intended to do just that,
provide proof of authorship. There would be greater benefit, and less
risk involved defending the domain, by adding just an opaque
revocation-identifier for a means to revoke authorization implied by the
signature. Keeping validation policies of the domain private with
respect to furthering assurances of the local-part would be a much safer
alternative.
I admit to not being happy with:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txt
I have yet to see the Kucherawy draft being referenced by this draft
appear.
-Doug