Dave CROCKER wrote:
On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote:
The fundamental problem with the current situation is that the
authenticated identity is not displayed and the displayed identity is
not authenticated.
Forgive my pursuing it in this fashion, but I'd class that as a first
derivative, rather than fundamental. (But, then, first derivatives
are important.)
Fundamental is that DKIM is not trying to authenticate the message
and it is not trying to authenticate any identity such as From:
It is merely trying to affix a /separate/ identifier, with a claim
that its being affixed is valid, but not that it relates to any other
aspect of the message. In other words, it is trying to identify
message streams, rather than "validate" messages or authors.
The fact that DKIM uses underlying crypto algorithms keeps confusing
people into wanting to use it the way OpenPGP or S/MIME are designed
to be used. Ain't gonna work.
d/
But DKIM does indeed bind an identifier (d=) to a message
cryptographically in a way that allows an MTA to use the
reputation of the owner of the (yes, separate) identifier
when evaluating the spamminess of a message. The d= domain
is the "authenticated identifier" to which I was referring.
ADSP and the related third-party extensions try to create
a binding between d= and From: but either break applications
such as MLMs or create a provisioning problem where domain
owners need to explicitly configure the third-parties that
are allowed to sign their mail. These mechanisms are motivated
by the fact that MUAs typically display the From: field and
users tend to give credence to the identifier in this field
when evaluating phishing messages. My point is that, rather
than trying to authenticate this field with DKIM + ADSP, we
should be encouraging MUAs to display the d= value and let
the user independently evaluate the reputation of the signing
domain and decide whether or not it was appropriate for the
domain to sign mail with the given From: line. I can trust
a message From: paypal.com but signed with d=mipassoc.org
not because paypal.com has somehow "authorized" mipassoc.org
but because I subscribe to the dkim mailing list and I know
the context in which the message is being delivered. I would
similarly know that my friend Joe has a vanity domain but
uses google apps for his mail, and expect to see a d=gmail.com
DKIM signature on mails from him. If this changes for some
reason, I might call Joe and ask him if he changed providers.
Even if the MUA doesn't display the d= domain directly, I
can imagine they might implement security tools similar in
spirit to some of the CA validation extensions for browsers
that are available to warn the user in case the CA of a given
website changes countries (see
http://files.cloudprivacy.net/ssl-mitm.pdf).
-Pete
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html