ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-15 13:18:24
On August 15, 2005 at 05:00, "Hector Santos" wrote:

IMO, the only real assertion one can make with DKIM is:

    The main benefit of DKIM is that a validating agent
    can know which domain signed it.

And the restrictions imposed by the message originating domain on
who can sign the message.

I don't see any other assertion that can be made. DKIM, as is, basically
says:

   VALIDATED MAIL = DATA + SIGNATURE + DNS DOMAIN PUBLIC KEY

There is nothing in there that says:

    - Who actually wrote the message?
    - Who actually sent the message?

However, one can presume a correlation exist between the REAL person who
wrote or sent the
message and the domain who signed it and this presumption is increase when
the signing headers include the headers From:, To:, and possibly Sender:.

I believe the SSP is to provide a binding to the signing domain and the
message originating domain.  Yes, you (the verifier) cannot directly
claim who wrote and sent the message, but you should be able to verify
which domain the message originated from in the transmission/delivery
chain; the domain that claims responsibility for the message and
its contents.

So a mailing list server or bulk distribution can create a thousand DKIM
signed message distribution each with unique signatures, random and/or bad
From: local part addresses and the each 1000 members will only verifier that
it did come that mailing list or bulk mail server domain.

Cool?  Sure maybe, the mail integrity and domain is authenticated.

But the From: is still random or bad. The author doesn't exist.

Even then, it is better than before?

- Same spoofing problem exist.

- If MUAs are trained to display "This message is DKIM safe", this could
give
  spammed users a false illusion of increased value mail.

This ties into previous discussions about SSP and its critical role in
DKIM verification.  DKIM cannot prevent a domain from sending out crap.
What it attempts to do is prevent a domain from sending out messages
that appear to be from a different domain.  How well it does that has
a big dependency on how SSP is defined.

--ewh
_______________________________________________
ietf-dkim mailing list
<http://dkim.org>