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 worthless. > 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 -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
