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

From: Stephan Bosch <[email-masked]>
Date: Mon, 23 Jun 2014 21:46:41 +0200

Hi Kathleen,

On 6/23/2014 8:49 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-appsawg-sieve-duplicate-07: Discuss
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The security considerations seem light, shouldn't there be a security
> consideration for the possibility of overwriting a message with another? 
> If an attacker wants to prevent someone from receiving a certain version
> of a message, couldn't this be used to achieve that goal?  I don't see
> anything to prevent this, with the exception of good security practices,
> trusted administrators, and monitoring for any tampering on sending
> servers.  I'm not looking for too much of a description, but a statement
> on this possible risk.

Replacing a targeted message with a falsification needs to occur before
the targeted message arrives at the Sieve interpreter, otherwise it is
already delivered. For the default use of the "duplicate" extension,
that requires predicting the Message-ID and ensuring that the attacker's
message arrives before the targeted message. Furthermore, it requires
knowledge of the Sieve script at the receiving end, especially if
":header" or ":uniqueid" are used.

This risk seems minimal to me. Therefore, I am not sure whether I
understand the mechanism of the attack you describe. Could you elaborate?

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jun 2014 17:36:22 -0400

> Does the above help?

Not to me.  Let me see if I can tease out the threat you're suggesting
by asking a few questions.

1. I presume the point here is for an attacker to prevent you from
getting a particular message.  Secondarily, the attacker will be
sending you a message, but anyone can do that anyway, so I don't see
the issue there.  First question: Is this correct, that the attack
involves blocking a particular message (having it discarded by your
delivery agent).

2. The attacker would need to know that your script is using this
feature, so let's presume for now that this feature is very widely
adopted.  The normal mode of use would be "if duplicate then discard",
so the unique ID would be the Message-ID field.  Does this assumption
match the threat you imagine?

3. How is the attacker going to determine the Message-ID of a message
that you will get, but that you haven't gotten yet, and that the
attacker wants to block?  Message-ID values are not predictable.

4. Assuming the attacker can figure out a Message-ID to attack, how is
the attacker going to get her message delivered before the one she
wants to block?  That's the only way to have the blocked message be
discarded by this feature.

5. Given that an attacker would have to come up with a Message-ID to
use for the attack, and then get her message delivered first so that
the legitimate message is the one that's considered the discardable
duplicate, do you really think this is real threat?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Jun 2014 15:18:45 -0700

> attacker wants to block?  Message-ID values are not predictable.

Well, that's not entirely true. Most Message-IDs are generated using 
some algorithm that could conceivably be known and re-created: It is 
certainly true that most Message-IDs use the current date and time as 
part of the left-hand-side, along with other information, in a 

> discarded by this feature.

Imagine that I want you not to get a piece of mail that is sent out at 
the end of the month telling you some important piece of information 
(like the number of failed log-in attempts to your account, or the 
number of traffic tickets issued for a particular truck you own). I know 
that the service sending this mail always sends on the first of the 
month at midnight exactly, and I know the algorithm that they use to 
generate Message-IDs, **and it doesn't include some randomly generated 
gobbledygook as part of it.** If I send you a message just prior to when 
you're supposed to get your important message with the Message-ID I was 
able to predict and recreate, I can get you to discard the message.

Now, the big question is: Do people algorithmically generate Message-IDs 
without random gobbledygook? I don't really know the answer to that. But 
given that 5322 doesn't require a particular algorithm that includes 
random data, it's certainly possible that this could be used for ill.

> duplicate, do you really think this is real threat?

I'm not sure.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jun 2014 18:29:47 -0400

> Imagine that I want you not to get a piece of mail that is sent out at the
> end of the month telling you some important piece of information (like the
> number of failed log-in attempts to your account, or the number of traffic
> tickets issued for a particular truck you own). I know that the service
> sending this mail always sends on the first of the month at midnight
> exactly, and I know the algorithm that they use to generate Message-IDs,
> **and it doesn't include some randomly generated gobbledygook as part of
> it.** If I send you a message just prior to when you're supposed to get your
> important message with the Message-ID I was able to predict and recreate, I
> can get you to discard the message.

