6 ms·

djb is a great lesson in how "being an asshole" can be counterproductive.

akira2501 4y ago
> counterproductive If the goal of a committee member is merely to be included in the committee. Otherwise, if the committee is merely operating as a rubber stamp for every one of it's members proposals, then there may not be much productive value in remaining there. Apparently that feeling was mutual.
- imwillofficial 4y ago
  There is a middle ground to he found, in upholding high standards without getting kicked off the team
  - 1letterunixname 4y 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 4y 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 4y ago
      ASN.1 is tiny. It's the encoding rules which add complications.
      - pixl97 4y 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 4y 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 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.
0xdeadbeefbabe 4y ago
Seems most counterproductive if you lose.
cvalka 4y ago
DJB is a gift to humanity.
riceart 4y ago
As if djb not being an asshole would have saved the IETF from their incompetent buffoonery. Yeah let’s just blame it all on one guy for not being a sycophant rather than lay the responsibility on the actual buffoons.
1letterunixname 4y ago
Other than source-less reputation bashing / gossip, are instances of poor behavior? Also consider TdR of OpenBSD and OpenSSH has been polarizing but impactful.
- tptacek 4y ago
  I think the track records are tellingly comparable.
dehrmann 4y ago
Sounds like Theo de Raadt.
Intermernet 4y ago
Except that a huge amount of the world runs on cryptography designed by him, because all the standards committees and government orgs are somehow less trustworthy than this "asshole".
- 1vuio0pswjnm7 4y ago
  djb is like a litmus test. How someone reacts to him can reveal whether that person is someone who thinks they are smarter than they really are, a personality type that is common amongst software developers. These are the type of people who cannot admit when they are wrong, and will never admit that they are incompetent. Arguably, it is because of such people that we are drowning in crappy software, and even worse, that crappy software is popular. IMHO, djb is on the side of the user, whether intentionally or not. djbdns allowed me, a user, to take control of DNS on the networks and computers I own. The philosophy of BIND at the time felt like "DNS is for DNS experts. We're experts. Do as we tell you."^1 I also learned nsd so I do use BIND zone file format. But I never became a BIND user. 1. I see a parallel in the context of "certificate authorities". Nothing wrong with "CAs" in theory but in practice, i.e., commercialisation of certificates and browser-centricity, the system reeks. Pay to play, or at least mandatory third party intermediaries, and generally user hostile.
  - akerl_ 4y ago
    I think it might be dangerous to elevate people in this way. Probably djb is a human, who doesn’t represent a dowsing rod for your evaluation of the world.

> counterproductive If the goal of a committee member is merely to be included in the committee. Otherwise, if the committee is merely operating as a rubber stamp for every one of it's members proposals, then there may not be much productive value in remaining there. Apparently that feeling was mutual.

imwillofficial 4y ago
There is a middle ground to he found, in upholding high standards without getting kicked off the team
- 1letterunixname 4y 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 4y 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 4y ago
    ASN.1 is tiny. It's the encoding rules which add complications.
    - pixl97 4y 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 4y 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 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.

0xdeadbeefbabe 4y ago

Seems most counterproductive if you lose.

cvalka 4y ago

DJB is a gift to humanity.

riceart 4y ago

As if djb not being an asshole would have saved the IETF from their incompetent buffoonery. Yeah let’s just blame it all on one guy for not being a sycophant rather than lay the responsibility on the actual buffoons.

1letterunixname 4y ago

Other than source-less reputation bashing / gossip, are instances of poor behavior? Also consider TdR of OpenBSD and OpenSSH has been polarizing but impactful.

tptacek 4y ago
I think the track records are tellingly comparable.

dehrmann 4y ago

Sounds like Theo de Raadt.

Intermernet 4y ago

Except that a huge amount of the world runs on cryptography designed by him, because all the standards committees and government orgs are somehow less trustworthy than this "asshole".

1vuio0pswjnm7 4y ago
djb is like a litmus test. How someone reacts to him can reveal whether that person is someone who thinks they are smarter than they really are, a personality type that is common amongst software developers. These are the type of people who cannot admit when they are wrong, and will never admit that they are incompetent. Arguably, it is because of such people that we are drowning in crappy software, and even worse, that crappy software is popular. IMHO, djb is on the side of the user, whether intentionally or not. djbdns allowed me, a user, to take control of DNS on the networks and computers I own. The philosophy of BIND at the time felt like "DNS is for DNS experts. We're experts. Do as we tell you."^1 I also learned nsd so I do use BIND zone file format. But I never became a BIND user. 1. I see a parallel in the context of "certificate authorities". Nothing wrong with "CAs" in theory but in practice, i.e., commercialisation of certificates and browser-centricity, the system reeks. Pay to play, or at least mandatory third party intermediaries, and generally user hostile.
- akerl_ 4y ago
  I think it might be dangerous to elevate people in this way. Probably djb is a human, who doesn’t represent a dowsing rod for your evaluation of the world.