Subject: [ietf-dkim] Review of draft-ietf-dkim-base-00 (1)

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2006 09:49:49 -0800

This message contains editorial comments on draft-ietf-dkim-base-00.
In a separate message I'll explore a larger scale issue: whether
it's a good idea to invent a totally new protocol rather than
reusing something existing (e.g., S/MIME).

S 1.1.

   o  there is no dependency on public and private key pairs being
      issued by well-known, trusted certificate authorities,

This claims seems somewhat disingenous. DKIM depends for its
security on DNS, which is *known*to be insecure. S 8.4 suggests
that this problem will be overcome via DNSSEC, which certainly
does require well-known, trusted CAs, namely the roots. Note also
that in classic PKI systems, the public and private key pairs
are not ISSUED by the CAs, just attested to by then,

S 3.3.
As noted previously by Russ, I think 512 keys are unwise.

S 3.5.
           require the attacker to choose both sets of input text; given
           a preexisting input (a "preimaging" attack), it is still hard

(1) Typically people use the term "preimage" rather than preimaging.
    Even more precisely, this is a second preimage attack.
(2) As noted in my review of a previous version of this 
    document, collisions are actually an issue here if the
    MTA does content filtering before signing.

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

It seems to me that the x= needs some explanation about what happens
in the case of clock skew.

S 3.6.

   DKIM keys do not require third party signatures by Certificate
   Authorities in order to be trusted, since the public key is retrieved
   directly from the signer.

Well, no, it's retrieved from the DNS server for the signer's
domain, which may or may not be the same thing.

S 4.
   For these reasons, multiple signatures are not prohibited but are
   left undefined.

I don't see how this makes sense:
(1) If they're undefined, that means that two parallel signatures
    can be rejected by the verifier, even if they're both verifiable?
(2) Given that multiple signatures are required for algorithm transitions,
    I don't see how you can avoid specifying behavior here. The obvious
    behavior seems to be to accept any valid signature and ignore the
    others.

S 6.3.
   o  Based on the algorithm indicated in the "a=" tag,

      *  Compute the message hash from the canonical copy as described
         in Section 3.7.

      *  Decrypt the signature using the signer's public key.

   o  Compare the decrypted signature to the message hash.  If they are
      identical, the hash computed by the signer must be the same as the
      hash computed by the verifier, and hence the signature verifies;
      otherwise, the signature fails.

GAH! Please please please don't describe digital signature verification
this way. This only applies to RSA, not, say, DSA. I note that
my previous review of draft-allman-dkim-base pointed out this error
as well.

S 8.2.
What about a compromised MTA?

Also, it's worth noting that malware could suppress bounces.

S 8.4.
   To systematically thwart the intent of DKIM, an attacker must conduct
   a very costly and very extensive attack on many parts of the DNS over
   an extended period.  No one knows for sure how attackers will
   respond, however the cost/benefit of conducting prolonged DNS attacks
   of this nature is expected to be uneconomical.

I don't find this at all convincing. The resources being used are
compromised computers, of which there are plenty. Not only is this
likely to be economical, it seems quite likely if DKIM is widely
deployed.

-Ekr

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Mar 2006 21:39:59 -0600

> This claims seems somewhat disingenuous. 

It shouldn't. The statement is simply and directly accurate, as given.

The problem with the analysis you provided is that it conflates a dependency
that DKIM *does* have on the DNS, with the means that DNS might/will use to
provide acceptable service.

To pursue the line of concern you have raised, here are some simple questions:

1. Does DKIM specify anything that looks like a cert authority?

    Answer:  No.

2. Does DKIM require validity of the data produced by the DNS?

    Answer:  Yes.

3. Does the DNS provide reasonably good data validity today?

    Answer:  Yes

4. Is the current DNS vulnerable?

    Answer: Yes

5. Are CA's required to fix this?

    Answer:  Maybe, but maybe not.  Certainly that is the path being explored,
    planned on, and maybe even slightly deployed.  Other schemes might have been
    feasible, but they aren't what has been defined.

In other words, Eric,  the logic that goes from DKIM to a CA is rather
circuitous.  It contains some twists and choices.

In fact if you are looking for the characteristic of craftiness that is implied
by the word disingenuous, then I'd be inclined to suggest that it applies more
to claiming that DKIM *does* use CAs than to the claim that it does not.

Otherwise we have to use the same logic to say things like: You "use" Turkish
because you bought a product that was imported from Turkey.

> As noted previously by Russ, I think 512 keys are unwise.

Is there an immediate danger to using them, for the purpose for which DKIM is
intended to be used?

Has the use of 512 keys been banned from the current Internet?

Is that danger worse than the many other imperfect mechanisms being used on the net?

Perhaps greater wisdom rests in providing alternatives, including the ability to
use existing packages today, with an eye towards agility on key size.

> domain, which may or may not be the same thing.

It probably is worth making that distinction, if only to help remind people of
such things as delegating signing, by outsourced services and the like.

One could have a semantic debate that they are all part of the same authority
structure, but it can't hurt to underscore the operational distinction.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Mar 2006 23:08:03 -0600

