ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Responsibility concerns withDesignatedSigningDomains

2006-08-27 12:26:54
Hector Santos:
The problem is the mistaken belief that signatures make
statements about 2822.From addresses.
...
So I am not sure why it is a mistaken belief to view DKIM as a Digital
Message Signature technology and protocol that attempts to make a strong
statement of assuring mail integrity by protecting the originating mail
author, its domain, its mail content from potential harm and abuse.

First, I trimmed a log of your reply, because I would not limit a
discussion of DKIM usefulness to just the popular email exploit of
the day (phishing).

Allow me to get back to basics. Stated in simple terms, if a DKIM
signature verifies, then the verifier knows two things:

 1) The hash was signed by the purported signing party. This means
    that the verifier can trace the message back to the signing party.

 2) The inputs to the hash were not modified. Specifically, some
    malicious or non-malicious party didn't modify the inputs at
    some later point in time.

If mail doesn't have a valid signature, then the none of the above
assurances exist. The mail may be authentic but some munging broke
the DKIM seal, or it may be non-authentic (phishing etc). The
verifier can not make a definitive statement about this. SSPs
notwithstanding, because SSPs don't handle email munging.

After all, what is the purpose of DKIM?

Thanks for asking. The purpose of DKIM is to trace back signed mail
to signing parties.

For example, suppose that you have confidence in your bank's DKIM
signature.  Then you can use it to distinguish between mail from
the bank, and phishing mail that pretends to be.  Note that it does
not matter what their rfc822.from says.  It's the bank's DKIM
signature that forms the primary basis for trust.

Another example: suppose that I receive mail from a mailing list.
I trust the list server's DKIM signature, so I can distinguish
between mail from the list server and mail that pretends to be.
Again, note that it does not matter what their rfc822.from says.
It's the list server's DKIM signature that forms the primary basis
for trust.

With first-party signatures, things simplify conceptually and
technically to the point of elegance. This is one reason why I
express preference for first-party signatures. But even in this
special case, it is the DKIM signature that forms the primary 
basis for trust. The rfc822.from is secondary.

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

<Prev in Thread] Current Thread [Next in Thread>