ietf-mxcomp
[Top] [All Lists]

Re: XML exploits

2004-06-16 05:30:36

In 
<B3D7F406-BF13-11D8-B40A-000A95CA7FAE(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> 
Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> writes:

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.

Marshall, when I first read your reply, I thought you might be
agreeing with me since I agreed with almost everything you said.
However, I think you have actually read stuff into my message that
just isn't there.



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.

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.

Correct.  And the failure of people who are not XML experts to answer
a question without research is not proof that a problem doesn't exist.



it isn't clear to me that the particular exploits you mention are
xml-specific or specific to a particular implementation.

Completely irrelevant.  What is important is whether there are enough
exploits for mail admins to object to having XML on their servers.


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

Yes, but remember that the current XML syntax requires a *complete*
SPF syntax parser in addition to an XML parser.  


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.

I never said that I wanted something that is provably perfect and I
never implied it.


We are trying to engineer a solution here.  We aren't supposed to be
some debating club where if you don't have a rebuttal card prepared
the other side scores a point.  We aren't even supposed to have sides
here. 

What I expect in order to make engineering decisions, and what Jim
Lyon didn't provide, is the provide the security background required
by RFC3552.  Since Jim is an RFC author, Jim is already supposed to
have done this research and disclosed all known security issues.  When
I answer a question raised by your co-chair that went unanswered, I
don't think the dismissive attitude toward XML security issues that
both Jim and you have displayed is appropriate.


-wayne



<Prev in Thread] Current Thread [Next in Thread>