Answer:  No.

    Answer:  Yes.

    Answer:  Yes

    Answer: Yes

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 08:35:42 -0600

Eric

> Uh, sure, if you say so. The fact is that the document explicitly
> suggests that it be secured via DNSSEC, so the path is nowhere
> near as indirect as you suggest.

Actually, that text demonstrates the kind of mis-directed requirements placed on
the DKIM effort.

What should have been an exercise in writing a specific protocol has, instead,
been forced to make comments about other work.  So, now, you are using a bit of
frankly pedagogical commentary as some sort of proof of normative inclusion.
(To say that something is "used", as you did about CAs, you are counting it as
part of the specification.)

This seems to be a particular pattern with anything that touches security and
perhaps accounts for the area's stellar record of creating successful
IETF work.

In any event, the fact that there is text that makes reference to DNSsec does
not change the logic problems I cited.  By way of a legalistic demonstration of
this fact, I'll repeat that the language is not normative.

Again, for your assertion to be correct, you must count DKIM's scope of what it
"uses" as being everything that is in everything that DKIM touches, and maybe
even requiring that this inclusion recurse down, ad infinitum.

>> In fact if you are looking for the characteristic of craftiness that
>> is implied by the word disingenuous, then I'd be inclined to suggest
>> that it applies more to claiming that DKIM *does* use CAs than to
>> the claim that it does not.
> 
> Of course you would.

Not too happy about having the word disingenuous applied to the analysis you posted?

Indeed, it is never pleasant to be the recipient of such labels about one's
intent, particularly when that use is both unfounded and inaccurate.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 09:16:51 -0600

> Well, it certainly is so much easier to write security protocols
> if you don't require them to be actually, you know, secure.

Oh.  So you see a technical flaw in DKIM?

Please cite it.  Please indicate what solutions will resolve it.

Failing that, please explain what you mean.

> No, just bored.

Have you ever noticed how someone making that statement, at the end of an 
energetic exchange that they have not won, mostly never means it?

I wonder if that qualifies as disingenuous?

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 20 Mar 2006 07:14:38 -0800

> circuitous.  It contains some twists and choices.

   I think that if "CA" meant "central authority" rather than
   "certificate authority", it would probably be appropriate.
   But it doesn't, and CA brings in all kinds of baggage mostly
   from the "certificate" side. If I understand things correctly,
   DNSSEC doesn't require use of "certificates".

   It's probably the wording here that's really the problem. Instead
   of antognizing the X.509 crowd (as it currently reads), it should
   be phrased in a positive way "the only trust root required for
   DKIM is the existing DNS trust root", or somesuch.

 > use existing packages today, with an eye towards agility on key size.

   This is, IMHO, probably not a battle worth fighting. I'm comfortable
   with the language that Russ/Arvel suggested.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 10:03:52 -0600

Michael,

>   "certificate authority",  it would probably be appropriate.

There are all sorts of ways of changing what Eric said, to make it accurate,
relevant and useful.

Certainly DKIM uses domain names registrations and initially (and perhaps
forever) relies on querying for key information by using the operational DNS.
Yes, the DNS is a central service.

It might well help public understanding to make the distinction between using 
the operational DNS and using some other third-party service.

However, I'll suggest that the way to get there is not through a simple
nomenclature change.

DKIM does not require the operation of new infrastructure.  DKIM uses domain
names registrations, to provide unique identifications. DKIM initially uses
records added to the operational DNS to distribute public keys.  DKIM uses the
relationship between the owner/administrator of the domain name and the location
of the key information, in the DNS, to establish self-certification of the key
information.

Given the history of Internet deployment of CA services, what DKIM is doing is
fundamentally different.

Whether this means that "no third party service" is used or whether the wording
should be more subtle, is a reasonable question.  Those uncomfortable with the
language probably ought to suggest an alternative.

>   DNSSEC doesn't require use of "certificates".

Your understandng is corret.

And yes, that does make Eric's "criticism" even more curious, doesn't it?

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 10:23:02 -0600

Eric Rescorla wrote:
> Dave Crocker <[email-masked]> writes:
> 
> I thought I was clear in the original message. There are well-known
> attacks on DKIM when it is used in the absence of DNSSEC. There's
> no secret here--it's explained clearly in both documents. Whether it's
> a "flaw" or not is a matter of opinion, of course. 

Ok.  So you do not like DKIM's use of the current, operational DNS.

As nearly as I can tell, the line of concern you are expressing applies equally 
to any other dependency on DNS having accurate information.

Since the vulnerability of DNS has been well-known for quite a bit more than 10 
  years-- or rather, that is how long DNSsec has been under development -- I 
guess we either had better note that there is a difference between plausible 
attacks and vulnerability, versus practical utility, or we all need to stop 
using the DNS for essentially any of its current applications.

I suspect that that is not an implication you intend.

So, please explain how the universal reliance on the DNS' mapping from domain 
name to IP address constitutes a fundamentally different security requirement 
than the one that DKIM has.

>> Have you ever noticed how someone making that statement, at the end of
>> an energetic exchange that they have not won, mostly never means it?
>>
> Whatever. 

Have you ever noticed how someone making that statement...

d/

-- 

Dave Crocker