Oh, please: this is a movie-plot threat most bizarre.  It requires a
specific situation, a specific implementation, and so much advance
knowledge that you might as well put on a tinfoil hat.

I honestly can't countenance putting advice about these flights of
imagination into all of our RFCs.  Really, Pete?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jun 2014 18:31:26 -0400

On re-reading this, I think my response comes off as rude, when I
didn't intend that.  I did mean to dismiss your suggestion as silly,
but I did not mean to dismiss it rudely.  Sorry.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Jun 2014 15:44:35 -0700

> but I did not mean to dismiss it rudely.  Sorry.

No offense taken. I took it as good-natured poking fun.

On the actual point:

> On Mon, Jun 23, 2014 at 6:29 PM, Barry Leiba<[email-masked]>  wrote:
>    

First, I only write these movie scripts; I ain't no critic. ;-)

More seriously, I don't think this is a big wide gaping security hole. 
But this is a relatively novel use of Message-ID, and there may be folks 
who use crappy Message-IDs who haven't thought of the possibility of 
someone discarding a message that has an identical Message-ID. This is 
more an operational problem than a security one, and still likely not a 
big one. But it's worth the thought.

For me, this feature is likely to cut down on spam, as certain spammers 
have the (convenient) habit of reusing the same Message-ID.

pr

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jun 2014 16:02:25 -0700

> but I did not mean to dismiss it rudely.

We should consider memorializing this bit of text as a universal IETF
classic squib.  Our version of an apology for all seasons...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 23 Jun 2014 16:53:43 -0700

On Jun 23, 2014, at 3:18 PM, Pete Resnick <[email-masked]> wrote:

> Well, that's not entirely true. Most Message-IDs are generated using some algorithm that could conceivably be known and re-created: It is certainly true that most Message-IDs use the current date and time as part of the left-hand-side, along with other information, in a well-known order. 

Message-Id came along as a target for the References header.  It was intended to be unique, but not cryptographically so.

A cheap way to build a Message-Id was sprintf(foo, "%d.%d@%s", getpid(), ctime(NULL), gethostname());

At the time, that was pretty much guaranteed to generate a suitably unique value.

It was never intended – let alone anticipated – that the message-id should be a cryptographically anonymous value.

You cannot assume any properties of a Message-ID, other than what fits the syntax of RFC822.  

--lyndon

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Jun 2014 06:54:22 -0400

> Actually, not so bizarre.  You'd be surprised the lengths folks go to as
> part of spear phishing attacks.  These are real attacks because they
> are effective.  This feature could be used as part of one.

No, it can't.  It neither prevents nor abets phishing, and I can't
imagine the scenario where it could.

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

> I think there should also be a statement similar to Lyndon's response
> on the fields used and possible risks.  Even include it is not likely.

I think it's a very bad idea to start putting descriptions of wildly
odd things that people contrive, and calling them "threats", into
every RFC.  It distracts us from the *real* issues that people need to
worry about when they're deploying this stuff.

This is simply NOT a real threat.  Let's not call it one.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Jun 2014 09:57:05 -0400

> For Spear phishing, yes, this is possible.  Martin explained a feasible example.

What Martin described isn't phishing.

But let's cut out the flailing:
Please post specific text that would address your concern, so we can
evaluate it.  Maybe that'll get this resolved better.

> Deleting is one of the options in the intro.

It's an example; there are also two other examples of how duplicates
can be handled, there in the same sentence.  This extension only
provides a test that returns "true" or "false".  What the script does
with that test is up to the script.

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

The document repeated refers to "duplicates" and "duplicate messages".
If I handed you something, then later handed you an identical thing,
would you ever consider the *first* one to be the duplicate?  I can't
imagine.  It's clear that it's the second (and subsequent) arrivals
that are "duplicates" of the first.

