Subject: Re: [lemonade] Push/pull security hallway conversation

From: Pete Resnick <[email-masked]>
Date: Wed, 31 Mar 2004 23:44:59 -0600

[This is a followup to Ned's message. I haven't seen his message 
appear on the list yet, so it may be caught in a non-subscriber 
filter. Please read his message before this one.]

I've got some clarification questions, mostly for my own edification. 
Mike can say something about the arguments himself.

On 3/31/04 at 3:48 PM -0800, [email-masked] wrote:

>>1. Point vs. Continuous Attacks
[...]
>>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.
>
>When you consider change attacks you've allowed an IMAP server 
>exploit to be used to compromise future mail people send in various 
>ways.

Are you saying here that a push-enabled IMAP server has the new 
exploit of a change attack which uses the sending mechanism? That's 
sort of what I was referring to when I said "possible added avenue" 
(though, admittedly I wasn't thinking of change attacks), but I get 
the feeling you're talking about something different.

>>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.
>
>First of all, for this to really be a point attack presumes you know 
>when the pull token you want becomes available to the submission 
>server.

Actually, I think what Mike had in mind was that for any reasonably 
busy server, there were always going to be a collection of pull 
tokens lying around somewhere (in a well known place, depending on 
the implementation) waiting to be sent and that an attacker would be 
able to grab those. But of course you're right that if you're looking 
for a particular piece of data, you'll need a continuous attack. 
(Mind you, for a plain old IMAP server where you are looking for a 
particular piece of data, you're going to need some time on the 
server to search for the data you want, so it's not a simple point 
attack in that case either.)

I guess my question is, if everything else is a wash on this score, 
isn't this still a new point vulnerability?

>And even if you grant that the attacker has some way of devining 
>when a token will become available, this is easily defended against 
>by making the pull token only usable from the submission server. 
>(This can be configured into the IMAP server or it can be coded into 
>the token itself. Or both.)

By "configured into the IMAP server", do you mean "only allow pull 
tokens to be used from a particular IP address" or something to that 
effect?

With regard to "coded into the token itself": My understanding of the 
way the tokens were designed (and the reason they were going to be so 
handy for all sorts of things) was that they were going to be 
authorization tokens without authentication credentials. If we put 
something into the token that indicates which particular machine they 
can be used from, aren't we going to also be in the business of 
having the MUA figure out which submission server it's talking to and 
which IP address or other identity is going to have to be embedded in 
the token?

>When change attacks enter the picture it all turns into a wash. In 
>the pull case the tokens cease to be interesting -- an attacker is 
>better off intercepting the outgoing mail in its entirety than the 
>small subset composed using pull mechanism.

At least for the case of the clients I envision who are using the 
IMAP server to store the outgoing message (i.e., using APPEND or 
CATENATE to the "sent-messages" box and pulling from there), all of 
their messages are going to use the pull mechanism. (More on this at 
the end of the message.) So I'm not sure I understand what you mean 
by the above.

>>2. Security Balances
>>[...]
>>With push, the equations stay pretty much the same:
>
>Sorry. The cost of the attack may stay the same, but the cost of 
>protection is critically dependent on code complexity and other, 
>similar factors. And the unfortunate reality is that proxies may 
>look simple but in fact are quite complex and hard to get right. And 
>you're adding one of these complex and tricky beasts to your IMAP 
>server. You've just raised the cost of protection substantially.

I've heard the word "proxy" used in this context before, and I've 
been told some things are proxies and some things aren't. So the 
first question I've got is, what counts as a proxy? I take it the 
"bolt sendmail onto imapd" is a proxy in the worst possible way, 
right? Is an SMTP submit client in your average MUA a proxy? What 
does and doesn't constitute one of these things?

Second, I keep hearing repeated that these are complex and tricky 
beasts. Maybe the answer to the above will make it perfectly clear, 
but what is it that's complex and hard to get right with these 
proxies? Again, perhaps I'm just missing the referent, but I'd be 
much happier if this argument didn't come down to "Trust me, I know 
about these proxies, and they're hard, so don't worry your pretty 
little head about this." I am feeling a bit like that's the answer 
I've been getting at times.

>>Since it is possible for a single submission server to receive 
>>submissions from several IMAP servers,
>
>Maybe it is, maybe it isn't. This gets down to implementation 
>details. And you shouldn't be assuming that implementations and 
>configurations of push will be "smart" and those of pull will be 
>"dumb".

I'm not sure I see where I have made the assumption that push 
installations will be "smart" and pull installations will be "dumb". 
If you think I have made that assumption, please point it out more 
explicitly. (I'm willing to admit that I might be unconsciously 
holding that sort of view, but I don't see where.)

>>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.
>
>There's a hidden assumption here that the messages in the store are 
>more valuable to an attacker than the messages someone submits. This 
>may or may not be true - the temporal factor may mean that new 
>messages are hugely more valuable.

Actually, the assumption that I've been making is that in the 
use-case that we're designing this for (low-resource clients), *all* 
data will be in the store. In the push case, that assumption is 
obvious. But even in the pull case, to this point we've talked about 
either (a) pulling completed messages from the IMAP store or (b) 
storing sent messages back into the IMAP store (with some sort of Fcc 
function). In either case, the IMAP store is where to be to get the 
good data when you want it if you're an attacker.

>But even if you asssume the store is where the really valuable data 
>livs, I would contend that the difference in implementation 
>complexity between the two schemes makes this a wash once again.

So, is the take away from this message (among other things) that 
security-wise, pull and push are really a wash? (More to the point, 
is there reason to believe that push is *worse*, security-wise, than 
pull?)

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Apr 2004 09:00:58 -0800 (PST)

In the new URLAUTH document, we have removed the client-generated URL 
functionality as being unneeded for Lemonade, so all URLs are created by 
SIGNURL.  We have furthermore removed anonymous signed URLs as also being 
unneeded for Lemonade.  Last but not least, the only current mechanism is 
INTERNAL.

Consequently,..

All URLAUTH URLs have been created by the server using keys (and perhaps 
even an algorithm) that is unknown even to an authorized entity, much less 
an attacker.

In order for a URLAUTH URL to be used, the client to the IMAP server (the 
submit server) must authenticate itself to the IMAP server.  This 
authentication is also unavailable to an attacker.

I think that this addresses most, if not all, of Mike's issues.

I think that pull and push are a wash as far as security goes.  However, I 
note that there is a vulnerability in push in that an attacker which 
compromises an IMAP server now has the keys to a submit server.  These 
days, it appear that the greater security issue is a bad guy acquiring 
access to a trusted SMTP-injection point that will get around spam 
blockers.  This point tends to be overlooked as most people think of SMTP 
as being unauthenticated.  That isn't the case with the SMTP engines 
operated by the more vocal pull advocates, so there may be a cultural 
difference that blocks communication in this regard.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Apr 2004 09:27:21 -0800 (PST)

On Thu, 1 Apr 2004, Derek Atkins wrote:
> Is the authentication of the submit server somehow tied to the URLAUTH
> object?  If so, how?

Yes, in one of two ways depending upon how the URL was signed.  In one 
form, the URL is only usable by a specific userid authenticated to the 
IMAP server; in the other, the URL is only usable by a userid 
authenticated to the IMAP server as having "submit server" role.

In all cases, the submit server (the client to the IMAP server) must 
authenticate to the IMAP server prior to using any URLAUTH URL.

> Also, how do to deal with the potential pull of multiple objects from
> multiple IMAP stores (which may be adminitered by different
> identities)?

This is contained within the URLAUTH URL, as long as the submit server can 
authenticate itself as being authorized to use that URL.

> I can certainly posit a case where I use my "home"
> submit server but want to pull in an object from a "foreign" IMAP
> store to which I have access.

That scenario doesn't work with push at all, and clearly was considered 
outside the scope of Lemonade.  Otherwise we wouldn't have had a long push 
vs. pull debate since push would have been knocked out of consideration.

Unfortunately, the removal of anonymous from URLAUTH closes many (but not 
all) doors on this capability.  You can't have it both ways; either you 
allow arbitrary clients to use a URLAUTH URL or you don't.  For the 
in-scope purposes of Lemonade, the latter sufficed.

I too believe that this capability is desirable.  But I had to bow to the 
reality that it's not going to happen at this stage.  Lemonade does not 
require this capability, and having it in there introduces distracting 
security arguments.

> Finally, (perhaps this is documented in URLAUTH), are URLAUTH objects
> necessarily single-use?

There is no requirement either way, although URLAUTH does have an 
expiration feature.  I don't think that single-use is necessary, and I 
certainly don't think that it should be mandatory.

Nevertheless, if there is concensus to include single-use as an option, I 
won't oppose it.

-- Mark --

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 1 Apr 2004 09:06:48 -0500 (EST)

> isn't this still a new point vulnerability?

I don't believe so -- by this argument, I believe it is reasonable to say
that SMTP servers are currently vulnerable to a "point vulnerability"
for any of the messages in their queue at a given moment.

Likewise, anything that the SMTP server has a token for can be seen as a
message "in their queue"  (provided that they are, of course, discarding
the token after they have the data).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?

---

From: [email-masked]
Date: Wed, 31 Mar 2004 15:48:59 -0800 (PST)

> 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.

I'm afraid I find this entire analysis to be based on a variety of incorrect
assumptions and as a result the conclusions it reaches are also incorrect.

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

> 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.

Breaking things down in to the binary cases of point and continuous attacks is
a gross oversimplification that leaves out the single most important case:
Someone breaks in, changes something in some way, and then leaves.

Trojan horses and all sorts of other common attacks fall into this middle
category. Indeed, I would claim that these attacks are practically the rule,
with point and continuous attacks being the exceptions.

The unfortunate reality is that change attacks are almost as difficult as point
attacks to detect. (The idea of using backups, checksums, limited access
rights, and similar mechanisms to detect or prevent such things is a nice one
in theory, but modern systems are so large and complicated and have so many
acolites in attendance feeding and washing and making all sorts of changes that
they are rarely practical.)

I'm not going to bother walking through the various cases of change attacks
here, but if you do the analysis I think you'll find that Derek is right and
that it ends up being a wash.

> 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.

And they are even more subject to change attacks.

> 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.

They are also subject to change attacks. These range from simple things like
adding/deleting an address to/from an alias or inserting a backdoor to allow
posting using an assumed identity to tricky stuff like generating a periodic
digest of all the messages that match some set of criteria and sending it
somewhere.

> 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.

When you consider change attacks you've allowed an IMAP server exploit to be
used to compromise future mail people send in various ways.

> 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.

First of all, for this to really be a point attack presumes you know when the
pull token you want becomes available to the submission server. If you don't
know when it will show up (and in many if not most cases you won't)  you have
to wait for it, making this a continuous attack.

And even if you grant that the attacker has some way of devining when a token
will become available, this is easily defended against by making the pull token
only usable from the submission server. (This can be configured into the IMAP
server or it can be coded into the token itself. Or both.) This means the
attacker has to perform the attack on the submission server, which in effect
converts it into a continuous attack in _all_ cases.

When change attacks enter the picture it all turns into a wash. In the pull
case the tokens cease to be interesting -- an attacker is better off
intercepting the outgoing mail in its entirety than the small subset composed
using pull mechanism. (I suppose there's the case of a token issued but then
the message submission based on the token fails for some reason, but I don't
think this is significant.)

> 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.)

Submission servers of any sort don't require continous attacks, which reduces
the attack costs considerably and changes the equation substantially.

> Now you go to introduce the submit mechanism. With push, the
> equations stay pretty much the same:

Sorry. The cost of the attack may stay the same, but the cost of protection is
critically dependent on code complexity and other, similar factors. And the
unfortunate reality is that proxies may look simple but in fact are quite
complex and hard to get right. And you're adding one of these complex and
tricky beasts to your IMAP server. You've just raised the cost of
protection substantially.

> 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.

It doesn't. See above.

> With pull, things change a bit. With point attacks being a
> possibility,

They should not be with a properly designed and configured pull system.

> the costs of attack drop on submission servers. Since it
> is possible for a single submission server to receive submissions
> from several IMAP servers,

Maybe it is, maybe it isn't. This gets down to implementation details. And you
shouldn't be assuming that implementations and configurations of push will be
"smart" and those of pull will be "dumb".

> 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.

There's a hidden assumption here that the messages in the store are more
valuable to an attacker than the messages someone submits. This may or may not
be true - the temporal factor may mean that new messages are hugely more
valuable.

But even if you asssume the store is where the really valuable data livs, I
would contend that the difference in implementation complexity between the two
schemes makes this a wash once again.

				Ned

---

From: Derek Atkins <[email-masked]>
Date: Thu, 01 Apr 2004 00:57:05 -0500

Pete Resnick <[email-masked]> writes:

> security-wise, pull and push are really a wash? (More to the point, is
> there reason to believe that push is *worse*, security-wise, than
> pull?)

I certainly do not believe that push is worse, security-wise, than
pull.  I think there are tradeoffs to be made; push has some benefits
over pull, and pull has some benefits over push.  IMHO I think pull is
a more general model, but there are definite security concerns that
need to be addressed (note that I'm NOT saying those concerns don't
also exist with push).

However, are you at all interested in a general case of combining
multiple objects from (potentially) different IMAP stores into a
single message?  If so, then push really boils down to "pull bolted to
ONE of my IMAP servers."

FWIW, I can certainly posit a case where I want to forward a reference
to a message in a public IMAP store as an attachment to a message
relating to something in my personal IMAP store and then save the
resulting message into my IMAP outbox.  I think push can do this
provided the reference is in a public IMAP store, but probably not if
it's in a (second) private IMAP store.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Apr 2004 18:30:47 -0800

At 9:00 AM -0800 4/1/04, Mark Crispin wrote:

>  In the new URLAUTH document, we have removed the client-generated 
> URL functionality as being unneeded for Lemonade, so all URLs are 
> created by SIGNURL.

That requires an extra round-trip per message (or message segment), 
doesn't it?  (It saves the client having to sign the URL, but with 
symmetric algorithms that shouldn't be too bad.)

Although if COMPOSE is being used, I suppose the client could 
pipeline the SIGNURL to the COMPOSE, and thus not have to wait for an 
extra round-trip.

At 4:33 PM -0600 3/31/04, Pete Resnick wrote:
>  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.

I'd expect in common configurations that submit servers would connect 
to IMAP servers and consume the tokens very quickly, so tokens would 
have an extremely short life, making this a continuous instead of a 
point attack.

At 9:00 AM -0800 4/1/04, Mark Crispin wrote:
>  However, I note that there is a vulnerability in push in that an 
> attacker which compromises an IMAP server now has the keys to a 
> submit server.  These days, it appear that the greater security 
> issue is a bad guy acquiring access to a trusted SMTP-injection 
> point that will get around spam blockers.  This point tends to be 
> overlooked as most people think of SMTP as being unauthenticated. 
> That isn't the case with the SMTP engines operated by the more 
> vocal pull advocates, so there may be a cultural difference that 
> blocks communication in this regard.

This is an interesting point.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The ignorance of how to use new knowledge stockpiles exponentially.
                                                --Marshall McLuhan

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Apr 2004 18:44:43 -0800 (PST)

On Fri, 2 Apr 2004, Randall Gellens wrote:
>> SIGNURL.
> That requires an extra round-trip per message (or message segment), doesn't 
> it?  (It saves the client having to sign the URL, but with symmetric 
> algorithms that shouldn't be too bad.)

Yes.  Although I believe that client-generated signatures are useful and 
desirable, they are not needed for the purposes of Lemonade and they 
create a distracting security issue.

>>  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.
> I'd expect in common configurations that submit servers would connect to IMAP 
> servers and consume the tokens very quickly, so tokens would have an 
> extremely short life, making this a continuous instead of a point attack.

More importantly, the attacker must not only gain access to the submit 
server and the pull tokens on the submit server.  The attacker must *also* 
gain access to the authentication credentials used by the submit server to 
authenticate it as such to the IMAP server.  The pull tokens are only 
usable by an entity which has those credentials.

-- Mark --

---

From: [email-masked]
Date: Thu, 01 Apr 2004 10:55:20 -0800 (PST)

> exploit of a change attack which uses the sending mechanism?

More or less. The IMAP server becomes a single point of attack, and
that's a significanly larger issue when change attacks are factored in.

> That's

Not really.

> the implementation)

Unless I'm misunderstanding something here unconditional deferral of token
expansion strikes me as a hugely nonobvious and entirely suboptimal way to
implement pull on a submission server. I would expect many pull tokens to be
dealt with during the SMTP session, with the result that the tokens themselves
never appear anywhere but in process memory somewhere, and even those will be
there for only a very brief period of time.

Only when token resolution has to be deferred for a protracted interval for
some reason will there be a bunch of them lying around. But guess what? All
these tokens give you is access to stuff that's going to end up in an outgoing
mail queue in fairly short order. The outgoing mail queue on a submission
server strikes me as a far more obvious and interesting target for a point
attack, as do the logs of messages sent and received (very useful for traffic
analysis).

> waiting to be sent and that an attacker would be

A change attack is far more likely in this case. Indeed, given the fact that
many MTAs now support fairly sophisticated message intercept capabilities
(thanks to various government mandates), change attacks have gotten a heck of a
lot easier in many cases - an attacker can simply make use of facilities the
MTA provides and goes out of its way to hide. And the trend is definitely
towards such features becoming the exception, not the rule. If you want to
worry real security issues, worry about this. I know I do...

> isn't this still a new point vulnerability?

Yes, but that's like saying that a 100 mile and 1 inch race is longer than a
100 mile race. An obscure and not terribly effective new attack isn't
interesting when there are so many obvious and terribly effective old attacks
around.

> tokens to be used from a particular IP address" or something to that

Yes.

> which IP address or other identity is going to have to be embedded in

First, the MUA pretty much has to know what submission server it
uses in order to send mail, so I fail to see why it would be difficult
to provide this information to the IMAP server.

But even if this is a hard problem for some reason I don't understand, the
identity doesn't have to be bound that tightly. A service provider could limit
the tokens its servers issue to the submission servers it provides. Yes, this
locks the user in to not being able to use the submission server of their
choice when they use pull, but it is still more flexible than push, where the
the submission server and IMAP server are by definition one and the same.

> the end of the message.) So I'm not sure I understand what you mean

My point is that with a change attack I might as well intercept all the mail
someone sends without worrying about the underlying mechanisms they use to
compose the message. You're reinforcing the sides of the barn while leaving the
front door open.

> first question I've got is, what counts as a proxy?

Simple: A proxy is something that acts as both a connection starting and ending
point but which falls short of being a full fledged transfer agent in a relay
chain. Push submission implemented in an IMAP server by speaking SMTP
or SMTP submit out the back end is one sort of proxy.

> I take it the
> right?

Something that forked a sendmail process and spoke to it using whatever
protocol would be a proxy, yes. Actually building a full fledged MTA into the
IMAP server would not be a proxy.

> Is an SMTP submit client in your average MUA a proxy?

No, because it isn't a connection endpoint.

> What does and doesn't constitute one of these things?

The issue is less one of nailing down what is or isn't a proxy than it is
one of the significant and nonobvious complexity involved.

> proxies?

I honestly don't know why they are hard to get right and why they always end up
being so much more complicated than you'd think they need to be. All I can tell
is that they are and do. I have implemented several proxies myself and worked
with many written by other people, and I can assure you that problems are the
rule, not the exception. For example, when I'm presented with some sort of SMTP
glitch for analysis (which happens a couple of times a month on average) the
odds are high that it is caused by a misbehaving proxy. (Next in line are
problems caused by path MTU glitches, and they are a _distant_ second.)

Here's a test question for you that may help illustrate what i mean. Push
submission in an IMAP server needs to provide a way to (a) Discover and (b)
Tunnel through the various SMTP extension the SMTP server on the other side
supports. But there's one particular extension parameter that has to be blocked
and not allowed to tunnel. Quickly: Can you tell me, without scanning a bunch
of documents, what that parameter is?

> Again, perhaps I'm just missing the referent, but I'd be

I'd also be happier if it didn't come down to a matter of trust. But short of
both writing and widely deploying your own proxy as well as working extensively
with ones written by other people, I don't know how you'd ever learn this. It
isn't the intuitively obvious answer, but it is the correct answer neverhtless.

> holding that sort of view, but I don't see where.)

You're assuming that push implementors will get a compoent that appears simple
but which experience has shown to be quite complex and nasty right while pull
implementors won't implement even the most basic and obvious precautions.
That's "smart" versus "dumb" in my book.

> data will be in the store.

I think this is a bad assumption to make. A very significant fraction of
messages are always going to be simple one or two liners with no attachments
and such and hence no need to perform any sort of compositing. I suppose an
implementation could compose all messages using CONCATENATE and then use push
or pull to submit them, but I doubt if the added costs involved in using this
approach will make users happy.

> In the push case, that assumption is

I disagree.

> is there reason to believe that push is *worse*, security-wise, than

My position is that both pull and push have issues. Push is better in some
ways, pull is better than others. And there are some real issues common to
both. Thus far this discussion hasn't really touched on the significant
security differences between the two, which only start to show up when you look
at details like signatures and encryption. But if you assign reasonable weights
to all the issues I think you'll find they are fairly close - certainly close
enough that it is impossible to declare a clear winner on the basis of 
security concerns alone.

Chris and I have done most of the detailed security analysis that's needed
here, but we simply haven't had time to finish up the draft. And the ways
things are going right now I'm not hugely optimistic we're going to be
able to get to this for a while.

				Ned

---

From: Michael StJohns <[email-masked]>
Date: Fri, 02 Apr 2004 16:26:47 -0500

Hi -

I've come to the conclusion I should stay out of the hallway at IETFs...:-)

To boil down my discussions with Pete & Derek - my observation was simply 
that if you concentrate things of value in a certain location, you increase 
the possibility of attack and the value to the attacker if they 
succeed.     With respect to push versus pull I asked the question of how 
many pull tokens would either pass through or be resident at a pull 
server.  Assuming the tokens become invalid when used (tokens are good for 
one pull), then the question of how many are at any given server at any 
given time (as opposed to having passed through)  becomes the interesting 
question when trying to figure vulnerability/value.  A pull server that 
handles only one or two of these over a period of a half hour is obviously 
not a big target - EXCEPT for specific high value files (that's where Ned's 
"change*" attack comes in).  A pull server that may have up to 100-10000 
requests queued at a point in time (and I don't know if that's a reasonable 
or unreasonable number) becomes an interesting target regardless of any 
lack of prior knowledge about the files.

If the tokens are only valid for a specific puller (e.g. something like 
Kerberos tokens) then they have no value at the intermediate point and the 
whole argument relative to push vs pull becomes somewhat moot.  If I 
understood what Mark was saying in his email, that's probably now the case**.

* Change attack - again, assuming the tokens become worthless once used, 
the change attack (assuming a pull system) has to use the tokens fairly 
quickly after they're stolen.  When the pull server attempts to pull the 
files as well and fails (because the token is worthless) provides a pretty 
detectable indication you've been compromised.  A change attack for this 
system becomes a special case of a point attack.  Best use of this one 
would be to target specific high value files on a low pull rate system - a 
"sleeper" attack.

**DISCLAIMER - I haven't read the documents and don't have the nuanced 
understanding of how the protocol will actually do things.  My comments to 
Pete/Derek were based on the information provided in the conversation which 
described the general mechanisms.

Later, Mike

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Apr 2004 11:40:37 -0800

At 9:00 AM -0800 04/01/2004, Mark Crispin wrote:
>created by SIGNURL.  We have furthermore removed anonymous signed 
>URLs as also being unneeded for Lemonade.  Last but not least, the 
>only current mechanism is INTERNAL.

I've asked the author of 2396bis to take a look at this; I've had no reply
yet, but I'm hopeful of getting a review of this from one or more
URI experts in the fairly short term.  In some previous discussions it
sounded as if there would be no problem with using this mechanism
as a token generator for "pawn tickets" which were *not* tied to
the URI (either for this use if there is some URI syntax issue or 
some other uses).
Do these changes affect that possibility?
			regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Apr 2004 12:05:13 -0800 (PST)

On Fri, 2 Apr 2004, Ted Hardie wrote:
> In some previous discussions it
> the URI (either for this use if there is some URI syntax issue or some other 
> uses).

That possibility still exists.  I haven't gone down that route in the hope 
that it will not be necessary; I consider it to be a cosmetic measure that 
adds needless complexity with no real gain in security.  But I also 
understand that cosmetics can make the difference between something 
happening and not happening.

-- Mark --

---

From: Derek Atkins <[email-masked]>
Date: Thu, 01 Apr 2004 12:09:10 -0500

Mark Crispin <[email-masked]> writes:

> In order for a URLAUTH URL to be used, the client to the IMAP server
> (the submit server) must authenticate itself to the IMAP server.  This

Is the authentication of the submit server somehow tied to the URLAUTH
object?  If so, how?  If not, then I don't see how this helps (except
knowing which submit server was used to grab an object via URLAUTH).

