True. I think perhaps the model of IETF design-by-committee, with giant industry players who wish to sink specifications under the weight of risky and unnecessary features, is much like the "too many cooks" problem. It's better to have smaller groups of renowned experts create minimal protocols rather than force another ASN.1 or IPsec on the world.
I don't really think that stereotype holds, and, especially in the DNS case, it often seemed like random university IT administrators were the people monkeywrenching the specifications.
The IETF does not force ASN.1 on anyone. There are many Internet protocols (i.e., with RFCs published by the IETF) that use things other than ASN.1, such as, for example:
- lots of protocols like HTTP and SMTP that use ABNF and text,
- protocols like DNS, SSHv2, and TLS that use ad-hoc syntax and encoding,
- NFSv4 (which uses ONC RPC),
- protocols like XMPP that use XML
and many others.
The IETF doesn't care very much about those details because by the time a protocol has been brought to them for standardization it's already too late to insist on radical changes unless those radical changes are necessary to make the protocol secure or otherwise viable on the Internet.
In fact, a pretty significant driver of bad IETF security standardization is hatred of ASN.1. Dislike of X.509 is like 95%+ of the motivation for DNSSEC.
As an maintainer/implementor of an ASN.1 compiler and an x.509 stack, I have to say I rather like both, ASN.1 and x.509. Well, except for the x.500 naming bit of x.509, which like x.400 naming should never have happened.
Hatred of ASN.1 is misplaced and has been extremely counter-productive. Hatred of BER/DER/CER and all TLV encoding schemes ever is fair (so let's adopt OER!). Hatred of ASN.1 has led to things like Protocol Buffers, which... uses a TLV encoding because... probably the designers didn't really take the time to understand what came before.
But I suspect -and keep in mind that I wasn't there- that for DNSSEC hatred of ASN.1 was only part of it, with the other part being a desire for proper name constraints[0] and trust hierarchy[1].
It does make sense that if the names we wish to authenticate are hierarchical in nature[2] then the PKI for it should use the same hierarchy. The only reason that the WebPKI isn't structured the same as DNSSEC is that historically the support for x.509 naming constraints wasn't there, then the business model of the WebPKI made all those on the inside not want to fix that. Now that we have Let's Encrypt the latter problem is going away, but the underlying issues remain.
This is where you and I part and disagree. You greatly dislike DNSSEC, while I greatly like it. You especially dislike DANE, and I especially want DANE. But it's nice to know that we at least agree on ASN.1 and x.509.
[0] x.509 has this, but it's ill-supported in WebPKI land.
[1] x.509 also has, kind of[3] but which, again, WebPKI does not.
[2] DNS naming is strictly hierarchical, though one can be forgiven for thinking that the com. zone is just one big flat swamp as it really is, but it's not the whole of the DNS.
[3] Well, in x.509 the hierarchy of CAs is based on x.500 naming, which is just not appropriate for a web where URI authority names are DNS names (to say nothing of what a disaster x.500 naming is). There's alternative issuer names, which includes dNSName, but once more, the issue is how widespread the support for those is.
EDI, PDF, and ACPI DSDT AML are provably worse "standards" as "standards" go.
Forking implies a problem in one or more areas:
- governance
- usability (documentation and examples)
- potentially NIH-syndrome
protobufs, capnproto, flatbuffers, thrift, msgpack, erlang terms, BSON, java class files, and more exist to scratch itches that are not universally scratchable. You can't argue with the readability, portability, simplicity, or usability of JSON.. although you can argue with it's low density and parsing cost.
What's missing generally in computer science, software engineering, and systems engineering is standardization down to a minimal, feature-complete subset of interchange formats, protocols, and APIs in the spirit of professionalizing and standardizing the industry with trusted conventions. The issue has been raised many times over the past 60 years, but at some point, there needs to be more than the rare bird of "professional engineering" licensure and too common and useless A+ certifications.
I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism.
Disclaimer: I run PKI at home where every machine has 802.11x certs, every "intranet" has a cert from an intermediate cert, and every service like vSphere has its own subordinate signing cert. I keep meaning to migrate over to FreeIPA with Dogtag.
> You can't argue with the readability, portability, simplicity, or usability of JSON.
Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding Rules :)
So you can specify JSON schemas in ASN.1 syntax, which means that you could transcode from any of the other ASN.1 encoding rules, which include:
- BER/DER/CER (TLV encodings)
- OER/PER (like XDR, but with one octet alignment)
- XER (yes, the X is for XML -- XML Encoding Rules)
- GSER (a pre-JSON JSON-like encoding rules for
ASN.1 invented at IETF)
- and other ERs that are proprietary
- and any ER you care to create, which could just
be bindings of other encoding schemes like
Flat Buffers or anything else you like.
I've been wanting an XDR-based encoding rules...
Which goes to show that a lot of the encoding schemes you listed could just have been ASN.1 ERs from the get-go and:
- benefited from existing ASN.1 modules
- benefited from transcoding
- benefited from existing ASN.1 compiler codebases
But no, people had to reinvent the wheel all the way to the syntax and semantics without adding much of anything truly new.
> I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism.
I agree with this, though I'm not sure what is the antecedent of "it" in "[l]ike GPG, it has a UX problem..." -- could be DNSSEC, but it could also be PKI! :)
It effectively adds another CA to the set of CAs we already have, but this time without any of the transparency logs or browser leverage to control abuse. When operators screw up WebPKI certificates, people get certificate errors in their browser. When they screw up DNSSEC --- which everybody does --- their whole domain falls off the Internet. It doesn't solve any problems, and creates new ones. It's easy to understand the hate DNSSEC gets.
Shall we reprise our arguments about this again for GP's benefit?
Nothing about DNSSEC precludes the addition of CT, and it will eventually happen.
DNSSEC w/ query name minimization means that any zone that wishes to MITM you has to potentially make the decision without first knowing what your target domain is, or even who you are (obviously this last depends on context), and the more indiscriminate they are in their MITM activities the more likely that they'll be caught. That's a big deal, and something WebPKI can't offer -- WebPKI only has CT to offer for mitigating the MITM power of CAs, and CT depends on people auditing the logs.
Only any entity in the world that can effectively require the major TLDs to implement DNSPKI transparency. The browsers forced CT on the CAs, under threat of removing them from the root programs.
The rules for a turing machine are tiny... it's potential output is not. When you're looking for a small subset of well defined behaviors in order to maintain compatibility and application security those complications matter a lot.
