On "max. tag nesting depth" in the Kolab-Format spec
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Jul 15 16:44:38 CEST 2011
Florian v. Samson wrote:
> Am Freitag, 15. Juli 2011 um 15:11:55 schrieb Jeroen van Meeuwen (Kolab
> > 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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the format