I’m happy that JSON doesn’t suffer from the complexity that XML does, but I find it bizarre that the answer to a “markup language” is a formalized subset of Javascript.
-----Original Message----- From: Dan Kaminsky <d...@doxpara.com> Reply: Dan Kaminsky <d...@doxpara.com>> Date: August 25, 2015 at 10:01:27 AM To: langsec-discuss@mail.langsec.org <langsec-discuss@mail.langsec.org>> Subject: Re: [langsec-discuss] XML DIGSIG langsec problems > Once upon a time you could provide XSL style sheets for canonicalization. > And then they added JS to XSL. > > To validate my signature, run my code. > > Yup > > On Tuesday, August 25, 2015, wrote: > > > > > http://www.contextis.com/documents/33/Exploiting_XML_Digital_Signature_Implementations-HITBKL20131.pdf > > > > > > By signing XML content, rather than the raw bytes of an XML > > document, the W3C were faced with a problem, specifically the > > possibility that intermediate XML processors might modify the > > document's physical structure without changing the meaning. > > > > At this point you are permitted to start chuckling, privately. > > > > An obvious example is text encodings. As long as the content > > is the same there is no reason why an XML file stored as UTF-8 > > should not have the same signature value as one stored as > > UTF-16. There are other changes which could occur which don't > > affect the meaning of the XML but would affect its physical > > representation, such as the order of attributes, as the XML > > specification does not mandate how a processor should > > serialize content. > > > > Eyebrows raised. > > > > With this problem in mind the W3C devised the canonical XML > > specification which defines a series of processing rules which > > can be applied to parsed XML content to create a known > > canonical binary representation. For example, it specifies the > > ordering of attributes, and mandates the use of UTF-8 as the > > only text encoding scheme. > > > > Summary: We won't specify how you serialize it, only how you serialize > > it to validate the signature. As a result, you have to parse the > > untrusted message and expose parsing and canonicalization to the > > anonymous attack surface before determining the signature is invalid, > > assuming you even managed to check that properly: > > > > > > https://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/att-0019/Camera-Ready.pdf > > > > http://www.slideshare.net/44Con/the-forgers-artjamesforshaw44con2k13 > > > > https://www.owasp.org/images/5/5a/07A_Breaking_XML_Signature_and_Encryption_-_Juraj_Somorovsky.pdf > > > > > > https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf > > > > > > Countermeasures: > > > > http://arxiv.org/pdf/1401.7483.pdf > > > > Proposed that the anonymous attack surface be required to do minimum > > processing on untrusted input before authentication/authorization. > > That means no parsing, nothing more complicated than slicing off a > > signature and validating it. Proposed that this not just encourages > > security in the non-authenticated case, it also minimizes the work to > > validate the security of the anonymous attack surface. > > > > Open question: how much flexibility in cipher negotiation or choices > > and serialization can be done safely during this stage. Compare > > OpenSSL. Considered that flexibilty (which requires more complex > > pre-auth logic) comes with risk, but if chosen carefully can be > > minimized. > > -- > > http://www.subspacefield.org/~travis/ | if spammer then > > j...@subspacefield.org > > "Computer crime, the glamor crime of the 1970s, will become in the > > 1980s one of the greatest sources of preventable business loss." > > John M. Carroll, "Computer Security", first edition cover flap, 1977 > > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss