Subject: Comments on draft-ietf-sieve-3028bis-09 from Eric Rescorla

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Nov 2006 16:54:56 +0000

Eric did security related review. Here are some comments/suggestions from him, slightly reworded by me. Eric will correct me if I misrepresented anything:

1) In section 1:

Eric felt that claims in the following paragraph are overstrong:

  The language is powerful enough to be useful but limited in order to
  allow for a safe server-side filtering system.  The intention is to
  make it impossible for users to do anything more complex (and
  dangerous) than write simple mail filters, along with facilitating
  the use of GUIs for filter creation and manipulation.  The language
  is not Turing-complete: it provides no way to write a loop or a
  function and variables are not provided.

He suggested the following replacement:

  The language is intentionally simple in order to make implementing
  secure implementations easier. However, several Sieve features do
  allow Sieve scripts to consume significant resources and thus
  implementors and administrators must take care to appropriately
  limit the amount of resources consumed by individual users.

2) In section 2.4.1 (talking about numbers):

>  Only positive integers are permitted by this specification.

Eric asked if zero was really not allowed.
I've checked my implementation and it would happily accept 0.

Any objections to changing section 2.4.1 to say "non-negative"?

3) Section 2.10.6:

Eric suggested to drop the following 2 paragraphs:

   Implementations might even go so far as to ensure that scripts can
   never execute an invalid set of actions before execution, although
   this could involve solving the Halting Problem.

   This specification allows any of these approaches.  Solving the
   Halting Problem is considered extra credit.

Eric said: solving the halting problem is not actually a problem with FSMs.

Any objections?

---

From: EKR <[email-masked]>
Date: Mon, 06 Nov 2006 09:42:32 -0800

Ned Freed <[email-masked]> wrote:

> I don't think this is an appropriate change. In particular, I think it is
> important to keep the language about sieve not being TUring complete. I have no
> objection to toning down the claims (although I do think it is unnecessary),
> but it is critical that we document the underlying language design philosophy.

OK, but the problem is that the text above isn't correct.  The language
*does* have loops, and draft-ietf-sieve-variables-08 defines variables.
Indeed, it's not clear to me that the langague isn't Turing complete at this
point.

-Ekr

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 09:45:26 -0800 (PST)

> *does* have loops,

Really? That's news to me. The loop construct that has been proposed for sieve
isn't a loop in the usual programming language sense - rather, it allows for
fixed iteration over the MIME structure of the message. AFAIK there's no way to
create an infinite loop or even a loop where the number of iterates is set by
the script. And this is in any case an extension, not something in the core
language.

> and draft-ietf-sieve-variables-08 defines variables.

Again, this is an extension, not a component of the core specification. It was
done this way for a reason - it is well known that variables introduce resource
consumption issues (as does body part iteration). Regardless, as I said, I
would have no problem  losing this claim.

> Indeed, it's not clear to me that the langague isn't Turing complete at this

Then please provide a script that loops indefinitely. I don't know how to
construct one myself.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 09:30:08 -0800 (PST)

> Any objections to changing section 2.4.1 to say "non-negative"?

Yes, positive is wrong, non-negative is correct.

> Eric said: solving the halting problem is not actually a problem with FSMs.

No, but satisfiability is. NP-complete is a pretty tough nut to crack. I
suggest changing the statement to more accurately describe the complexity
of this problem.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 6 Nov 2006 19:00:11 +0100

[email-masked] writes:
> OK, but the problem is that the text above isn't correct.  The 
> language *does* have loops, and draft-ietf-sieve-variables-08 defines 
> variables.

Sieve has if/then/else and some set operations, but does it have loops?

Arnt

---

From: EKR <[email-masked]>
Date: Mon, 06 Nov 2006 10:12:36 -0800

> the script. And this is in any case an extension, not something in the core

As I observed in my original review, I believe you may be able to
construct a loop using the redirect construct. It's not a loop internal
only to the sieve-processing MTA, but that doesn't mean it's not a loop.

