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

[Gunnar Wrobel]

Quoting "Florian v. Samson" <florian.samson at bsi.bund.de>:

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

It looks like we all agree that there exist dangers to the Kolab  
clients by providing them with problematic input data (primarily via  
IMAP). To me the recent discussion sounds as if this shouldn't be part  
of a "preserve all XML tags" KEP - after all Florian already splitted  
this topic off.

So if we agree that such dangers are worth discussing and putting in a  
KEP, why not develop that into its own document. Something that  
highlights some potential pitfalls for Kolab clients. But rather than  
having a paragraph saying "max nesting level 7" in the format spec I'd  
rather see something like "ensure the client handles nesting level  
1000 gracefully - it MAY abort above level 10". Or "ensure the client  
handles 10.000 groupware folders gracefully - it MAY abort when there  
are more than 5.000".

Maybe that would be a reasonable compromise.

Cheers,

Gunnar

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de