spf-discuss
[Top] [All Lists]

RE: Why XML

2004-06-22 10:49:35
Um, how does the complexity of XML improve security.  I can think of examples 
where XML enhancements
CAUSED exploits, and there are implementations where the XML implementation 
poses denial of service
exploit by sheer processing power needed for a full XML parser.

How is this a "single shot" at upgrading email?  The SMTP protocol has been 
evolving for a VERY long
time.

Interesting arguments on extensibility.  All valid.  Also all valid for SPFv1 
due to the fact that
SPFv1 is extensible.


Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085


-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Hadmut 
Danisch
Sent: Tuesday, June 22, 2004 1:19 PM
To: IETF MARID WG
Subject: Re: Why XML



Hallam-Baker, Phillip wrote:
 [ statement voting for XML ]


Folks,

I fully agree with Phil. There are pretty good reasons to choose
XML or ASN.1/DER. If you have a parser for XML or ASN.1, it will
be able to parse *any* version of records, even future ones.

Keep in mind that you are not designing some application
for LAN usage or for those who might want to give it a try.

This is about upgrading the world wide e-mail system. This
is a single-shot adventure. You won't get a second chance.

With ASN.1 or XML you can rely on the fact, that the
implementations can at least talk to each other even if
written for different versions of the data structures (after
all, that's what ASN.1 and XML have been designed for,
and there are good reasons why other protocols make
use of it). Application writers have learned that using
such a structured data language makes programs
better, more reliable, more secure, easier to extend,
and improves the compatibility between different versions.

Why ignore this?

I am working on network security and sender authentication
since around 1992 and was discussing about e-mail sender authorization
in context of RMX for about two years now. Believe me, you will never
be able to foresee everything what will come.
None of you should believe that he/she is able to design the
final protocol solving everything. Be
prepared to fail. What would you do if, maybe a year after the world
wide rollout, you suddenly realize that there is something you didn't
take into consideration? Maybe a new kind of attack? New spamming
technologies? New laws? New technology? Maybe a sender identified
by the mobile phone number instead of IP address? Any weird method
of time slots? Maybe topological authentication? Or maybe a completely
new directory service? Who knows? What makes you know that we
won't want to have a jpeg portrait image as a method of
authentication/authorization in three years?  Or any magic device
allowing us to send e-mail from every internet cafe authenticated?

What will you do then? Tell the world "Sorry, we made a mistake.
We have to reinstall the world wide mail system.  Please upgrade all
world's MTAs to the new version synchronously next
wednesday at exactly 11:30 am"?


The RMX syntax was a first approach, and SPF is not
significantly more modern. These syntax definitions are state of the
art - the art of about 10-20 years ago. We shouldn't ignore the
progress of computer science and programming technology.

How many changes and extensions will SPF syntax take?
Isn't every change and extension an odd hack? What makes
you rely on the fact that any new extension can be read by
any older version? With such a proprietary syntax as SPF,
every implementor will write his own parser/interpreter. I guess
that a new syntax version will break 5-30% of implementations.
In contrast, XML and ASN.1 parsers exist and are proven
and tested. You can automatically generate the parsers from
the grammar, thus eliminating lots of bugs and security flaws.


And as I stated earlier, don't be limited to today's point of
view and
today's
technology. Tomorrow there will be another killer application again
requiring protection against fraud and forgery. Maybe voice-over-ip.
Maybe instant messaging. What would you do? Start a new discussion
for two years and design a new proprietary syntax?

Keep in mind that this is a one-shot operation for upgrading
a world wide communication network which will only succeed if
the world wide communication remains working and compatible
without major problems. This requires an extensible, orthogonal
and precise definition and a robust and proven method to
describe data structures, where parsers can be generated automatically
and libraries are ready for use instead of reinventing another wheel.
XML parsers exist for most modern programming languages and make
it easy to write e.g. a graphical frontend. The art of programming
is abstraction between contents and representation. XML and ASN.1
do this all. SPF doesn't. Don't make the mistake to take your own
hacking (in)capabilties as a design criterion for a world wide
communication
protocol. Parsing SPF is a hack. This makes it look easy and
comfortable
in some people's eyes. But that's wrong. We are not here to design
a protocol easy to parse with perl regular expressions.

And, by the way, sorry, but can't resist, asking for "who can give
an example SPF isn't able to cope with, otherwise it must be good" is
not exactly the art of designing good protocols.


Or in other words: I vote for ASN.1 or XML (or zipped XML).


regards
Hadmut






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