Section 3 lays out how it works.  The first time we see a given unique
ID, the test returns false and the unique ID is added to the duplicate
tracking list.  If we ever see the same unique ID again, the
"duplicate" test returns "true".  I have read it again, and I don't
see how that's not clear.

Again, what text, exactly, would you want changed?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Tue, 24 Jun 2014 06:59:04 -0700

On 6/24/14 5:03 AM, Kathleen Moriarty wrote:

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

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.

pr

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 24 Jun 2014 16:07:04 +0200

On Tuesday, June 24, 2014 3:59:04 PM CEST, Pete Resnick wrote:
> So, your call. Maybe worth adding something. But there needn't 
> be any grand warnings of impending horror.

+1

If you want to DoS someone into not receiving a particular message, then 
surely there are easier ways than predicting the message-id exactly. You 
could spam five hundred nearby users with a hundred messages each 
containing similar text and watch the spam filter learn.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Jun 2014 11:54:18 -0400

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

That would truly be an odd thing to say: anyone implementing Sieve has
to quite thoroughly understand the difference between tests and
actions, because both have been implemented for the base spec long
before getting to this extension.

I think the core point that you're trying to make (about which the
duplicates are) might be better done with some other re-wording.  I
think this might make the whole thing about duplicate messages
clearer:

OLD
   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.
NEW
   The "duplicate" test identifies the message by a "unique ID", and,
   using that unique ID,  keeps track of which messages were seen
   by a "duplicate" test during an earlier Sieve execution.  In its basic
   form, the test gets the unique ID from the content of the message's
   Message-ID header.  The "duplicate" test evaluates to "true" when
   the message was seen before and it evaluates to "false" when it
   was not.
END

OLD
   As a side-effect, the "duplicate" test adds the message ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  This way, the same test will evaluate to "true" during
   the next Sieve execution in which that message ID is encountered.
   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
NEW
   As a side-effect, the "duplicate" test adds the unique ID to an
   internal duplicate tracking list once the Sieve execution finishes
   successfully.  The first time a particular unique ID is seen, the
   message is not a duplicate, and the unique ID is added to the
   tracking list.  If a future Sieve execution sees a message whose
   unique ID appears in the tracking list, that test will evaluate to
   "true", and that message will be considered a duplicate.

   Note that this side-effect is performed only when the "duplicate"
   test is actually evaluated.  If the "duplicate" test is nested in a
   control structure or it is not the first item of an "allof" or
   "anyof" test list, its evaluation depends on the result of preceding
   tests, which may produce unexpected results.
END

If you really do want to say that this is only a test, and that it
takes no actions on its own, please believe me when I say that that's
entirely unnecessary, and even silly, in the context of implementing
Sieve.  The only thing about that that needs to be said is the side
effect the test has, and that's there.

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

I'm OK with that almost as it is.  If we're really addressing
Message-IDs I think the last sentence would work better like this:

"Therefore, scripts are well advised to be conservative with respect
to actions taken when duplicate messages are identified only by
Message-ID."

1. Scripts are most often created automatically, so "script writers"
would be a little odd.  Personifying "scripts" covers cases of both
human writers and automated generators.

2. It's not the duplicate messages themselves, but how the duplicates
are identified.  Scripts that nest the "duplicate" test in other
conditional constructs could be fine in this regard, as could scripts
that use the ":uniqueid" tag to build the unique ID from other things
than just the Message-ID.

Stephan, what do you think of all this?

Barry

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Jun 2014 09:27:54 -0700

> worry about when they're deploying this stuff.

Having now watched this exchange I think the above raises what appears
to be the larger issue.

Security Considerations sections need to cover the specifics of the
material covered by the document, and not include basic tutorial
material on security threats and mitigations.

Similarly, the section is not intended for the kind of highly detailed
(and therefore obscure) discussion of threats or mitigations done in a
formal threats analysis.  To impose requirements that start looking like
that kind of detail is to impose a DOS on IETF work.

We seem to have this sort of disparity of expectations on security
issues with some regularity over the years.

