[langsec-discuss] XML DIGSIG langsec problems
Nils Dagsson Moskopp
nils at dieweltistgarnichtso.net
Sat Aug 29 02:51:23 UTC 2015
Surely you must be joking, I thought. And then I skimmed this … :
Is there a LANGSEC shorthand for the phenomenon that programmers who
find it difficult to solve a (solvable) problem in a limited language
turn the chomsky hierarchy control up to eleven instead of thinking?
I am asking because I have seen it many times … all the developers who
could not write proper CSS if their life depended on it, who are using
Dan Kaminsky <dan at doxpara.com> writes:
> 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.
> On Tuesday, August 25, 2015, <travis+ml-langsec at subspacefield.org> wrote:
>> 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:
>> 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
>> http://www.subspacefield.org/~travis/ | if spammer then
>> "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 at mail.langsec.org
Nils Dagsson Moskopp // erlehmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 212 bytes
Desc: not available
More information about the langsec-discuss