> Then please provide a script that loops indefinitely. I don't know how to

Well, I'm no mail expert, but it looks to me that if you write a
redirect rule that goes to an unknown address, it may be possible
to create a loop. The key question is what the envelope sender
address is, which sieve leaves open (S 4.2).

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation.  It MAY be copied from the original message.

If you your own address, this creates a loop, right?

-Ekr

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 10:19:39 -0800 (PST)

> only to the sieve-processing MTA, but that doesn't mean it's not a loop.

First of all, a message forwarding loop is a totally different sort of beast,
one that has no bearing on the computational complexity and difficulty of 
processing a single sieve script, which is all we're talking about here.
Discussion of message loops is a huge and involved topic that has almost
nothing to do with sieve - and sieve doesn't add or subtract anything from the
existing landscape in this area.

Second, sieve redirect is neither necessary nor sufficient to create such
loops. Pretty much any forwarding mechanism in existance can be used to create
them. But as a direct consequence of the ease with which such loops can be
created, messaging standards have for decades required that compliant systems
check for and prevent such loops from occuring. (As I hope you're aware, common
mechanisms for dealing with the simpler forms of loops involve counting
Received: fields, adding your own tag somewhere, and so on.)

> If you your own address, this creates a loop, right?

Not with any reasonably implemented messaging system, no. Given the existance
of forwarding mechanisms that change envelope addrresses (as you say, redirect
may do this in some implementations, but there are plenty of other
autoforwarders out there that this a lot more often than sieve interpreters
do), one of the checks you need to make is to see whether or not you're dealing
with a deeply nested DSN, and if you are, refuse to transfer the thing.

A more interesting case arises in the sieve notify extension (currently in
draft). Since this for the creation of an entirely new message that can be sent
right back to same sieve script, it is possible to construct loops where each
time around you're dealing with a completely different message with nothing in
common with its predecessors. This case definitely needs to be looked at before
notify is standardized.

				Ned

---

From: EKR <[email-masked]>
Date: Mon, 06 Nov 2006 10:55:59 -0800

> processing a single sieve script, which is all we're talking about here.

Well, I think this is a reasonable point, but not one with which I
entirely agree. The larger security question is what the impact of
allowing partly-untrusted users from putting sieve scripts on
one's server is, and this kind of message forwarding loop is relevant
for that.

-Ekr

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 06 Nov 2006 11:12:55 -0800

Hi Ned,

--On November 6, 2006 10:19:39 AM -0800 Ned Freed <[email-masked]> 
wrote:

> draft). Since this for the creation of an entirely new message that can
> be sent right back to same sieve script, it is possible to construct
> loops where each time around you're dealing with a completely different
> message with nothing in common with its predecessors. This case
> definitely needs to be looked at before notify is standardized.

mime-loop enclose action also generates a 'new message' that could cause 
this, I think.

-- 
Cyrus Daboo

---

From: Michael Haardt <[email-masked]>
Date: Mon, 06 Nov 2006 21:33:45 +0100

> common with its predecessors. This case definitely needs to be looked at before

My suggestion is to keep all Received: header fields.  I can't think of
a more effective way to prevent loops.

Michael

---

From: Aaron Stone <[email-masked]>
Date: Mon, 06 Nov 2006 13:10:21 -0800

> Eric said: solving the halting problem is not actually a problem with FSMs.

Does that mean I can drop haltingsolution.c from my implementation? ;-)

On a serious note, I rather like the humor here. Could we incorporate it
in a revision? Perhaps something like:

    Implementations may go so far as to ensure that scripts can not be
    activated or execute with an invalid set of actions. Because Sieve
    is intentionally not Turing-complete, this involves only an FSM
    generator and not a Halting Problem solver.

Aaron

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 13:15:34 -0800 (PST)

> one's server is, and this kind of message forwarding loop is relevant

