4 ms·

I love how I work with IT for 20 years and don't understand a single acronym here other than DNSSEC

by dlopes7 5mo ago

walrus01 5mo ago
To be fair, advanced real world knowledge of public/private key PKIs (x.509 or other), things like root CAs, are a fairly esoteric and very specialized field of study. There's people whose regular day jobs are nothing but doing stuff with PKI infrastructure and their depth of knowledge on many other non-PKI subjects is probably surface level only.
- hannob 5mo ago
  I know quite a bit about PKI and X.509, and I can tell you that much: the overlap with how DNSSEC works is limited.
  - silisili 5mo ago
    As is the overlap between DNSSEC and DNS itself, to be honest. I once worked at the level of administering DNSSEC for 300+ TLDs. It's its own world. When that company was winding down, I tried to continue in the field but the most common response (outside of no response, of course), was 'we already have a DNS team/vendor/guy.' And well, then things like this happen. I won't throw stones though, it's a lot to learn and can be incredibly brittle.
- hathawsh 5mo ago
  Is that actually true, though? Even though it's not really my job, I find myself debugging certificates and keys at least once a month, and that's after automating as much as possible with certbot and cloud certificates. PKI always seems to demand attention.
  - walrus01 5mo ago
    In my initial comment, I meant more in terms of complexity and planning from the perspective of the people who are running the public/private key infrastructure on the other side/upstream of what you're doing as a letsencrypt end user. Broadly similar general concept to the team responsible for the DNSSSEC signing keys for an entire ccTLD. Yeah a x509 PKI / root CA is a very different thing than DNSSSEC but they have a number of general logical similarities in that the chain of trust ultimately comes down to a "do not fuck this up" single point of failure.
- mschuster91 5mo ago
  It's not made easier by the fact that a lot of cryptography is either very old and arcane or it's one hell of a mess of code that doesn't make sense without reading standards. I had the misfortune of having to dig deep into constructing ASN.1 payloads by hand [1] because that's the only thing Java speaks, and oh holy hell is this A MESS because OF COURSE there's two ways to encode a bunch of bytes (BIT STRING vs OCTET STRING) and encoding ed25519 keys uses BOTH [2]. And ed25519 is a mess in itself. The more-or-less standard implementation by orlp [3] is almost completely lacking any comments explaining what is going on where and reading the relevant RFCs alone doesn't help, it's probably only understandable by reading a 500 pages math paper. It's almost as if cryptographers have zero interest in interested random people to join the field. End of rant. [1] https://github.com/msmuenchen/meshcore-packets-java/blob/main/src/main/java/de/afa_amateurfunk/meshcore_packets/crypto/PublicKey.java#L57 https://github.com/msmuenchen/meshcore-packets-java/blob/mai... [2] https://datatracker.ietf.org/doc/html/rfc8410#appendix-A https://datatracker.ietf.org/doc/html/rfc8410#appendix-A [3] https://github.com/orlp/ed25519/tree/master https://github.com/orlp/ed25519/tree/master
  - cyberax 5mo ago
    X.509 is a deep legacy, but at least at this point it's well tested. > because that's the only thing Java speaks No, it most definitely is not. You can just construct a private key directly in BouncyCastle: https://downloads.bouncycastle.org/java/docs/bcprov-jdk18on-javadoc/org/bouncycastle/crypto/params/X25519PrivateKeyParameters.html https://downloads.bouncycastle.org/java/docs/bcprov-jdk18on-... I'm 100% certain that you also can do that with raw java.security. I did that about 15 years ago with raw RSA/EC keys. You can just directly specify the private exponent for RSA (as a bigint!) or the curve point for EC. Ditto for ed25519, you can just take the canonical implementation from DJB. And you really really shouldn't do that anyway, please just use OpenSSL or another similar major crypto library.
    - Muromec 5mo ago
      I wouldn't recommend touching openssl (the library, command line tools are okay-ish) with anything that breaths life.
icedchai 5mo ago
I've been in IT 30+ years, been running DNS, web servers, etc. since at least 1994. I haven't bothered with DNSSEC due to perceived operational complexity. The penalty for a screw up, a total outage, just doesn't seem worth the security it provides.
- qingcharles 5mo ago
  How simple sysadmin was in 1994 with no cryptography on any protocol. Everything could be easily MITM'd. Your credit card number would get jacked left and right in the 90s.
  - icedchai 5mo ago
    Nobody was taking credit cards online then. Your telnet sessions were easily sniffed, however.
    - qingcharles 5mo ago
      Not in '94, sure. But a couple of years later it was common and SSL was still uncommon, for a bunch of reasons, and also everyone was storing the card numbers in plaintext on their servers too. Telnet was sniffed. IRC was being sniffed and logged.
      - icedchai 5mo ago
        Yes, I worked on some early ecommerce sites. Often, we'd accept credit cards with SSL and then send them out with email (plain text SMTP) to the customer, for manual entry. Very secure.
  - gerdesj 5mo ago
    Cool. Feel free to explain how to tighten things up. I've just given them part of a recipe for using DNSSEC. I suspect you are not actually human .. qingcharles.
    - 5mo ago
bflesch 5mo ago
Don't worry, that's by design ;)

