It really probably is the worst security specification ever written.

It’s also enormous, I assume from the attempt to have nominally composable parts that could be reused for other flows.

It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.

▲

cryptonector a day ago | parent [-]

It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).

▲

arethuza a day ago | parent | next [-]

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

C. A. R. Hoare

	▲	cryptonector 11 hours ago \| parent [-]
		The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones. I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex. I think that hints at the problem space being... large and complex and requiring large and complex solutions. What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.

▲

pseudohadamard 15 hours ago | parent | prev [-]

The thing is that they don't have to be that big at all, you could probably specify enough of PKI and TLS and SSH to cover most uses cases in, I dunno, 30-40 pages. However the standards bodies that produced them, termed "working groups", are more like standing committees that will (a) standardize any random idea that any member brings along and (b) are worse than the energizer bunny, they just keep going and going and going and going. Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). You can't stop these standards mills, they'll just keep grinding out more stuff that no-one ever asked for, for all of eternity.

	▲	cryptonector 11 hours ago \| parent \| next [-]
		It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today. Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or... What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.
	▲	cryptonector 11 hours ago \| parent \| prev [-]
		> Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?

▲

koolba a day ago | parent | prev | next [-]

The root problem with SAML is there’s a million and one permutations to do the same thing.

Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.

There’s too many ways to do too many things.

▲

pseudohadamard a day ago | parent [-]

That's because its built in part on XMLDSig, a genius idea to sign active content that can redefine its own semantics as it's being signed/verified. It's a triumph of ideology over common sense.

▲

arethuza 21 hours ago | parent | next [-]

I think I got to the canonicalization part of the relevant spec and decided that life was too short...

NB I can absolutely see why canonicalization is required... just that it was the bit where I lost interest

	▲	pseudohadamard 18 hours ago \| parent [-]
		The first book that came out on XMLDSig, "Secure XML: The New Syntax for Signatures and Encryption", written by the chair of the working group, spent over half of its 500 pages wrestling with canonicalization, and even then it read more as a 250-page problem statement than a solution. And that was before you got into deliberately malicious content that actively subverts the signature process.

▲

21 hours ago | parent | prev [-]

[deleted]

▲

pseudohadamard 15 hours ago | parent | prev [-]

Which, given the output of the IPsec and PKIX working groups, is saying something.

	▲	tptacek 13 hours ago \| parent [-]
		I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.