Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Thank you all for the discussion on this!  It's helped to clear up some
points, at least for me.  Proposed text to be altered if needed is included
in-line.


On Tue, Jun 24, 2014 at 9:59 AM, Pete Resnick <[e-mail]>
wrote:

> On 6/24/14 5:03 AM, Kathleen Moriarty wrote:
>
>  In any case, I did read it wrong and would like some explicit text that
>>>> says what is deleted.
>>>>
>>>>
>>> Nothing is deleted, as such.  The document is quite clear that if a
>>> message comes in, and its unique ID is already in the list, then a
>>> "duplicate" test returns "true".  I don't see that anything more needs
>>> to be said about that.  The duplicates are only deleted if the script
>>> says to do that ("if duplicate then discard;").  The script can use
>>> other actions in addition or instead.
>>>
>>>
>> Deleting is one of the options in the intro.  Can you read through the
>> draft again as it does not clearly state what is getting moved to a folder
>> or deleted (if they choose to) - original message or messages in the queue.
>>  I kinda think that's important and led to my misread of a key point.
>>
>>
>
> So let's be clear: The document itself doesn't define *anything* to do
> once you've determined that you have a duplicate by using this test;
> Barry's right on this point. You could delete the message, or store it in
> some folder, or delete the original and keep the duplicate, or delete all
> of your mailboxes, or spam the entire world. After all, it's a test in a
> script. And we certainly don't want to say, "Security consideration: Using
> this test could delete all of your mailboxes or spam the entire world".
> That would be silly.
>

Sure, agreed. I wasn't debating that point and think it is clear that the
script takes the action, not the duplicate feature.

In Section 3, how about adding a sentence to the end of this paragraph
(paragraph, then proposed sentence):

   In its basic form, the "duplicate" test keeps track of which messages
   were seen before by this test during an earlier Sieve execution.
   Messages are by default identified by their message ID as contained
   in the Message-ID header.  The "duplicate" test evaluates to "true"
   when the message was seen before and it evaluates to "false" when it

      was not.

Proposed sentence:
     Any possible actions to subsequently received duplicate messages would
be determined by a script in the Sieve filter.


> What I'm ambivalent about is whether this document should strengthen the
> last paragraph of section 3 (whether there or in the Sec. Cons. section) to
> be clear that Message-IDs are not necessarily unique, either through the
> fault of benign generators who just don't do such a good job, or through
> some attacker trying to do something obnoxious, and therefore script
> writers should be conservative in taking action based solely on the
> Message-ID indicating a duplicate. (And to be sure, this is only a warning
> to script writers about what is or is not reasonable; it's not a particular
> vulnerability in this new mechanism. A script writer could delete all of
> its mailboxes or spam the entire world based on all sorts of things
> available in sieve.)
>
> So, your call. Maybe worth adding something. But there needn't be any
> grand warnings of impending horror.


I agree here and thanks for the clear write up.  A warning is all I was
looking to see added to cover our bases on pointing out security
considerations with using this added feature.

Script writers using the duplicate test evaluation should be aware that
Message-IDs are not necessarily unique either through the fault of benign
generators or attackers at some point prior to the Sieve filter injecting a
message with the properties used by the duplicate Sieve filter.  As such,
script writers may opt to be conservative when considering actions taken on
duplicate messages.

Edit away!

Thanks!
Kathleen


> pr
>
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
>
>


-- 

Best regards,
Kathleen