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

[Florian v. Samson]

Hi Jeroen,

Am Freitag, 15. Juli 2011 um 11:42:10 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> Florian v. Samson wrote:
> > 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 disagree.
>
> Prevention of the parsing of nested XML potentially resulting in denial
> of service is hardly Kolab Format's purvue, but could instead be
> implemented, for example, in a parsing library -by means of limited
> read-ahead- and/or in or through the client.

Sorry, I am unable to follow that logic: "Prevention of <whatever> is hardly 
Kolab Format's purview, but could instead be implemented ... in a parsing 
library ...".

A specifications (as the Kolab-format spec) primary purpose is always to 
provide rules for implementers.  Hence, IMO this would be fully in the 
purview of the Kolab-format spec.

The question rather was, if this makes sense, both logically and 
technically.

> Also, *specifying* the maximum level of nesting does not *prevent* the
> maximum level of nesting from being exceeded. 

Well this is nitpicking on words, IMO!
Yes, specifying that such Kolab-objects MUST be neither generated nor parsed 
(beyond a certain nesting level) does not prevent a malicious user to 
hand-craft such an Kolab-object and upload it.
But it would be guaranteed to have no ill effect on on any conformant 
client.

> As such, clients would have to 1) read, 2) count

... while reading / parsing

> , 3) hit the limit, 4) ignore further nesting levels, 

Yup, that is it.

> but this is an absolutely flawed implementation of trying to implement
> DoS prevention, and very costly to change once the limit has to be
> raised. Insert here a remark on road speed limits, and IPv4 -> IPv6.

I already pointed out that this not alike the "640K" barrier. 
And even if you still believe it does: that "barrier" was overcome soon, so 
where/what is the proof in that story?

But your examples do actually fit well:

1. Do you seriously believe that establishing a world wide rule that all 
road speed limits MUST be set to less than 500 mph would ever do any harm?
(BTW, lake Bonneville is not an official road! ;-) )

2. Would you also support saying it is too strict to limit IP-addresses to 
max. 256 Bytes forever, even though one can easily calculate that with this 
limit imposed one could assign vast numbers of IP-addresses to every atom 
in the solar system?

If we ever reach those limits (and this is very unlikely due to logical or 
physical barriers) I suppose Kolab will be log outdated or vastly 
overhauled, as it happened with the PC ("640K" barrier) as well.

> Furthermore, if the limit in nesting levels is to be implemented to
> prevent a potential client denial of service, I would argue you also
> require a limit for string lengths, number of sequential tags, content
> characters and maximum number of folders for a Kolab account.

Oh yes, I fully agree, and suppose Bernhard will do so as well.


Cheers
	Florian