Re: [MORG] Review of draft-ietf-morg-fuzzy-search-02.txt

[Timo Sirainen <[e-mail]>]

On Fri, 2010-08-06 at 12:02 +0200, Alexey Melnikov wrote:

> 1) This might be too implementation specific, but should we point out 
> possible buffer overflows and other nastiness with fuzzy indexing 
> systems that might be used at the backend?

Mentioning buffer overflows sound like they could be a bit too
implementation specific.

> 2) It might be worth mentioning that fuzzy search might cause 
> Deny-of-Service attacks on the IMAP server. Implementations of this 
> extension are likely to consume more disk space, memory and/or CPU.

How about this, also addresses Cyrus's point of poisoning:

Implementation of this extension might enable a denial-of-service attack
if the implementation isn't careful to prevent them. Fuzzy search
engines are often complex with non-obvious disk space, memory and/or CPU
usage patterns. Implementors should test at least the behavior of large
messages that contain very long words and/or unique random strings. Also
very long search keys might cause excessive memory or CPU usage.

Invalid input may also be problematic. For example if the search engine
takes UTF-8 stream as input, it might fail more or less badly when
illegal UTF-8 sequences are fed to it from a message whose character set
was claimed to be UTF-8. This could be avoided by validating all the
input and replacing illegal UTF-8 sequences with the Unicode replacement
character (U+FFFD).

Search relevancy rankings might be susceptible to "poisoning" by smart
attackers using certain keywords or hidden markup (e.g. HTML) in their
messages to boost the rankings. This can't be fully prevented by
servers, so clients should prepare for it by at least allowing user to
see all the  search results, rather than hide results below a certain
score.