On Aug 3, 2005, at 12:53 AM, Jon Callas wrote:
On 30 Jul 2005, at 9:56 PM, EKR wrote:
We put spam and phishing last, and identity protection first, for the
exact reasons that you stated at the first MASS BOF: these are social
problems, and do not lend themselves to a purely technical solution.
We consider DKIM to be an authentication foundation for
accreditation, reputation and other authorization services.
Presently, there is not a good, reliable mechanism to build these
on other than IP address. DKIM uses digital signatures to provide
that foundation.
The identity validated by a verified DKIM signature would be the
domain providing the key. A product of obtaining this identity would
be that signatures also verify selected headers and message body
content which inhibits relay attacks. DKIM is not directed toward
phishing attacks, as such efforts MUST ensure reliance upon the
entire From header. Although DKIM policy may attempt to bind
signatures to the From header to protect the naive recipient as a
matter of policy, such binding may defer to the Sender header, for
example.
Constraining systems permitted to sign messages permit "anti-
phishing" assurances. System constraints are not directly an
assurance made by DKIM, but rather is a matter of key delegation.
However, the 'g=' element within the key may not offer sufficient
abuse protections, and harbors concerns regarding a potential for DNS
abuse. Nevertheless, the Originating Address algorithm is more
robust against phishing threats than the Purported Responsible
Address algorithm, for example.
By acknowledging a binding weakness, and accommodating a provision
for sub-domain 'third-party' signing, an alternative to the 'g='
parameter permits roughly the same level of anti-phishing protection,
while also improving domain reputation protections. Domain
reputation/accreditation will be the primary means to defeat most
attacks and abuse. As always, the domain which delegates keys would
have roughly the same duties of ensuring use of these keys are not
being abused. The trade-off would be improved reputation protections
versus a possible profusion of keys when attempting to assure local-
part name space at the possible expense of DNS stability.
It should be reasonable to opt for improved domain reputations,
rather than attempting to stretch DKIM to include validations for the
local-part, well beyond the domain identity validated by the
signature. This trade-off should also be weighed against the
possible impact wide-scale deployment of user-keys would have upon DNS.
The main thing that DKIM is designed to do is to have the sending
administrative domain sign a message for the benefit of the
receiving administrative domain. It's not the same thing as S/MIME
or OpenPGP, which are *user*-level signatures.
Absolutely.
I'm not convinced that this *can* be deployed incrementally.
The key here is to focus on the amount of information provided
by a message being unsigned. If most of the internet is sending
unsigned messages, then the negative weight you can assign to
someone not being signed is necessarily very small and so it's
not very useful for spam triage. This is exactly the kind of
question which needs to be addressed in a security analysis of this
class of system.
We agree we're not being as clear as we should be. Let me try to
explain what we mean.
Go back to the Yahoo basic explanation. If no one in the world but
Yahoo and eBay implemented DKIM, they'd get value out of it.
Adoption across the entire Internet isn't required. If the Nigerian
Phishers Association then adopts DKIM, it provides further benefit
to Yahoo, because they know that NPA messages are coming from the
NPA, and it can handle them appropriately.
On the flip side, incremental means that a DKIM-signed message has
no adverse affect on the recipient. For example, Gmail is presently
signing all messages with DomainKeys, and unless you look at the
headers, you wouldn't have noticed. (Now on the other hand, I'm
amused that the archives of this list does show the DKIM headers.)
Another way to look at it is that if you authenticate with DKIM,
then we can use reputation to make a decision about the email. If
there's no signature, or indeterminate reputation, we do scanning
by content, just as we'd do today.
Does this help explain what we mean?
Incremental benefits defer to those that establish a "name" basis for
assessing reputation, as opposed to a default use of IP addresses
which may be shared across a diverse range of messaging behaviors.
This benefit is enhanced by a means to authenticate the host name at
the onset of the transaction, to ensure resource protection schemes
for DoS protections will not diminish this benefit. This incremental
benefit should also be of interest to a majority of domain owners.
S 9.3:
-----
Since the key servers are distributed (potentially separate for
each
domain), the number of servers that would need to be attacked to
defeat this mechanism on an Internet-wide basis is very large.
Nevertheless, key servers for individual domains could be
attacked,
impeding the verification of messages from that domain. This
is not
significantly different from the ability of an attacker to deny
service to the mail exchangers for a given domain, although it
affects outgoing, not incoming, mail.
-----
I think this analysis misses something important: DKIM depends on
wide deployment of signing infrastructure in order to make
a message being not signed meaningful. If popular senders
are regularly unverifiable, this strongly reduces recipients
incentive to make decisions based on DKIM settings.
I think that you may not have seen that a sender can announce to
the world that they sign all messages and please reject any
unsigned ones. This policy statement means that an unsigned message
from such a domain is meaningful, and in a negative sense. Does
this address your concern?
Attacking the DNS for any specific domain would likely create Temp
fails, regardless of the use of DKIM.
-Doug