On "max. tag nesting depth" in the Kolab-Format spec

[Florian v. Samson]

Hi Georg,

Am Freitag, 15. Juli 2011 um 10:37:33 schrieb Georg C. F. Greve:
>
> Just very briefly, I will come back to kolab-format@ with a bit more time
> in the next weeks, but I think some more work needs to be done on showing
> the rationale for a hard-coded nesting depth limit:
>
> On Friday 15 July 2011 10.12:49 Florian v. Samson wrote:
> > In short: Why not?
>
> 	"640K ought to be enough for anybody."
>
> There is an inherent problem with foreseeing absolute numbers and limits
> in computing, and changing this later if/when we hit that barrier will be
> very expensive for all clients.

While I do understand this aspect and have no issue with raising the limit 
to e.g. 127, I do agree with Bernhard that there ought to be one.

I do believe that this specific case has its logical limits in nesting 
depth: a XML-construct which may nest indefinitely would be very bad 
design, IMO.  So this case is much more specific and does have its logical 
boundaries which *are* roughly assessable, in contrast to, e.g., the 
resource consumption of software in 15 years in terms of "Main memory 
space", "Mass storage space", "Computing power", "I/O load" etc. 

> > You have not argued against any of the dangers I pointed out:
>
> The threat scenario so far seems based on a malicious user that
> deliberately tries to destroy data. 

... or just let the clients of many other Kolab-users go awry (DOS).
And those which stumble would do so until the forged Kolab-object is deleted 
on the server.

> This is a scenario that is almost 
> impossible to protect against in the end, and nesting bombs are a lot
> more complex as an attack than currently existing attack vectors which we
> realistically cannot prevent.

Really, I cannot think of anything much simpler than to forge and upload a 
Kolab-object to a shared IMAP-folder on a Kolab-server.
Can you please provide two or three examples of the "a lot simpler currently 
existing attack vectors which we realistically cannot prevent."?

Cheers
	Florian