Subject: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 May 2011 22:09:06 -0700

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-melnikov-sieve-external-lists
Title:  Sieve Extension: Externally Stored Lists
Reviewer: Murray S. Kucherawy
Review Date: May 2, 2011
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This draft is almost ready for publication as a Standards Track RFC, modulo a few points I'd like to mention below.

Major Issues:
1. Altering list behaviour based on data available external to the Sieve processing code means alteration of such data presents a vector for attack.  The Security Considerations section should mention this.  It does mention some related issues (e.g., authentication) but not the one I have in mind, namely that the outcome of the Sieve script becomes dependent on external data not necessarily under direct control of the user.

Minor Issues: 
1. Since the document references the possibility of storing lists in external relational databases, I was surprised not to see a specific reference to how one might be used.  Is it the case that no URI schema exists yet for referring to, say, an SQL query?  If such does exist, an example of this would be good to include, but certainly not required (especially if such a schema has yet to be registered).

Nits:
1. ":list" is sometimes quoted in the document and sometimes not.  It should be consistent throughout.

Apart from those, it's pretty clean.  Nicely done!

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 11:03:16 -0400

Thanks for the review, Murray.

> Document: draft-melnikov-sieve-external-lists
It hasn't been that for a long time, and the correct current version
is draft-ietf-sieve-external-lists-07 :
http://tools.ietf.org/html/draft-ietf-sieve-external-lists

> Major Issues:
> 1. Altering list behaviour based on data available external to the Sieve processing
> code means alteration of such data presents a vector for attack.  The Security
> Considerations section should mention this.  It does mention some related issues
> (e.g., authentication) but not the one I have in mind, namely that the outcome of
> the Sieve script becomes dependent on external data not necessarily under direct
> control of the user.

Hm.  I'd have thought that to be sufficiently obvious as not to
require mention -- we *are* going out to an *external* list, after
all.  But I'm happy to put something in for that, sure.  How about
inserting the following paragraph after the one about "confidentiality
and authentication"?:
-------------
Having the processing and outcome of a Sieve script depend on the contents
of external data can allow someone with control of the external data to have
unusual, and perhaps unauthorized, control of the script -- and, consequently,
of the disposition of the user's email.  A user using such a list for
spam control,
for example, might find important mail being discarded because of tampering
with the list.  Someone using redirect to an external list could have her email
redirected to the wrong eyes because of such tampering.  Security and integrity
protection of external lists is as important as protection of the Sieve script
itself.
-------------

> 1. Since the document references the possibility of storing lists in external
> relational databases, I was surprised not to see a specific reference to how
> one might be used.  Is it the case that no URI schema exists yet for referring
> to, say, an SQL query?  If such does exist, an example of this would be good
> to include, but certainly not required (especially if such a schema has yet to
> be registered).

As I've said on the mailing lists about examples: I'm a fan of having
many examples, and I'll be happy to add more if someone would provide
me with specific text.  I'm loath to try to concoct more off the top
of my head at this point, and will rely on dependable submissions.

> It should be consistent throughout.

It should; I've changed that in my working version.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 08:10:29 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, May 06, 2011 8:03 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists
> 

Sorry, yes; I copied it from the top of that URL which has a link to the original name.  I did look at the newest one.

> of the disposition of the user's email.  A user using such a list for spam control,

That or something like it would be ideal.

> of my head at this point, and will rely on dependable submissions.

Fair enough, and I'm not even sure there's an SQL URI scheme yet upon which to base one.  It just seems an obvious one to add since it's referenced.

> It should; I've changed that in my working version.

Thanks!

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 May 2011 20:42:29 +0100

Hi Murray,

>Fair enough, and I'm not even sure there's an SQL URI scheme yet upon which to base one.  It just seems an obvious one to add since it's referenced.
I don't know of any URI scheme related to SQL.