Sorry for useless line breaks in my message. This will never happen again.
I will try to consolidate your post too.
.
(1) IP as identity
Your Point:
If I know IP address I will know origin of email.
My Point:
Hacked only once IP can be blacklisted for a long time.
As result a lot of legit emails will be blocked.
DK propose to add additional level of granularity - keys.
Once key compromised - you can revoke it yourself.
No needs for blacklists. But blacklists can be created to blacklist
non-legit keys/domains.
Compromised key revocation can possibly prevent delivery of email message
that already leave your servers.
MUA (in addition to MTA) can check all emails against list of compromised
keys.
User clients or servers can easily check if key revoked/blacklisted, reason
why and mark messages as suspect (or delete, but email can be valid).
With IP based auth this is impossible. All emails that leave your servers
will be delivered to MUA.
Parsing headers to find out if IP in revocation list are possible - but not
trivial.
Before DATA SPF algo do not allow to validate messages after delivery.
(2) Proving that I spammed people
Your Point:
We must be responsible for everything.
My Point:
SPF "includes" increase risks of attacks.
If "aol.com" SPF record will be forged - this will put a lot of innocent
users who use "include:aol.com" at risk.
As result this make that there is no identified responsible person.
AOL can blame their network partners because they allowed DNS forgery or
traffic injection.
AOL clients will blame AOL.
Users with mailboxes filled with spam will blame and blacklist AOL clients.
Also www.mygreatingcards.com can be in reality responsible for spam, but
will blame hackers who hacked unknown company using unknown method and
altered legit greeting cards.
And you will trust them because nothing like this was in past.
Press coverage about attack by unknown hackers to promote "MyProduct Co."
company will only increase spam effect and boost MyProduct sales.
You will be unable to sue them because of known SPF weakness.
(3) Hacking
Your Point:
Hacked Amazon in case of SPF are the same as hacked Amazon with DK.
My Point:
No needs to hack Amazon.
I can hack Amazon ISP. I can hack DNS root servers.
I can hack DNS of select big ISPs and send spam that will look like from
Amazon.
Anything of this will damage Amazon reputation.
In case if Amazon will keep DK secure no reputation damage will be
decreased.
You can use CA signed keys. Or you can user SSL transport to
distribute/validate keys.
I agree with you that Amazon must take entire responsibility.
(3) SPF an Authentication Mechanism
Your point:
If it isn't an authentication mechanism, then what is it?
Authentication is a process of determining authorization via the
presentation and examination of credentials. The credentials that SPF uses
are [...]
My point:
All credentials used are not reliable.
Also you depend on bunch of information that can be forged.
A/MX/TXT/PTR/Include records.
You cannot validate if spammer altered legal message during transit.
As well IP network is not secure - if you can take control over router or
network link you can inject messaged on behalf of totally independent
networks.
It was noted in section 10 (Security Considerations) in 3-protocol.txt
DK has must less exploitable weakness.
The only information you must obtain from reliable source is public key.
Current unsecure key delivery using DNS have workaround using CA or using
other delivery methods.
This make information you have and decision you make based on it more
reliable
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua