4 ms·

There is a middle ground to he found, in upholding high standards without getting kicked off the team

1letterunixname 3y ago
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.
- tptacek 3y ago
  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.
- ggm 3y ago
  ASN.1 is tiny. It's the encoding rules which add complications.
  - pixl97 3y ago
    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.
- cryptonector 3y ago
  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 3y 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 3y 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 3y ago

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.

tptacek 3y ago
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.
ggm 3y ago
ASN.1 is tiny. It's the encoding rules which add complications.
- pixl97 3y ago
  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.
cryptonector 3y ago
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 3y 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 3y 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 3y ago