headers
Alexey Melnikov | 3 Nov 2006 17:54
Favicon

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


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.
(Continue reading)

Permalink | Reply | 23 comments |
headers
Ned Freed | 6 Nov 2006 18:30

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


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

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.

> 2) In section 2.4.1 (talking about numbers):
(Continue reading)

Permalink | Reply | 21 comments |
headers
EKR | 6 Nov 2006 18:42

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


Ned Freed <ned.freed <at> mrochek.com> wrote:

> > 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.
> 
> 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.
(Continue reading)

Permalink | Reply | 20 comments |
headers
EKR | 6 Nov 2006 19:12

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


Ned Freed <ned.freed <at> mrochek.com> wrote:
> > Ned Freed <ned.freed <at> mrochek.com> wrote:
> > OK, but the problem is that the text above isn't correct.  The language
> > *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.

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.

> > Indeed, it's not clear to me that the langague isn't Turing complete at this
> > point.
> 
> Then please provide a script that loops indefinitely. I don't know how to
> construct one myself.

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.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ned Freed | 6 Nov 2006 18:45

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


> Ned Freed <ned.freed <at> mrochek.com> wrote:

> > > 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.
> >
> > 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.
(Continue reading)

Permalink | Reply | 18 comments |
headers
Arnt Gulbrandsen | 6 Nov 2006 19:00
Picon
Favicon
Gravatar

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


ekr <at> networkresonance.com 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
Permalink | Reply | 0 comments |
headers
Ned Freed | 6 Nov 2006 19:19

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


> Ned Freed <ned.freed <at> mrochek.com> wrote:
> > > Ned Freed <ned.freed <at> mrochek.com> wrote:
> > > OK, but the problem is that the text above isn't correct.  The language
> > > *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.

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

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
(Continue reading)

Permalink | Reply | 16 comments |
headers
EKR | 6 Nov 2006 19:55

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


Ned Freed <ned.freed <at> mrochek.com> wrote:
> > 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.
> 
> 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.

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
Permalink | Reply | 1 comment |
headers
Cyrus Daboo | 6 Nov 2006 20:12
Favicon

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


Hi Ned,

--On November 6, 2006 10:19:39 AM -0800 Ned Freed <ned.freed <at> mrochek.com> 
wrote:

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

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

--

-- 
Cyrus Daboo
Permalink | Reply | 0 comments |
headers
Michael Haardt | 6 Nov 2006 21:33
Picon

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


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

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

Michael
Permalink | Reply | 12 comments |

Gmane