[tedunangst]

I've never liked (nor understood the popularity) of signature schemes that require parsing before verification. This has also led to problems with X.509. And DKIM. And plists. And package managers. And more.

It's much simpler to sign the entire message, unparsed, and it's immune to these issues.

We went through a decade of debate before deciding that "encrypt then mac" is the only right way to do things. That knowledge hasn't trickled down to other domains.

[Everlag]

Aye, this is the 'Cryptograph Doom Principle'[0].

To very lossily summarize: always authenticate before looking at the message.

Its a handy rule of thumb when you're making choices like how to validate a message.

https://moxie.org/2011/12/13/the-cryptographic-doom-principl....

[vbezhenar]

I agree that it's a bad idea. I had an issue with two XML libraries with different languages. One did XML signing, other did verifying. They just did not work, properly signed message failed to validate. I tried to debug, but those standards were incomprehensible, there are thousands of LoC dedicated to normalization and whatnot. You need few dozens of LoC to sign or verify bytes and you need incredible complexity to implement that XML security thing.

But the issue is: those standards are out there and they're used and probably some people will use it in new projects and you have to interoperate with them.

So yeah, don't use those standards when you can, but sometimes you have to.

[marcan_42]

Yup, as I was reading this I was wondering how this could possibly lead to a critical vuln since nothing would ever depend o... and then I read about how SAML works.

Kill it with fire. This stuff's broken. We know better than to do things this way no. Just no. You sign binary blobs. Signature check fails, your binary blob is garbage and never gets parsed. End of story.

(Mental note: never deploy SAML anywhere)

Aside: I've seen a credit card processor implement nonsense like this, where I had to parse XML with regular expressions to extract the to-be-signed segment, because it was never going to round trip through a typical XML parser. But then again, this was only about the 25th batshit insane and likely insecure thing they were doing, just like every other banking related company, so shrug.

[userbinator]

This has also led to problems with X.509.

Could you explain more about this? I thought the whole point of ASN.1 DER was to have only one canonical representation for a given structured value, and that the signing was done as-is on the sequence of bytes directly. It definitely doesn't have the same problems as XML and other text-based formats.

[tedunangst]

Overshoot on my part. I was thinking of problems like those in https://arxiv.org/abs/1812.04959, but that's a different problem.

[dboreham]

I believe the problem being addressed is where the payload may be transcoded in flight or otherwise not delivered in exactly the same form. Put another way: the signature validates the payload, however it may end up being represented to the validator on delivery. It isn't simply a transport integrity measure.

[hnarn]

I might be missing the point here, but isn't the whole idea of signing a message that it should not be possible to "transcode the message in flight"? If you even allow the message to be "not delivered in exactly the same form" in the first place, you're introducing an attack vector completely without reason, because what you instead could do is let the payload be strongly signed and unchanged, and then have differing parsing rules at the end.

[koolba]

Yep and it’s even worse because the signing and encryption involves XML transforms to canonicalize the source prior to verifying them. So you force the recipient to not only validate a potentially transformed message, but they have to transform it again too!

It’s the perfect intersection of precarious and deranged.

[whatshisface]

You sign your letter and seal it in an envelope. I put your envelope into a cardboard box and give it to your friend. Your friend refuses to open your letter because you did not sign my box.

[jeltz]

No, this is more like your friend refusing to trust the contents of the letter after the mailman cut the letter into small pieces and glued them back together.

[hnick]

I think that would be more analogous to receiving a message, parsing it, then realising the payload is another signed message, and then validating that.

Depending on the situation, signing the container might not even be necessary, much like a zip file without a password that only contains encrypted contents anyway.

[syrrim]

Usually, signing the whole damn thing is too computationally expensive, so you sign a hash instead.

[hakre]

as long as binary safe transport is given, possible. unless that ... . you can't skip the memory protocol.

[GoblinSlayer]

signify works with text, you only decode the signature from base64 string and check the rest in raw.

[hakre]

yes, as long as the text is binary safe ... . XML specifies the character set for the document. IIRC also for base64.