So here is a simple suggestion:

     When there is a Discuss on security-related issue, the AD should:

        1.  Explain how it is specific to the material in the document
-- rather than being generic threats and mitigations

        2.  How likely the scenario is

        3.  How serious the threat is to the use of what is covered in
the document.

        4.  Propose text -- or guidance in the formulation of text -- to
mitigate the threat that is presented by not covering the threat in the
document.

d/

---

From: Ned Freed <[email-masked]>
Date: Mon, 23 Jun 2014 17:03:22 -0700 (PDT)

+1

				Ned

---

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 23 Jun 2014 11:49:00 -0700

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/

COMMENT:

I support Alissa's discusses and will watch for the responses to address
privacy and to protect the identifiers used.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jun 2014 16:11:43 -0400

Hi Stephan,

Thanks for the quick response, mine is in-line.

> ":header" or ":uniqueid" are used.

Yes, I figured it would be easy to do from a point prior to the receiving
host with the sieve interpreter, hence my assumption above as the sending
server.  Use of this filter could lead to such a problem even though the
attack starts on the sending server.  Since the compete message is not
checked to ensure it is the same as the previous, there are ways to
accomplish this type of attack.  In adding this capability, which relies on
limited fields for the comparison to detect duplicates, it is subject to
the described attack.  Sure, the attack originates at the sending MTA or
some point before the receiving Sieve interpreter, but would not be
possible of a fuller comparison were performed.  Essentially, this is a
risk that should be made known in the security consideration section that
happens when you start using this feature.

Could you add a few sentences on the risk?  Since the Sieve filter can
choose how the comparison is known, include that the specific
implementation knowledge is required, making it more difficult to perform
(not impossible though, so there is still a risk).

Does the above help?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jun 2014 21:40:26 -0400

Hi,

Head out for a swim around Walden Pond and mail exploded!  Response in line and thanks for the discussion and imagination, having led incident response teams, if there is a hole, it will be found ;-)

I had to go back several messages because text was cut in subsequent ones to get to the bottom of this.

Sent from my iPhone

> On Jun 23, 2014, at 6:18 PM, Pete Resnick <[email-masked]> wrote:
> 
> Well, that's not entirely true. Most Message-IDs are generated using some algorithm that could conceivably be known and re-created: It is certainly true that most Message-IDs use the current date and time as part of the left-hand-side, along with other information, in a well-known order. So:
I agree with Pete here, if someone was determined, they would figure this out.  FYI - when you are defending against state sponsored hackers, I would assume they could figure out the message ID or do something in flight.  
>> discarded by this feature.
Two part response, this could be part of a phishing attack, replacing a real message.

Now, I just reread the draft and see where the problem is, it doesn't explicitly state that the subsequent messages are the ones deleted.  It makes sense that would be the case off the message queue, but text would be helpful, maybe in section 3.2 or sooner?  It does show up in the examples, but that's the only place I could find.

I read the draft incorrectly and somehow got the impression that the subsequent message would replace the original.  Not sure what made me think that, the noise around me and thinking of cases where people correct messages (not in the draft).

Thanks,
Kathleen 
> 
> Imagine that I want you not to get a piece of mail that is sent out at the end of the month telling you some important piece of information (like the number of failed log-in attempts to your account, or the number of traffic tickets issued for a particular truck you own). I know that the service sending this mail always sends on the first of the month at midnight exactly, and I know the algorithm that they use to generate Message-IDs, **and it doesn't include some randomly generated gobbledygook as part of it.** If I send you a message just prior to when you're supposed to get your important message with the Message-ID I was able to predict and recreate, I can get you to discard the message.
> 
> Now, the big question is: Do people algorithmically generate Message-IDs without random gobbledygook? I don't really know the answer to that. But given that 5322 doesn't require a particular algorithm that includes random data, it's certainly possible that this could be used for ill.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jun 2014 21:42:40 -0400

Hi Lyndon,

Thanks for the additional response, see in-line.

