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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Aug 2010 12:02:59 +0200

Barry Leiba wrote:
>> This is not a proper text for this section, as I don't think this is true.
>> It would be better to say that this document doesn't add additional security
>> considerations not already present in implementations of ESEARCH, SORT, etc.
>>     
> I agree.
>   
>> But maybe we should think harder about this in the case of this document.
>>     
> We did think about it, and we think it's correct that it doesn't add
> additional ones.
>
> Did you have anything specific in mind?
>   
Only some vague thoughts:

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?

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.

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 20 Aug 2010 19:29:26 +0100

> systems that might be used at the backend?

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

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Aug 2010 13:58:21 -0500

> Mentioning buffer overflows sound like they could be a bit too

I agree.  Moreover, I don't think it's the place of the IETF to tell
programmers how to program, and buffer overflow bugs are well enough
known that programmers should already know that they need to watch for
them.  I really don't think this opens things up for any more or
different buffer overflow bugs than any other spec does.

> see all the  search results, rather than hide results below a certain

I'm happy with that text.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Aug 2010 10:51:05 +0100

Barry Leiba wrote:

>them.
One would think so. I actually think that educating people is a good 
thing. However I am not going to insist on discussing this.

>I really don't think this opens things up for any more or
That part I agree with.

>I'm happy with that text.
I am too. I am not convinced that mentioning Unicode replacement 
character (U+FFFD) is necessary, but I suppose it is Ok.

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 25 Aug 2010 18:51:34 +0100

> character (U+FFFD) is necessary, but I suppose it is Ok.

So just "This could be avoided by validating all the input." would be
better? Or just remove the whole sentence.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Aug 2010 10:55:05 +0100

Timo Sirainen wrote:

>So just "This could be avoided by validating all the input."
>
Yes. Or alternatively something like:

This could be avoided by validating all the
input and, for example, replacing illegal UTF-8 sequences with the Unicode replacement
character (U+FFFD).

I.e. I want to be clear thar replacing with U+FFFD is not the only 
solution.

>would be better? Or just remove the whole sentence.
>  
>