I love how I work with IT for 20 years and don't understand a single acronym here other than DNSSEC

by dlopes7 5mo ago

I love how I work with IT for 20 years and don't understand a single acronym here other than DNSSEC

To be fair, advanced real world knowledge of public/private key PKIs (x.509 or other), things like root CAs, are a fairly esoteric and very specialized field of study. There's people whose regular day jobs are nothing but doing stuff with PKI infrastructure and their depth of knowledge on many other non-PKI subjects is probably surface level only.

hannob 5mo ago
I know quite a bit about PKI and X.509, and I can tell you that much: the overlap with how DNSSEC works is limited.
- silisili 5mo ago
  As is the overlap between DNSSEC and DNS itself, to be honest. I once worked at the level of administering DNSSEC for 300+ TLDs. It's its own world. When that company was winding down, I tried to continue in the field but the most common response (outside of no response, of course), was 'we already have a DNS team/vendor/guy.' And well, then things like this happen. I won't throw stones though, it's a lot to learn and can be incredibly brittle.
hathawsh 5mo ago
Is that actually true, though? Even though it's not really my job, I find myself debugging certificates and keys at least once a month, and that's after automating as much as possible with certbot and cloud certificates. PKI always seems to demand attention.
- walrus01 5mo ago
  In my initial comment, I meant more in terms of complexity and planning from the perspective of the people who are running the public/private key infrastructure on the other side/upstream of what you're doing as a letsencrypt end user. Broadly similar general concept to the team responsible for the DNSSSEC signing keys for an entire ccTLD. Yeah a x509 PKI / root CA is a very different thing than DNSSSEC but they have a number of general logical similarities in that the chain of trust ultimately comes down to a "do not fuck this up" single point of failure.
mschuster91 5mo ago
It's not made easier by the fact that a lot of cryptography is either very old and arcane or it's one hell of a mess of code that doesn't make sense without reading standards. I had the misfortune of having to dig deep into constructing ASN.1 payloads by hand [1] because that's the only thing Java speaks, and oh holy hell is this A MESS because OF COURSE there's two ways to encode a bunch of bytes (BIT STRING vs OCTET STRING) and encoding ed25519 keys uses BOTH [2]. And ed25519 is a mess in itself. The more-or-less standard implementation by orlp [3] is almost completely lacking any comments explaining what is going on where and reading the relevant RFCs alone doesn't help, it's probably only understandable by reading a 500 pages math paper. It's almost as if cryptographers have zero interest in interested random people to join the field. End of rant. [1] https://github.com/msmuenchen/meshcore-packets-java/blob/main/src/main/java/de/afa_amateurfunk/meshcore_packets/crypto/PublicKey.java#L57 https://github.com/msmuenchen/meshcore-packets-java/blob/mai... [2] https://datatracker.ietf.org/doc/html/rfc8410#appendix-A https://datatracker.ietf.org/doc/html/rfc8410#appendix-A [3] https://github.com/orlp/ed25519/tree/master https://github.com/orlp/ed25519/tree/master
- cyberax 5mo ago
  X.509 is a deep legacy, but at least at this point it's well tested. > because that's the only thing Java speaks No, it most definitely is not. You can just construct a private key directly in BouncyCastle: https://downloads.bouncycastle.org/java/docs/bcprov-jdk18on-javadoc/org/bouncycastle/crypto/params/X25519PrivateKeyParameters.html https://downloads.bouncycastle.org/java/docs/bcprov-jdk18on-... I'm 100% certain that you also can do that with raw java.security. I did that about 15 years ago with raw RSA/EC keys. You can just directly specify the private exponent for RSA (as a bigint!) or the curve point for EC. Ditto for ed25519, you can just take the canonical implementation from DJB. And you really really shouldn't do that anyway, please just use OpenSSL or another similar major crypto library.
  - Muromec 5mo ago
    I wouldn't recommend touching openssl (the library, command line tools are okay-ish) with anything that breaths life.

icedchai 5mo ago

I've been in IT 30+ years, been running DNS, web servers, etc. since at least 1994. I haven't bothered with DNSSEC due to perceived operational complexity. The penalty for a screw up, a total outage, just doesn't seem worth the security it provides.

qingcharles 5mo ago
How simple sysadmin was in 1994 with no cryptography on any protocol. Everything could be easily MITM'd. Your credit card number would get jacked left and right in the 90s.
- icedchai 5mo ago
  Nobody was taking credit cards online then. Your telnet sessions were easily sniffed, however.
  - qingcharles 5mo ago
    Not in '94, sure. But a couple of years later it was common and SSL was still uncommon, for a bunch of reasons, and also everyone was storing the card numbers in plaintext on their servers too. Telnet was sniffed. IRC was being sniffed and logged.
    - icedchai 5mo ago
      Yes, I worked on some early ecommerce sites. Often, we'd accept credit cards with SSL and then send them out with email (plain text SMTP) to the customer, for manual entry. Very secure.
- gerdesj 5mo ago
  Cool. Feel free to explain how to tighten things up. I've just given them part of a recipe for using DNSSEC. I suspect you are not actually human .. qingcharles.
  - 5mo ago

bflesch 5mo ago

Don't worry, that's by design ;)