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

[Jeroen van Meeuwen (Kolab Systems)]

Florian v. Samson wrote:
> 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.
> 

Rather then making any hard limit a rule (clients *MUST*, the format *MAY 
NOT*), I would, in any scenario, make it a recommendation for clients (clients 
*SHOULD* be aware that XML allows unlimited nesting, and ...)

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

Such a guarantee -if any at all- would be an empty promise, as one can make a 
client not receive any other message objects still, through other means.

> > As such, clients would have to 1) read, 2) count
> 
> ... while reading / parsing
> 

Speaking of nitpicking on words...

> > , 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?
> 

I'm sorry, you must have confused me with Georg, who had mentioned the 640K 
earlier in this thread -as a quote, not an argument in and by itself.

> 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! ;-) )
> 

I believe you are putting words in my mouth, as I have not made any such 
argument.

The point of referring to road speed limits was to illustrate they can as 
easily be broken as a format or specification setting an arbitrary limit on 
the level of nesting of XML tags.

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

You must know more about the exact number of atoms in the solar system then 
many scientist.

Aside from that, whether or not 256 byte address spaces for IP addresses are  
or are going to be used hardly relates to the maximum level of nesting of XML 
tags.

Again, the point of referring to IPv4 -> IPv6 was to illustrate how big the 
associated cost can be, when you run out of space.

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

More to the point, is why you want to specify a hard limit (you have said 
why), and why you think it must be a hard limit stated in the format (and you 
have stated why), of all places.

I think I have illustrated why I think it should not be a hard limit, and why 
it should not be a hard limit in the format.

I fear going back and forth about it, without a single constructive argument 
is going to be fruitless.

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

You would, seriously, want to specify a hard limit on these potential attack 
vectors through the format?

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08