Sent from my iPhone

> On Jun 23, 2014, at 7:53 PM, Lyndon Nerenberg <[email-masked]> wrote:
> 
> 
Yes and that's fine.  My point wasn't to change this, but to state the risk of relying on it.

Thanks,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jun 2014 21:49:26 -0400

Actually, not so bizarre.  You'd be surprised the lengths folks go to as part of spear phishing attacks.  These are real attacks because they are effective.  This feature could be used as part of one.

In any case, I did read it wrong and would like some explicit text that says what is deleted.

I think there should also be a statement similar to Lyndon's response on the fields used and possible risks.  Even include it is not likely.

Thanks,
Kathleen 

Sent from my iPhone

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Jun 2014 08:03:58 -0400

Barry,

Sent from my iPhone

> imagine the scenario where it could.
For Spear phishing, yes, this is possible.  Martin explained a feasible example.  There are very real spear phishing attacks that go to great lengths to fool the recipient into thinking the message is real.  Conference mailings and airline plans have been used in these real attacks.  I think it's naive to assume something that has no protections except timing and a text ID are immune to such problems and can't be used by attackers. 

If a call helps, I'll walk you through spear phishing examples.

I'll be at the FIRST conference tomorrow and Friday (speaking), so I can probably get some new ones from attendees.

> worry about when they're deploying this stuff.
There are no considerations in this draft. A feature is being added that adds a risk, letting people know about it shouldn't be out of the question.  I don't think this is widely odd.  We can wait until it gets used and update the draft later or add a statement that says plain text values are used for this feature, which has a potential for abuse if a sender is aware that the feature is in use and how it is implemented at a destination.

Spear phishing builds on the examples Pete and Martin provided. Let's as a conference is being organized and a mass mailing is going out.  Competitors of the host typically attend.  A few are singled out and receive a message with a special link to the conference site that downloads and installs malware to spy on the user (this is very real, I've looked at systems post infection before).  Or a special word or PDF is attached to a few of the messages that does something similar because of a vulnerability in one of those products.

In spear phishing, targets are watched for a while and methods to fool them are devised over time.  This stuff is not made up.  The conference one has been used, this feature just gives an opportunity to have the message look more like the others.

Regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Jun 2014 11:27:02 -0400

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 <[email-masked]>
wrote:

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

      was not.

Proposed sentence:

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

Edit away!

Thanks!
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Jun 2014 12:55:10 -0400

Barry,

Thanks for taking the time to discuss this.  Response in-line.

>    the message was seen before and it evaluates to "false" when it

WFM and thank you.  My words were meant to help the discussion and get
edited as needed.  You are more familiar with the terminology used by the
group.

>    tests, which may produce unexpected results.

WFM, thank you!

> effect the test has, and that's there.
That's fine, it was in the discussion thread, so I used it.  Your wroding
work.  If Stephan is good with it, we should be okay?

Thanks!
Kathleen

-- 

Best regards,
Kathleen

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jun 2014 08:04:02 -0700 (PDT)

> containing similar text and watch the spam filter learn.

Exactly. And you failed to mention having to know that the recipient is using
this particular extension in a particular way. Plus this attack is going to
leave traces in the server's logs if it is successful, and if those traces are
discovered it will be a giant red flag that something naughty was done. (In
contrast, the spam training attack you describe is highly unlikely to leave
such traces.) So to do this effectively means it would be really nice to be
able to modify the server's logs after the fact.

Taken together this means the attacker has to have intimate knowledge of - and
likely access to - both the sending and receiving environment. It beggers
belief that someone who has this won't also have access to some other, far more
practial, attack.

And this brings us to the more general point: It's vital that security
considerations in this sort of document have at least some sense of proportion
and context. The IESG really needs to start taking this into account in their
comments and discusses.

It's often the case that an assortment of fanciful and/or farfetched attacks
can be constructed against systems, services, protocols, cryptographic
primitives, and so on. (Bruce Schneier calls these things "movie plot attacks",
but I don't think this is a useful characterization because it misses all sorts
of things that would never fly in a script.)

