RE: Why XML2004-06-22 10:49:07Um, 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
|
|