identities)?  I can certainly posit a case where I use my "home"

> I think that this addresses most, if not all, of Mike's issues.

I'm not sure it does.  The first question certainly relates to one of
Mike's concerns.

-derek

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Apr 2004 14:48:32 -0800

At 12:05 PM -0800 04/02/2004, Mark Crispin wrote:
>That possibility still exists.  I haven't gone down that route in 
>the hope that it will not be necessary; I consider it to be a 
>cosmetic measure that adds needless complexity with no real gain in 
>security.  But I also understand that cosmetics can make the 
>difference between something happening and not happening.

The intended gain would not be for security, but to ensure that the
behavior of URI parsers would not have unintended interactions
with this mechanism,  There is  a reasonably larger number of
URI libraries in the wild; they have no knowledge of this intended
use of URIs.  If we can preserve correct operation by splitting these 
functions,
it may well be the right thing to do.  I look forward to a review
by Roy to indicate his thoughts on this; if he is not able to
give it adequate time, I'll arrange for the review by one of the
other authors.
			Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Apr 2004 16:50:58 -0800 (PST)

On Fri, 2 Apr 2004, Ted Hardie wrote:
> it may well be the right thing to do.

Ah, I understand now.  The issue was presented to me as being "for 
security".

I don't see how it will make a difference, since the signature is 
deterministic.  Any effort to change the URI in any way will render the 
signature invalid whether or not it is in the URI.