Now, elucidation and promulgation of attacks against cryptographic primitives
makes all sorts of sense even when those attacks are wildly impractical. For
one thing, these primitives are used in a wide variety of environments and
what's impractical in one place may be practical in another. And for
another, making it clear that the best attacks known are completely ineffective
tends to build, rather than reduce, confidence in this space.

But I don't think this is true when it comes to specific services and protocols
that slot into specific services in specific ways. I think a lot  more
selectivity is called for in such cases.

First and foremost, these discussions cost us all a lot of time, time which I
seriously question is not better spent elsewhere.

Second, there's a tendency for WGs to just quietly agree to add text to address
the concern that was raised in order to make it go away, which risks falling
into "Boy who cried wolf!" territory.

Third, when this leads to bulking up, qualifying, or convoluting what used to
be clear, consise prose in the service of fanciful security concerns the result
is almost always poorer than the original. (And as a person whose email address
is on a lot of RFCs, and who often gets contacted when people have questions, I
can assure everyone this is NOT an idle concern.)

My favorite example of all this - and one in the same space as the present
document - is something that happened between RFC 3028 and RFC 5228. This is a
long, sad, story, but I want to focus on the sentence in the former RFC that
says, "The language is not Turing-complete: it provides no way to write a loop
or a function and variables are not provided."

Given how often Sieve is extended, this criteria is actually pretty darned
important: We do not want someone to modify the language or define an extension
that on subsequent inspection provides a means to perform a DOS attack on an
MDA that implements it. So designers and implementors really need to think
about this issue.

Yet this very sentence came under fire during the RFC 5228 revision. Someone on
the IESG pointed out that it might be possible to use Sieve
redirect/notify/vacation/whatever to loop a message around indefinitely, at
which point you could use header tests and modification actions to implement a
Turing machine. Ergo, the language is in fact Turing complete! Gotcha! That
sentence needs to go!

