ietf-dkim
[Top] [All Lists]

[ietf-dkim] Yahoo! IPR uses a direct relationship, the Opaque-identifier uses an indirect.

2005-10-30 20:46:52
20050039019 (20050039017)
,---
| 1. A method for message authentication, comprising: generating a key
| pair associated with a domain, wherein a public component of the key
| pair is accessible to a domain name system (DNS) server that is
| associated with the domain; if a message originates from a "sender's
| address" associated with the domain, employing a private component of
| the key pair to digitally sign the message and forwarding the
| digitally signed message towards a recipient of the message; and if
| the public component stored with the DNS server verifies that the
| digitally signed message originated from the domain associated with
| the "sender's address," employing at least one policy to handle the
| verified digitally signed message for the recipient.
'---

The primary claim in the patent application depends upon direct
association with the "sender's address", rather than the indirect method
recommended in:

http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-03.txt

The opaque-identifier + "sender's address" is retained by the recipient
where there may not be a direct relationship between the signing-domain
and the sender's address.  This indirect relationship would discourage
email-address based reputations.  Email-address reputation may act to
coerce policies that prohibit third-party services as this would be the
_only_ available protection for the email-address.  The opaque-
identifier however provides much better anti-spoofing security in the
general case and does not expose the email-address to reputation
accrual.

A direct relationship forced by way of policy enables reputation schemes
based upon the email-address.  Such an email-address reputation scheme
would have the effect of forcing an email-address to only be used with a
particular provider, and prohibit use of third-party email services such
as mailing-lists, e-invites, greeting-cards, kiosk-style communications,
several mobile applications, etc.

Such constraints upon the From header will also mean the From header may
no longer relate to who authored the message, but rather may indicate
the domain associated with the email message transport system.
Introducing uncertainty in this header does not reduce the amount of
spoofing of the author, but rather changes the nature of the spoofing
and actually increases the likelihood of a spoofing success.  Even a
direct relationship is easily spoofed due to the prevalence of "pretty-
name" MUA displays.

The opaque-identifier + signing-domain retained by the recipient can
significantly reduce a miscreant's ability to spoof, even within the
same domain!  It also enables strategies that can defend against
"pretty-name" ploys and look-alike domains perhaps done using changed
characters-sets.  This would also be more effective against the typical
phishing attack without the need for any policies asserted by the email-
address or the signing-domain.

The opaque-identifier can also completely defeat any message replay
abuse, provided the sender is responsive.  Publishing of revoked opaque-
identifiers could also be offered as a service by delegating the
revocation zone.

-Doug






_______________________________________________
ietf-dkim mailing list
http://dkim.org