Given that many clients have the ability to autoforward without any server-side
involvment at all or with any sieve support, I'm having a hard seeing this as a 
problem sieve brings to the table and therefore deserves lots of attention in
the sieve context. Even so, I have no objection to adding some language
discussing mail loops specifically to the security considerations section. The
real question is how far should this go? Simply saying that sieve redirect is
another autoforwarding mechanism that can be complicit in mail loops might
alert someone to the issue (although anyone who deals with email implementation
is likely to be well aware of it already), but doesn't explain the bag of
tricks needed to deal with the issue. An entire document can (and arguably
should) be written about this stuff, but this WG really isn't the right place
to do all that.

The more complex issues that some sieve extension raise definitely need to be
dealt with in the documents describing those extensions. In the case of notify
specifically I think it is really important that a standard loop detection
mechanism be defined, because if we leave it up to each implementation to come
up with a way to do it two or more party loops involving systems using
different detection mechanisms are still possible.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Nov 2006 19:21:14 -0800 (PST)

> a more effective way to prevent loops.

I guess it would work - although it would probably trip loop detectors
too soon in some cases - but I don't think an appproach that effectively calls
for a message to lie about where it has been is a good idea.

I think we need another mechanisms, probably header-based.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 10 Nov 2006 11:13:22 +0100

Ned Freed writes:
> too soon in some cases - but I don't think an appproach that 
> effectively calls for a message to lie about where it has been is a 
> good idea.

AOL. There aren't any RFCs that say "Don't insert inaccurate Received 
fields", but it still seems to have very bad karma ;)

> I think we need another mechanisms, probably header-based.

"Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 3834 
orders autoresponders to be careful about incoming auto-submitted 
messages. If similar language is added to the relevant sieve documents, 
the result should be fine. At least in theory.

Arnt

---

From: Michael Haardt <[email-masked]>
Date: Fri, 10 Nov 2006 11:09:58 +0100

> I think we need another mechanisms, probably header-based.

Unless you come up with a widely accepted standard for that, that is
not going to work, because other sites may not evaluate such headers.

Notifications are in a way very similar to redirects, only forwarding not
the original message, but a summary.  In fact many people use redirect
in absence of notifications.

Redirect has the same problem of coming closer to the limit where a
loop is being assumed, but it rarely causes trouble.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Fri, 10 Nov 2006 11:22:11 +0100

> the result should be fine. At least in theory.

Did I just say "a header-based solution won't work unless widely
accepted"? I completely forgot about "Auto-Submitted:", thanks for
the reminder!

This WG is great. :)

Michael

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 10 Nov 2006 12:29:24 +0100

Michael Haardt writes:
>>  "Auto-Submitted: auto-generated" is defined in RFC 3834 section 5. 
>>  3834 orders autoresponders to be careful about incoming 
>>  auto-submitted messages. If similar language is added to the 
>>  relevant sieve documents, the result should be fine. At least in 
>>  theory.
>

Ah, uhm, widely accepted, ah, uhm... but I rather think Auto-Submitted 
is the right answer. Some people will of course not check/generate 
Auto-Submitted, but IMNSHO nothing a Sieve RFC says can make a 
diferrence to them. (My unfavourite autoresponder is in a package that 
also says "Date: 31 Nov ..." - until the software starts to obey 
822/2822 I don't even dare to hope it'll obey 3834 or Sieve RFCs.)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Fri, 10 Nov 2006 10:08:39 -0800 (PST)

> the result should be fine. At least in theory.

The main issue with using Auto-submitted: is that it would block all cases of
notifications sent in response to other notifications. Received: field counting
stops loops at some point but doesn't prevent a reasonable amount of
autoforwaring to occur before loop detection kicks in.

I just don't know if it is OK to block all notifications in response
to notifications. What do others think?

				Ned

P.S. Full disclosure: Blocking notification responses to notifications would
eliminate a major layer 9 problem for our product team.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 10 Nov 2006 21:19:38 +0100

