-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 13 July 2004 06:18 pm, Andrew G. Tereschenko wrote:
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.
No, my point was that with SPF, we can authenticate a sending MTA as being
authorized to send email for a domain. Instead of just an IP address for
the origin of the email, we will have an IP address and a responsible
domain name.
My Point:
Hacked only once IP can be blacklisted for a long time.
As result a lot of legit emails will be blocked.
This is irrelevant.
DK propose to add additional level of granularity - keys.
You admit yourself that the keys in DK can be compromised. This is actually
just as easy as compromising a server. You have to store that key on the
server, and it can't be stored encrypted unless you have the password
available to the email server. If someone is able to compromise a machine
so that it will send email, then that implies that they have access to the
email system and all that the system entails. Thus, they have the password
and the domain key, and it can be copied.
(2) Proving that I spammed people
Your Point:
We must be responsible for everything.
No, we must be responsible for our mail servers, not everything. We claim
responsibility through the publishing of SPF records. Previously, if
someone sent email with Amazon.com's name, we would have to tell the owner
of that machine to stop it. This was ineffective, obviously. Now, I can
limit the number of machines allowed to send email for Amazon to only those
machines we have in our data center set aside specifically for sending
outbound email.
If I can't secure these machines, then email is the least of my worries.
My Point:
SPF "includes" increase risks of attacks.
Then don't use it, or use it responsibly. We may use it to include SPF
records from our own domain. If we can't trust ourselves, well, that's
really bad.
People who send email through their ISPs will use it to include the ISP's
records. If they can't trust their ISPs, then they have bigger problems
than sending email.
If "aol.com" SPF record will be forged - this will put a lot of innocent
users who use "include:aol.com" at risk.
DK suffers from the same problem. If the aol.com DK record is forged, then
we have problems bigger than email.
As result this make that there is no identified responsible person.
Your assuming that DNS can be compromised. This has not been the case. There
have been no recorded DNS attacks with the result of forged records for
quite some time now.
If DNS can be compromised, then email is the least of our worries.
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.
If AOL fails to take responsibility for their DNS records, then AOL suffers.
This is appropriate. Think of it this way. If AOL is incompetent, why would
you trust them at all? Why would you even accept their email? Would you
accept email from
We-Cannot-Secure-Our-Own-Machines-Because-We-Are-Idiots.com?
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.
No, if they get repeatedly hacked and fail to secure their networks, I will
not trust them. In fact, I would distrust them. I would probably say, "Hey
people, don't allow SMTP from this network. They invite spammers and
hackers into their network." Whether they allow themselves to get
compromised from incompetence, ignorance, or greed, is irrelevant.
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.
I don't see how this is relevant.
(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 would like to see you try. If you can hack our ISPs, you can hack the
entire internet. In other words, we are all doomed if this is possible.
It has been proven with experience that machines today are securable, that
we are resistant to most attacks, and that IP spoofing, DNS injection, and
other attacks are a thing of the past. Or they are so rare and so
ineffective as to be totally useless.
If someone comes along and is able to compromise our machines, do IP
spoofing, or DNS injection attacks, then email is the least of our worries.
Our entire internet is at risk.
I can hack DNS of select big ISPs and send spam that will look like from
Amazon.
Anything of this will damage Amazon reputation.
Yes, if you can do it, it will damage Amazon's reputation, and rightly so.
If you can hack into your bank and drain the customer's accounts of money,
then I would hope the bank's reputation would suffer. I certainly wouldn't
want to bank at "HeyWeGetHackedAllTheTime.com".
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.
See, now we are getting to the point. SPF provides a way for me to take
responsibility for my actions.
Previously, we had to call the major ISPs and tell them which servers in our
address range are allowed to send email. That was how we claimed
responsibility. We were already doing what SPF does, but we use the
telephone rather than DNS. Using SPF is going to make communicating what we
are already communicating that much easier.
Think of the original hosts.txt file that got passed around before DNS. That
was how they did DNS. Now the have DNS and it just makes life easier. That
is what SPF is - it is doing something that is already being done but now
it is a lot easier.
(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.
If they aren't, then the internet is unusable.
Also you depend on bunch of information that can be forged.
A/MX/TXT/PTR/Include records.
Again, if they can be, we have bigger problems than sending email.
You cannot validate if spammer altered legal message during transit.
How can they transmit even a legal message? If they try to forward it, it
will be SPF FAILED because they are not allowed to send email for me. The
only way they can send an email in my name is if they change it so that
they claim responsibility for it. Now there is a paper trail of
responsibility. If they spammed a message using 2822 FROM in my name, I can
see that they claimed responsibility for it.
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.
If you can do this, we have bigger problems than email.
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
You are obliged to use DK if you like. It works well in conjunction with
SPF.
My personal feeling is that SPF gives you enough protection that DK and
other protocols aren't necessary. I also believe that SPF itself is also
just as secure as DK. I know the messages aren't as secure, but the
protocol is.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA9WC4BFeYcclU5Q0RAnEBAJ9GINkANtjsn+sofcfUFy0rrcZEIwCgqORj
YZ7WAglDYT+ZOIJ/P4kyLhQ=
=J/Tq
-----END PGP SIGNATURE-----