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

[Jeroen van Meeuwen (Kolab Systems)]

Florian v. Samson wrote:
> Am Freitag, 15. Juli 2011 um 15:11:55 schrieb Jeroen van Meeuwen (Kolab
> Systems):
> > Florian v. Samson wrote:
> > > Am Freitag, 15. Juli 2011 um 11:42:10 schrieb Jeroen van Meeuwen (Kolab
> > > Systems):
> > > > 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?
> 
> Yes, we already did so in KEP2, when we detected a potentially unlimited
> length string, the sec-frac ("frac-sec"?; never mind) in the datetime, to
> be specific.
> 

Euh, that's not actually what you did in KEP #2, it specifies that IF a field 
to be defined in the future were to allow or require time-secfrag, it MUST 
then also set its maximum number of digits.

A hard limit has yet to be set, which is not the same as "we already did 
specify a hard limit on these potential attack vectors".

> Any potentially *unlimited* <something> ought to be limited, IMO.
> There really are not that many cases.
> What is wrong with that approach, in your opinion?
> 

I think that approach is wrong because it's pursued for the wrong reasons, in 
the wrong direction and frankly, by the wrong people at the wrong level.

If there's any type of serious threat in the level of nesting that XML allows, 
and there isn't, please amend the specification for XML.

If such limitation is not accepted, and it won't be, look at "protecting" all 
implementations of XML parsing libraries to provide its respective go_parse() 
API call with a go_parse($but_please_initially_use_this_max_level_of_nesting).

If such implementation takes too long, and it will take quite some time, 
perhaps a notice to Kolab client implementors is in order, so that they can 
take measures to protect themselves against this misperceived security issue.

If there's a danger in the amount of digits in the time-secfrag, please take 
that upstream and amend ISO8601 / RFC3999 or whatever it is perceived the 
Kolab proprietary datetime format described in KEP #2 is compatible with.

To account for a potential DoS through one attack vector by specifying a hard 
limit in something like the Kolab format -still not enabling prevention- has 
the same effect as me not lighting a cigarette to counter global warming.

That said, to nest XML beyond the level of depth a client may or may not be 
capable of parsing is to ignore a variety of more attractive attack vectors.

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