Re: Comments on draft-allman-dkim-base-00.txt

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

Jon Callas <jon@xxxxxxxxxx> wrote:
> On 30 Jul 2005, at 9:56 PM, EKR wrote:
> > 1.0 Background
> > DomainKeys Identified Mail (DKIM) is basically an anti-forgery
> > measure. The idea is that MTAs serving a given domain will
> > digitally sign messages they forward. Thus, recipients will
> > be able to detect forgery by absence of a valid signature.
> > Signing keys are made available via DNS.
> >
> 
> Absence of a valid signature does not imply forgery, but presence of a
> valid signature is strong evidence to the contrary.

Agreed.

> Furthermore, one of the values of DKIM is that the presence of a
> signature might have positive or negative value. For example, as a
> receiver, I might consider a DKIM signature from ebay.com to be a good
> thing and deliver the message to the recipient with no further
> checking. I might consider a DKIM signature from 3bay.com to be reason
> to delete the message, add in additional metadata (like a Spam
> Assassin-compatible header), or something else.
>
> All of these, however,
> are beyond the scope of this document, if not the whole (proposed)
> DKIM working group.

I disagree, because they go to the question of whether its a useful
technique.


> 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.

You can't ignore the fact that the reason people are interested
in this is as part of a spam/phishing filtering system. In
such a system, the value of reducing identity forgery is
primarily to enable whitelisting, which has the purpose of
reducing false positives. So, it needs to be asked whether that
is a useful technique.


> > 2.2 Duplication of Existing Mechanisms
> >
> > DKIM really consists of two loosely coupled protocols.
> >
> >      (1) A message signing protocol with characteristics somewhat
> > 	 reminiscent of PEM.
> >      (2) A key retrieval protocol to retrieve the keys used
> > 	 for (1), as well as to deliver policy about what
> > 	 messages are expected to be signed.
> >
> > There's no reason why these two need to be coupled at all.
> > Indeed, it would make a lot of sense to couple a generic
> > message signature protocol to the key retrieval mechanism
> > described here.
> >
> 
> As others have said, DKIM differs from PEM, S/MIME, and OpenPGP in
> that it puts the signatures in the headers. It's not like them at all.

Right, but why is that a different problem from the one that
PEM et al. attempt to solve? I.e., why can't you use the same
protocol for secure messaging and for this application?


> I'm not sure what to say more about decoupling. You're certainly right
> that we could do it. The present structure owes a lot to the way that
> we merged the DK and IIM documents. We could make another revision
> that would separate things into two documents, but would that actually
> add anything? You'd still have to read them both before you understood
> the system, and one could argue that that makes it less understandable.

Yes, but it would give you a system constructed of generic components,
which is always a good thing.


> 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.
> 
> If this message were signed, it would be a statement by callas.org
> saying that the message was properly sent according to its own
> policies. When I first spoke to the Yahoo guys, they said that the
> goal of (then) DomainKeys was so that Yahoo as an ISP can know that a
> message that purports to come from eBay really did, even if it bounces
> off of the recipient's alumni association. I think that's a good,
> concise description of what problem we're trying to solve.

Yes, that's fine, but cryptographically there's no important difference.


> I mention in my other notes another advantage that I'll call out here
> again. That is that we do not *require* special MUA support. An MUA
> that speaks DKIM can add value, but it's not needed. When we spoke to
> senders who want to use DKIM for authenticating mail to their often
> naive customer base, it's important to them that DKIM signature not
> alter the appearance of an email. Additionally, I can tell you from my
> experience that it is very difficult to create a complex MIME message
> that displays correctly if I don't know a priori what your MUA is. By
> "very difficult" I mean that we've not found a profile of MIME
> features that scales well at all.

Sure, but why doesn't this all just imply that we should junk S/MIME and
OpenPGP and replace them with DKIM?


> 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.

Extremely minimal value, I would argue.


> >
> > S 1.4:
> > -----
> >    DKIM differs from traditional hierarchical public-key systems in
> > that
> >    no key signing infrastructure is required; the verifier requests the
> >    public key from the claimed signer directly.
> > -----
> > I wouldn't characterize a DNS query to a server quite possibly not
> > controlled by the same person as the MTA as "directly". For instance,
> > I operate my own MTA but name service is provided by my ISP.
> >
> 
> Yes, but you're allowed to put entries into your DNS, aren't you?
> Maybe we're being glib, but if I outsource my DNS, I consider it to be
> under my direct control, even if I'm not personally changing the
> configs and hupping the server process.