Except of course this would make the email *system* Turing complete, not the
Sieve language. And if infinite loops are possible who cares if Sieve is then
used to compute a factorial or whatever on top of the looping message? It's the
loop that's the problem, not the Turing completeness you can build on top of
that. (We also go to a lot of trouble in our specifications to insure that
loops can't be created if things are implemented correctly.)

But the ensuing discussion of this and several other IMNSHO equally ridiculous
points cost us a lot of time, and if memory serves, conference calls were
actually required to resolve the matter. Which had the side effect of sapping
most of the remaining energy of the working group and driving off a couple of
active contributers.

But it sure did lead to that sentence being modified. It now says, "The base
language was not designed to be Turing-complete: it does not have a loop
control structure or functions."

Was the change worth it? I think the answer is an emphatic "no", and to be
blunt I still find the entire episode to be galling 6 years later.

Returning to the matter at hand, I remain to be convinced that this is an issue
that's worth addressing. What will convince me is suggested text that describes
the issue in accurate and practical fashion. If such text can be constructed I
have no problem seeing it added to the document.

But more generally, this seems to be yet another case where we're attempting to
address the newly perceived shortcoming of the core email service in a document
tangential to the specification of that service. (I refrained from commenting
on the privacy concern thread, but given the operational reality that all but
the most security conscious servers routinely keep detailed logs of the
metadata for every message that's sent or received for a considerable period,
and we provide exactly zero guidance as to the best practices for handling such
logs, I find the need to describe best practcies for handling a bunch of hash
values to be a bit overblown.)

And even if it were practical to craft such text - I suspect there's far less
agreement on what these newly perceived shortcomings are than you might think - 
putting such material in a place where it's unlikely in the extreme to have
mainstream impact is at best a waste of time.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Jun 2014 20:07:13 +0100

I've got to agree with this. I was going to craft a sufficiently sarcastic
further suggestion of some ridiculously contrived security flaw we had to
document to underline this point, but I couldn't actually think of anything
more contrived than the potential flaw of someone phishing by
pre-overwriting an email that ... I mean, really. Even if it occurred, the
end users writing these scripts are not the audience of this RFC, and
wouldn't notice the advice.

I'm sorry to say that the discussion smacks of security bikeshedding.

Yes, it's possible to write Sieve scripts which can expose you to security
flaws - much worse cases than this. It's also possible to publish your
password on Twitter, yet the HTTPbis RFCs do not, to the best of my
knowledge, warn about this in their Security Considerations. This isn't a
matter of whether or not that might form good advice - I happen to hold the
opinion that publishing your password on Twitter is almost certainly a bad
idea - but whether the people likely to do so read RFCs.

On 24 June 2014 16:04, Ned Freed <[email-masked]> wrote:

> agreement on what these newly perceived shortcomings are than you might
> think - putting such material in a place where it's unlikely in the extreme
> to have
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 24 Jun 2014 22:12:49 +0200

Hi Kathleen, Barry,

On 6/24/2014 6:55 PM, Kathleen Moriarty wrote:
> On Tue, Jun 24, 2014 at 11:54 AM, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     OLD
> edited as needed.  You are more familiar with the terminology used by
> the group.

WFM. Actually, this also resolves an issue I still had with this section
about mentioning the concept of a generic "unique ID" earlier. I had no
inspiration on how to do this nicely, but I think this will do the trick.

>        tests, which may produce unexpected results.

OK. This is better.

> That's fine, it was in the discussion thread, so I used it.  Your
> wroding work.  If Stephan is good with it, we should be okay?

Yes.

>     to actions taken when duplicate messages are identified only by

I can agree with this text with Barry's modification, but where do you
want to put this? At the end of Section 3 or in the Security
Considerations? If it is best put in Section 3 I should merge it somehow
with the last paragraph.

>     human writers and automated generators.

I checked for other occasions in the specification where this may have
occurred, but so far I don't seem to have referred to the script
authors.  So, doing it like this should be OK and I don't have to change
things elsewhere.

>     than just the Message-ID.

What does this remark refer to?

>     Stephan, what do you think of all this?

See above.

Regards,

Stephan.

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jun 2014 19:02:37 -0700 (PDT)

>    tests, which may produce unexpected results.

I'm ambivalent about the first change, but the second one is definitely an
improvment. The heritage of where this started as purely a message-id
thing has proven difficult to eradicate.

+1

> Stephan, what do you think of all this?

I think all this is fine, although I doubt it's going to reach an
audience for which it matters.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Jun 2014 02:29:59 -0400

> I can agree with this text with Barry's modification, but where do you want
> to put this? At the end of Section 3 or in the Security Considerations? If
> it is best put in Section 3 I should merge it somehow with the last
> paragraph.

I think it's best to stick it into the Security Considerations.

> What does this remark refer to?

That was just explaining my edits to Kathleen; no action for you there.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 25 Jun 2014 08:36:47 +0200

Hi Barry,

> I think it's best to stick it into the Security Considerations.

OK, will do.

Regards,

Stephan.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Jun 2014 06:41:51 -0400

Thank you, all!  That sounds good.

Sent from my iPhone

> On Jun 25, 2014, at 2:36 AM, Stephan Bosch <[email-masked]> wrote:
> 
> Hi Barry,
>

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:11:01 +0200

Hi Kathleen, Barry,

>        tests, which may produce unexpected results.

Applied in -08.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 26 Jun 2014 10:12:27 +0200

Hi Kathleen, Barry,

Applied in -08.

Regards,

Stephan.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 26 Jun 2014 07:08:18 -0400

Thank you, Stephan, the updated text looks good and I cleared my discuss.
 Thanks for taking time to work through the discussion and resulting text.

On Thu, Jun 26, 2014 at 4:12 AM, Stephan Bosch <[email-masked]> wrote:

> >>>>> script writers may opt to be conservative when considering actions
> taken
> >>>>> on
> >>>>> duplicate messages.
> want

-- 

Best regards,
Kathleen