Subject: Re: [sieve] [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 2

From: Robert Burrell Donkin <[email-masked]>
Date: Fri, 4 Sep 2009 11:29:02 +0100

On Thu, Aug 27, 2009 at 11:13 PM, Alexey
Melnikov<[email-masked]> wrote:
> Robert Burrell Donkin wrote:
>
>> <blockquote
>> cite='http://www.ietf.org/id/draft-ietf-sieve-external-lists-00.txt'>
>>  A failure to retrieve data due to the server storing the external
>>  list membership being down or otherwise inaccessible may alter the
>>  result of Sieve processing.  So implementations SHOULD treat a
>>  temporary failure to retrieve or verify external list membership in
>>  the same manner as a temporary failure to retrieve a Sieve script.
>>  For example, if the Sieve script is stored in the Lightweight
>>  Directory Access Protocol (LDAP) and the script can't be retrieved
>>  when a message is processed, then the agent performing Sieve
>>  processing can, for example, assume that the script doesn't exist or
>>  delay message delivery until the script can be retrieved
>>  successfully.  External list memberships should be treated as if they
>>  are a part of the script itself, so a temporary failure to retrieve
>>  them should be handled in the same way as a temporary failure to
>>  retrieve the Sieve script itself.
>> </blockquote>
>>
>> how does this error handling behaviour improve security?
>>
>
> This improves consistency of Sieve processing.

i fail to see why this is seen as a security issue

could anyone provide an example illustrating how an attacker could use
an implementation inconsistency in error handling to compromise a
sieve server?

> If there is WG consensus to change this, then I would argue we would need a
> mechanism to detect membership verification failures using a new test (or a
> modifier to existing one).
>
>> what are the advantages of this new error handling language to that
>> already established in RFC 5228?

i fail to see the security reasoning justifying deviation from the
error handling laid down in the basic Sieve langauge specification

could anyone provide an example illustrating how flaws in the original
Sieve specification's approach to error handling necessitate the
adoption of an alternative strategy in this new specification?

- robert

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 06 Sep 2009 19:17:20 +0100

>an implementation inconsistency in error handling to compromise a
Consistency makes security analysis simpler.

I suppose this can be moved out of the Security Considerations to 
another section. How would you suggest to name such section?

>error handling laid down in the basic Sieve langauge specification
I actually disagree. The proposed error handling makes it consistent 
with the base specification. The idea behind the text is as follows: if 
there is a Sieve script that contains the list of all members in the 
script itself, the Sieve script processing shouldn't change when the 
script is changed to use external lists and all previously inlined 
members moved to an external list.

Besides, exactly the same wording was used in RFC 5490 and nobody in the 
WG complained when it was last called.

>adoption of an alternative strategy in this new specification?
See above.

---

From: Robert Burrell Donkin <[email-masked]>
Date: Mon, 7 Sep 2009 12:06:48 +0100

> Consistency makes security analysis simpler.

IMHO this only merits at most a sentence describing how consistent
error handling was considered with security in mind

> I suppose this can be moved out of the Security Considerations to another
> section. How would you suggest to name such section?

clear error handling rules are important for implementors and a
consistent approach does make security analysis easier. this should be
moved to a section dealing with error handling.

> I actually disagree. The proposed error handling makes it consistent with
> the base specification. The idea behind the text is as follows: if there is
> a Sieve script that contains the list of all members in the script itself,
> the Sieve script processing shouldn't change when the script is changed to
> use external lists and all previously inlined members moved to an external
> list.

the current solution does not achieve this aim

the base specification describes two clearly error handling
strategies. when a internal list is incorrect then either a compile
time or runtime error should be raised by the engine (as described in
the specification). the proposal adds a novel (and quite ill defined)
error type and therefore introduces a change in behaviour for some use
cases when a list is move from internal to external.

> Besides, exactly the same wording was used in RFC 5490 and nobody in the WG
> complained when it was last called.

IMHO a mistake in one specification should not be used to justify it's
propogation

perhaps better reviewing would have spotted this inconsitency with the
original sieve language specification

- robert

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Sep 2009 23:35:27 +0100

>>>>>retrieve the Sieve script itself.
 [...]

>>>>mechanism to detect membership verification failures using a new test (or
>>>>a modifier to existing one).
>>>>        
>>>>
Let step back a bit. Sieve scripts are frequently stored/retrieved in 
LDAP, NFS and other similar types of storage. An implementation that 
wants to invoke a Sieve script for a user would needs to retrieve it 
first. This can fail, for example an attempt to read a Script from a 
file can fail due to disk failure.
What happens on such failure is implementation specific. It also happens 
before the Sieve script is invoked at all, so arguably there is no 
contradictions with the base Sieve document.

What you are suggesting is that that should be handled as a runtime 
error (at this point it is too late for a compile time error, the script 
is already installed). A runtime error means implicit keep. So you are 
suggesting that a failure to retrieve a Sieve script should equate to 
running a Sieve script containing "keep;". I don't think this is a good 
suggestion.

Let's consider my suggestion in case of SMTP/LMTP delivery. LMTP server 
is going to receive the email message and retrieve script for the user 
associated with RCPT TO from an LDAP server. If there is a failure to 
retrieve the script, then LMTP server can treat this as a temporary 
error to deliver to the user. So it will respond with 4XX response and 
the sender will retry email delivery later. At a later time the LDAP 
server might become available again and the correct Sieve script will be 
executed.

>IMHO a mistake in one specification should not be used to justify it's
True, if we can come to consensus that this was indeed a mistake.

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Sep 2009 22:41:49 -0700 (PDT)

> file can fail due to disk failure.

Very true, but the ability to handle this error at the time the scipt is
fetched does not translate into an ability to signal such a failure during
sieve execution. It certainly isn;t in our implementation, where implementing
this form of error handling during script evaluation is going to be a *major*
PITA.

> running a Sieve script containing "keep;". I don't think this is a good

I have to agree. I don't think this is a viable option and I'm afraid
that what the text currently suggests is the best we can do.

The only other alternative I can think of is for a failed test due to an
underlying list problem to set some sort of variable. But that forces scripts
to handle the condition, which is very ugly.

> server might become available again and the correct Sieve script will be

It may be straightforward when dealing with a simple LMTP server-based
implementation, but let's please not forget that such implementations have the
serious issue that errors reported after message data transfer cannot in
general be reflected back as an SMTP error.

But while I don't like the current approach much, I have no better replacement
to suggest.

				Ned

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 08 Sep 2009 02:54:09 -0400

> general be reflected back as an SMTP error.

No, but one could certainly treat lists referenced in this way as a part of 
the data needed to run the script, and fetch them up front, before the 
script begins executing.  Of course, that presumes that one can "fetch" the 
list.  The problem becomes much worse when the list is a query-only 
service, because then you're going to need to talk to the service while 
running the script, and _that_ could fail.

-- Jeff

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Sep 2009 07:31:08 -0700 (PDT)

> running the script, and _that_ could fail.

For us at least, unfetchable lists are looking to be the rule, not the
exception.

I can't get into specifics, but we have one customer who is building an
application on top of the external lists mechanism and who has decided to use a
list of hashes rather than the original data in order to save space. Why?
Because they have calculated that if they store the original data they're going
to need 17 Gb more real memory in each of their database servers.

				Ned