Yes, but that's not what this text says. You explicitly don'[t
contact the signer, but rather some potentially entirely different 
machine operated by a different person. This isn't a technical
issue but one of writing clarity.

> >
> > S 3.3.3:
> > -----
> >    o  Larger keys impose higher CPU costs to verify and sign email
> > -----
> >
> > The CPU cost to verify even fairly large RSA signatures is extremely
> > small.
> >
> 
> Maybe. The CPU cost to verify signatures is small if it's a fast
> processor that spends a lot of its time idle.
> 
> I commonly read my mail from two machines. One is a 1.5GHz PPC, the
> other is a 40MHz x386. On the latter machine, the difference between a
> "small" signature and a "large" one is measured in seconds.
> 
> In the other dimension, if you have a fast CPU that is very busy, it
> might also be a concern. Take a server that processes 12 million
> messages per day. On that machine, a difference of a millisecond per
> signature ends up being over three CPU-hours per day. That may or may
> not make a difference.
> 
> It's a true statement that larger keys impose higher CPU costs. What
> would you like us to say?

Well, it's also true that adding >64 bytes to the message imposes
higher digest costs, but it's generally regarded as insignificant.
I tend to put the verification costs in this category. That said,
I don't really care.

> >
> > S 3.5:
> > ------
> >          INFORMATIVE RATIONALE:  The authors understand that SHA-1 has
> >          been theoretically compromised.  However, viable attacks
> >          require the attacker to choose both sets of input text;
> > given a
> >          preexisting input (a "preimaging" attack), it is still hard to
> >          determine another input that produces an SHA-1 collision, and
> >          the chance that such input would be of value to an attacker is
> >          minimal.  Also, there is broad library for SHA-1, whereas
> >          alternatives such as SHA-256 are just emerging.  Finally, DKIM
> >          is not intended to have legal- or military-grade requirements.
> >          There is nothing inherent in using SHA-1 here other than
> >          implementer convenience.  See
> >          <http://www3.ietf.org/proceedings/05mar/slides/saag-3.pdf> for
> >          a discussion of the security issues.
> > -------
> > I'm not sure that I agree with this analysis. If the model for the
> > MTA is that it's going to blindly sign any message from someone
> > who is authorized, then I agree with you, but that's not the
> > only model. Consider an MTA which does some outgoing spam filtering
> > and only signs messages it thinks aren't spam--this is to contain
> > botnet compromise.
> >
> > In this case, the attacker prepares two colliding messages, one
> > spam and one innocuous. He gets the MTA to sign the innocuous one
> > and then substitutes on output. Note that this is possible because
> > of the extension property of SHA-1 and the choice to put the message
> > contents first in the SHA-1.
> >
> 
> I'm not sure I understand what you're saying. If we assume a thorough
> compromise of SHA-1, one in which it is "easy" to get a pre-image
> collision, then yeah, the attacker can take a signed message and make
> a colliding message that passes signature verification. That's why a
> complete break of a hash algorithm would be bad.

Attacker generates message A (spam) and message A' (not spam) that
collide. He sends A' through the MTA, gets a signature, and then strips it off
and sends A to the victim. It's slow, but it is an attack that doesn't
require preimages.

> Would it make you feel better if we just stopped talking about SHA-1
> and went right now to SHA-256? We have tags that allow the sender to
> specify the hash algorithm used in the message. We also have ways for
> the signing domain to specify which algorithms may be used with a
> given key. We believe this takes care of any downgrade problems that
> might exist with weak hash algorithms.

I'm not saying the above is a serious security risk, merely that your
analysis above is inadequate.

> > 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?

No, because initially currently many senders don't have any such
policy published. They just don't sign their messages. The important
question for the recipient is how useful a signal a message being
signed is. If it only reduces the false positive rate for spam
(back to that again, but that's the use case) then the incentive
to use it as a signal isn't very high.

-Ekr