Ned Freed writes:
> The main issue with using Auto-submitted: is that it would block all 
> cases of notifications sent in response to other notifications.

Not necessarily.

The rule could be phrased so that a simple implementation does just 
that, but a more complex one can use persistent storage to allow 
one-interation "loops" and remain safe and compliant.

I _might_ decide to implement a rule like "don't notify if incoming 
message is auto-submitted and the notification would go to an address 
I've recently notifified while processing this sieve script". (Sharing 
code with "don't notify if I've recently sent umpteen notifications to 
the same address while running this sieve script".)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 10 Nov 2006 21:29:57 +0100

Ned Freed writes:
> Received: field counting stops loops at some point but doesn't prevent 
> a reasonable amount of

Actually, I wasn't proposing to use Auto-Submitted for autoforwarding. 
I'd say that Auto-Submitted should be used iff the message sent is a 
new message, with a new message-id etc. If the sieve script reinjects 
the received message (same subject, same header fields generally, same 
bodies) IMO the existing Received fields should be preserved and one 
added.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 12 Nov 2006 11:40:09 -0800 (PST)

> one-interation "loops" and remain safe and compliant.

I don't see how this can work. The problem with notification loops is that in
general each notification in turn may have _nothing_ in common with any
previous message, not even the address of the sender or recipient. So your
persistant storage lets you catch the loop... how exactly? When the messages
have nothing in common, there's nothing in common to put in your persistent
storage for comparison purposes.

And even if you assume that, say, the sender address is going to be the same
each time around (all it takes is the presence of something like per-message
subaddressing or SRS for this not to be true) so there's something to store,
the heuristic has to include some sort of rate measuring since the indicators
are not unique to any particular message. The resulting heuristics are going to
be far more brittle than Received: line counting: With Received: line counting
a limit that's set too high simply allows the loop to go on a little bit longer
than it should, but with a rate-based scheme setting the limit too high breaks
loop detection completely.

> the same address while running this sieve script".)

This assumes that the recipient address of the notification is the same every
time. It may not be - people like to do stuff like embed current time
information in a subaddress. Indeed, the need to do these types of operations
is one of the primary motivators for having the currentdate test as part of
Sieve - right now people who want to do this sort of thing are forced to use
some other mechanism like procmail.

I'm also quite uncomfortable with the storeage requirements this sort of thing
imposes on notification implementations. One of the characteristics I've
observed with notifications is that when they are used at all the usage is much
heavier than otherother mechanisms with storage requirements like vacation.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 12 Nov 2006 15:29:41 -0800 (PST)

> Actually, I wasn't proposing to use Auto-Submitted for autoforwarding.

I didn't say you were. All I was saying is that Received: line counting is a
reasonable way to prevent loops in pure autoforwarding scenarios.

> bodies) IMO the existing Received fields should be preserved and one

Agreed, and IMO we should state this in the base specification's discussion
of redirect if it doesn't do so already.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Sun, 12 Nov 2006 18:01:47 -0800

On Sun, 2006-11-12 at 15:29 -0800, Ned Freed wrote:

> Agreed, and IMO we should state this in the base specification's
> discussion of redirect if it doesn't do so already.

3028bis-09 still makes reference to .forward behavior, although there
are more details since I asked for clarification on what,
exactly, .forward behavior actually is a few months ago :-)

I'm not aware of any particular best practices document about how to
handle forwarding / redirecting mail, so basically we should either
reference one or write the best practices into the base spec as needed.

Aaron

---

From: Ned Freed <[email-masked]>
Date: Tue, 14 Nov 2006 11:38:09 -0800 (PST)

> reference one or write the best practices into the base spec as needed.

Agreed. In particular, we should be explicit about preserving Received: fields
when redirecting and that redirection should result in the addition of 
a Received: field. We don't want to be explicit about who does any of this
since that's going to vary from one implementation to the next.

				Ned