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

[Dave Cridland <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>>
>
> 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
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>