Subject: [lemonade] Push/pull security hallway conversation

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 2004 16:35:55 -0600

[Apologies for the resend; I screwed up Derek's address in the first 
sending. Please reply to this instead.]

I was supposed to get to this right after I got back from Seoul, but never did.

I had a hallway conversation with Derek Atkins and Mike St. Johns 
about security issues in push/pull. The conclusion was that Derek 
thought doing push or pull was pretty much even security-wise, while 
Mike thought that pull was *less* secure than push. Derek's analysis 
pretty much agreed with what's been on the list to date, and he can 
elaborate in response to this if he wants. (I've Cc'ed Derek, so he 
can speak for himself.) But Mike's argument seemed pretty persuasive 
to me (and I seriously tried to argue against it) and he suggested 
that I post a synopsis of his argument to the list and let him join 
the discussion as he sees fit.

There are two parts Mike's argument which I'll call "Point vs. 
Continuous Attacks" and "Security Balances".

1. Point vs. Continuous Attacks

When calculating the cost of attack for any system, one thing you can 
look at is whether the attack is a point attack or a continuous 
attack. Using his terminology, a continuous attack is one where you 
must break into the system you wish to attack and stay on for some 
period of time before you can get at the data you are interested in 
attacking. I take the canonical case here to be a man-in-the-middle 
attack where you listen for traffic over a period of time and make 
your attack when the data of interest is available. A point attack is 
one where you get in, make the attack immediately, and then leave. 
The example here would be breaking in a stealing a file from a known 
location on the system and then getting off of the compromised system 
immediately. Since continuous attacks take indeterminate amounts of 
time to perpetrate, they are often easier to detect and are therefore 
harder to accomplish. Point attacks are much harder to defend against.

Current IMAP servers are of course subject to some point attacks: If 
you are able to compromise the IMAP system, you can often get at the 
user data immediately and get off of the system without being 
noticed. Current submission servers are really only subject to 
continuous attacks to steal data: You have to compromise the system 
and wait for a client to send the data before you can steal the data.

In a push scenario, each server still has similar vulnerability: The 
IMAP server is still subject to point attacks (with the possible 
added avenue of the attacker being to push his acquired data through 
SUBMIT, for what that's worth) and the submission server is still 
subject to continuous attacks.

However, in a pull scenario, Mike argues that submission servers will 
now be subject to point attacks: An attacker who gains access to the 
submission server will potentially get access to a pull token. Once 
stolen, the pull token can then be taken and the attacker can leave 
the submission server, able to download the data from the IMAP server 
from another machine before the submission server has a chance to 
actually get the data. This would make the risk scenario for the 
submission server much different than the current state of affairs.

2. Security Balances

Mike described a simple set of security balances that have to be made 
in any system:

Cost of Protection < Cost of Attack
Cost of Attack > Value of Data
Value of Data > Cost of Protection

On any IMAP server now, you protect it according to the above 
guidelines. So, the cost of attacking the IMAP server must be greater 
than the value of the data on that IMAP server, which must be greater 
than the cost of protecting it. Therefore, you protect it (with 
passwords, firewalling it off, etc.) to the extent that you can get 
that formula to hold true. Different IMAP servers have different 
values of the data on them, so each will have different formulas and 
the cost of protection will be different for each. (Since submission 
servers require continuous attacks to get at data, the cost of 
attacks is normally much higher and the cost of protection much lower 
than the IMAP servers it might serve.)

Now you go to introduce the submit mechanism. With push, the 
equations stay pretty much the same: Whatever the value of the data 
on the IMAP server, you protect it to the extent that the protection 
is less than the cost of attack and less than the value of the data. 
There is an additional piece to protect (the risk that the data will 
be available through the submission pipe), but since the data gets to 
that submission pipe through the IMAP server, overall the assessment 
stays pretty similar.

With pull, things change a bit. With point attacks being a 
possibility, the costs of attack drop on submission servers. Since it 
is possible for a single submission server to receive submissions 
from several IMAP servers, it means that you will have to protect the 
submission server to value of the data coming from the most valuable 
IMAP server. That potentially increases the cost of protection for 
the overall system (IMAP+submission) significantly more than with the 
push scenario.

-------------

I hope I have done justice to these arguments. I am by no means a 
security geek, and I hope Mike will elaborate or correct what I have 
said as necessary. Everyone's feedback and analysis is requested.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade