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

[Ned Freed <[e-mail]>]

> 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