5 ms·

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, f

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.

tptacek 4y ago
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.
- cryptonector 4y ago
  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.
  - 1letterunixname 4y ago
    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.
    - tptacek 4y ago
      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.
      - cryptonector 4y ago
        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.

tptacek 4y ago

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.

cryptonector 4y ago
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.
- 1letterunixname 4y ago
  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.
  - tptacek 4y ago
    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.
    - cryptonector 4y ago
      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.