I've also noted quite a bit of HTTP URL usage (e.g. my bank) that does the 
same sort of thing.  So, given that there is precedent *and* that these 
are IMAP URLs (which are unlikely to ever be processed by one of these URI 
libraries), I think that we're OK without it.

My own agenda is that a potential non-Lemonade use for these URLs would be 
broken if the signature isn't in the URL.  As this is non-Lemonade, it 
isn't really a concern for the WG.  On the other hand, the use that I'm 
thinking of may stimulate implementation and deployment of the URLAUTH 
functionality, which in turn would benefit Lemonade use (since a necessary 
feature would be more widely available).

-- Mark --

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Apr 2004 17:11:44 -0500

Sorry for the delay in responding to this.

On 4/1/04 at 10:55 AM -0800, Ned Freed wrote:

>>I take it the "bolt sendmail onto imapd" is a proxy in the worst 
>>possible way, right?
>
>Something that forked a sendmail process and spoke to it using 
>whatever protocol would be a proxy, yes. Actually building a full 
>fledged MTA into the IMAP server would not be a proxy.

Wait, now I'm a little confused, but perhaps I misunderstand the above:

If we design an IMAP command where the client can say to the IMAP 
server "Send this message to this set of recipients" at which point 
the IMAP server takes the message and (as a full fledged MTA (or, I 
take it, submit client)) sends it, that's *not* a proxy?

So, is what's being complained about the ability to pipe SMTP 
commands through the IMAP command?

pr