[ietf-dkim] Re: Responsibility concerns with DesignatedSigning
dotis at mail-abuse.org
Sun Aug 27 21:31:39 PDT 2006
On Sun, 2006-08-27 at 21:39 -0400, Wietse Venema wrote:
> Frank Ellermann:
> > It can be both correct: Let's take a realistic example, GMail
> > starts to offer forwarding, but adds some ads plus their own
> > signature, destroying the signature of bank.com. If we have
> > a couple of "MUST reject" and implementations actually doing
> > this they might give up. Something has to give, bank.com, the
> > munger, the verifier, or the user.
> When mail has a valid bank DKIM signature we have assurance that
> it was sent by the bank. The rfc2822.from is of minor relevance,
> because we already know from the DKIM signature that it was sent
> by the bank.
Without an assurance of the 2822.From, one does not know who within the
signing domain authored the message. This would be true for any domain,
where one must not assume an entire signing domain represents a
trustworthy entity. Very few will. Therefore DKIM should develop a
strategy that provides a benefit when not everyone in the domain is
trustworthy. Trust therefore MUST start at the 2822.From address. The
signature MUST also convey whether the 2822.From address has been
validated. Without this assurance, the DKIM signature is practically
> When mail has a valid gmail.com DKIM signature, but no valid bank
> signature, then all we know is that it came via gmail. Whatever is
> in rfc2822.from is merely hearsay and should be treated as such.
> There is no reason to delete the mail.
There is no reason to verify the DKIM signature when the 2822.From
address is not assured. When the 2822.From address is not assured, there
is no assurance who sent the message. The recipient should not assume
this signature offers any protection, nor should there be any annotation
that indicates the signature is valid. Annotation should only indicate
the 2822.From address is assured valid AND the signature verifies.
> The problem that you refer to is due to the mistaken belief that
> DKIM signatures imply anything about rfc2822.from addresses. We
> can eliminate the problem by simply taking DKIM signatures for what
> they actually are: proof about the identity of the signing party,
> not proof about the identity of the author.
If someone decides they can trust the 2822.From address, this trust can
be extended to that of signature, but only when the signature itself
indicates the 2822.From address has been validated. Otherwise, there is
no way any trust can extend to the signature, and there would be no
significant value obtained verifying the signature. If anything, this
would be wasted cycles that could leak information and ultimately
mislead the recipient.
Any DKIM message can be replayed, there are look-alike signing domains,
and not everyone within a signing domain should be considered
trustworthy. Also the To header is often an alias of some bulk list.
The factors needed for security are:
- a signature assured 2822.From address
- the DKIM signature associated with the 2822.From address
(by being within the 2822.From domain or via policy)
- presences of the valid 2822.From address in the address book
More information about the ietf-dkim