some might think it odd that i, as co-chair responsible for process,
would respond to this email; however, a careful reading between the
lines will inform the thoughtful reader as to why this reply is
appropriate.
On Jun 15, 2004, at 11:26, wayne wrote:
Ok, now, I'm bothered. Why didn't Jim or Harry immediately mention
such known security with XML. Yes, they are likely not problems any
longer, but then neither are the DNS/IP-spoofing/SMTP problems that I
can name.
i wouldn't claim to be an XML expert, though i've been deploying
xml-based code for five years this month.
however, i know a few things about phrasing an argument. there are
certain things which are unprovable, such as trying to prove a
negative. i also know a few things about fear, uncertainty, and doubt,
and how to use them in trying to advance a position.
it isn't clear to me that the particular exploits you mention are
xml-specific or specific to a particular implementation.
i think that a carefully written implementation of an xml-parser is
likely to be resilient to all kinds of malicious nonsense; similarly, i
think that an implementation that isn't carefully written can have
problems.
i think i can
s/xml/current spf syntax/g
and get the same truth value for the statement above. certainly i can
s/xml/ber/g
and get the same truth value, although in that case it took about 8
years before exploits started showing up.
the underlying assumption is that things have to be provably perfect in
order to proceed. certainly spf isn't provably perfect. far, far from
it. certainly caller-id isn't provably perfect. neither is xml. though
each of the three exhibit a certain elegance in their own way.
however, the assumption is flawed because while theorists may be
interested in provably perfect systems, experienced practitioners are
not.
/mtr