5 ms·

My Logs, for the last 30 days, domains validated with DNSSEC was 5.34%. In general, it feels that ISPs like to be slow adopting standards, e.g. IPv6 it is still

My Logs, for the last 30 days, domains validated with DNSSEC was 5.34%. In general, it feels that ISPs like to be slow adopting standards, e.g. IPv6 it is still rolling.

tptacek 7y ago
Just look it up on dnssec-tools. As of March of this year, there were ~1.7MM signed domains in .COM. As of Q3 of last year, there were 144MM domains in .COM. Wherever you got that "30%" stat from, it was wildly off. Even I was overcounting. And (I'm ninja-editing this in, so sorry if I caught you while replying), as you noted, much of the growth in .COM signings is attributable to Cloudflare auto-signing --- which is the same thing that is happening in places like .NL. But registrars auto-signing domains is security theater. Ironically: attacks against registrars are far more common than attacks on the DNS protocol itself; the recent spate of "DNS attacks" from the end of last year turned out to have been phishing attacks.
- mlyle 7y ago
  Yes, I slipped a zero. Still, your argument is: It's not adopted much, so we shouldn't adopt it--- plus it doesn't matter if naming isn't trustworthy? :P I don't find that a very good argument. Your same argument seems to imply that since we have good TLS on many protocols, we shouldn't be too heartbroken about people stealing traffic with BGP, either.
  - tptacek 7y ago
    So, that's actually not my argument. But, though you're trying to dunk on it, it is a solid argument. Here's why: the cryptography in DNSSEC is obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit, with an outlandish hack that combines spoofing and a KDF to prevent zone enumeration). The protocol "supports" P-curve ECDSA signatures, and, of course, both the P-curves and the NIST DSA signing algorithm are themselves outmoded --- and that's the frontier of crypto in DNSSEC; Geoff Huston did studies of this and found a substantial fraction of deployed DNSSEC verifiers can't even handle that. The point being: it will take decades, literal decades, to get the baseline level of cryptographic competence we expect from secure messengers (to say nothing of modern signing crypto) into DNSSEC. And every new deployment of 1990s-grade DNSSEC makes that problem harder. If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. The entire protocol would be drastically cleaner, easier to deploy, and, of course, much more secure. This is not the core argument I have against DNSSEC (for that, just Google [against DNSSEC]). But it's a good one. What they say about PHP holds true for DNSSEC: it's a fractal of bad design. I don't know what BGP has to do with any of this except to say that DNSSEC obviously doesn't do anything to prevent BGP hijacking attacks; attackers who control BGP control IP addresses, the things DNS maps in the first place. I'm doing my best to keep these responses varied and interesting, because an HN search will show this is an argument I've made here a lot. Hopefully I'm doing an OK job of that.
    - mlyle 7y ago
      > So, that's actually not my argument. But, though you're trying to dunk on it, it is a solid argument. Here's why: the cryptography in DNSSEC is obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit, Root zone has been signed with 2048 bit keys since 2016. Large numbers of domains are signed with 2048 bit keys, too. > If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. Online signing still looks really expensive. Asking an authoritative server to do a 2048 bit signature per answer is costly, given the other conversation you've followed me into and argued basically the other side of. Especially since work you do to make DNS authoritative servers verify things is easily used for DOS, unlike work done for prefix verification in BGP). > don't know what BGP has to do with any of this Because we're in a thread talking about preventing BGP hijacking of prefixes with crypto, and the tangential discussion of preventing DNS hijacking of names with crypto (DNSSEC) came up. Some arguments you presented against caring about DNS security work equally well wrt: caring about BGP security--- who cares if someone intercepts our traffic, we're probably using TLS!
      - tptacek 7y ago
        No. All modern DNSSEC implementations are online signers anyways, because the BCP mitigation for zone enumeration, "whitelies", depends on that. So what we in fact have is the worst of both worlds: a protocol that makes painful compromises to work in an offline-signer model, and all the operational concerns of online signers. A DNSSEC that was designed for online signers from the jump would be cleaner and more secure. That the root zone was signed with 1024-bit RSA in 2016 is its own dunk, and I think you for making it for me, but of course the root zone isn't the only zone; the 1024-bit root just meant every TLD was capped at that level of security. Now they're not, but the rest of the DNS is still littered with them. See: every DNSSEC survey. And, of course, you've addressed only a small part of that previous argument --- just the key sizes. I don't know what point you're trying to make about BGP. I think you think I'm opposed to RPKI. I'm not.
        mlyle 7y ago

My Logs, for the last 30 days, domains validated with DNSSEC was 5.34%. In general, it feels that ISPs like to be slow adopting standards, e.g. IPv6 it is still rolling.

tptacek 7y ago

Just look it up on dnssec-tools. As of March of this year, there were ~1.7MM signed domains in .COM. As of Q3 of last year, there were 144MM domains in .COM. Wherever you got that "30%" stat from, it was wildly off. Even I was overcounting. And (I'm ninja-editing this in, so sorry if I caught you while replying), as you noted, much of the growth in .COM signings is attributable to Cloudflare auto-signing --- which is the same thing that is happening in places like .NL. But registrars auto-signing domains is security theater. Ironically: attacks against registrars are far more common than attacks on the DNS protocol itself; the recent spate of "DNS attacks" from the end of last year turned out to have been phishing attacks.

mlyle 7y ago
Yes, I slipped a zero. Still, your argument is: It's not adopted much, so we shouldn't adopt it--- plus it doesn't matter if naming isn't trustworthy? :P I don't find that a very good argument. Your same argument seems to imply that since we have good TLS on many protocols, we shouldn't be too heartbroken about people stealing traffic with BGP, either.
- tptacek 7y ago
  So, that's actually not my argument. But, though you're trying to dunk on it, it is a solid argument. Here's why: the cryptography in DNSSEC is obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit, with an outlandish hack that combines spoofing and a KDF to prevent zone enumeration). The protocol "supports" P-curve ECDSA signatures, and, of course, both the P-curves and the NIST DSA signing algorithm are themselves outmoded --- and that's the frontier of crypto in DNSSEC; Geoff Huston did studies of this and found a substantial fraction of deployed DNSSEC verifiers can't even handle that. The point being: it will take decades, literal decades, to get the baseline level of cryptographic competence we expect from secure messengers (to say nothing of modern signing crypto) into DNSSEC. And every new deployment of 1990s-grade DNSSEC makes that problem harder. If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. The entire protocol would be drastically cleaner, easier to deploy, and, of course, much more secure. This is not the core argument I have against DNSSEC (for that, just Google [against DNSSEC]). But it's a good one. What they say about PHP holds true for DNSSEC: it's a fractal of bad design. I don't know what BGP has to do with any of this except to say that DNSSEC obviously doesn't do anything to prevent BGP hijacking attacks; attackers who control BGP control IP addresses, the things DNS maps in the first place. I'm doing my best to keep these responses varied and interesting, because an HN search will show this is an argument I've made here a lot. Hopefully I'm doing an OK job of that.
  - mlyle 7y ago
    > So, that's actually not my argument. But, though you're trying to dunk on it, it is a solid argument. Here's why: the cryptography in DNSSEC is obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit, Root zone has been signed with 2048 bit keys since 2016. Large numbers of domains are signed with 2048 bit keys, too. > If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. Online signing still looks really expensive. Asking an authoritative server to do a 2048 bit signature per answer is costly, given the other conversation you've followed me into and argued basically the other side of. Especially since work you do to make DNS authoritative servers verify things is easily used for DOS, unlike work done for prefix verification in BGP). > don't know what BGP has to do with any of this Because we're in a thread talking about preventing BGP hijacking of prefixes with crypto, and the tangential discussion of preventing DNS hijacking of names with crypto (DNSSEC) came up. Some arguments you presented against caring about DNS security work equally well wrt: caring about BGP security--- who cares if someone intercepts our traffic, we're probably using TLS!
    - tptacek 7y ago
      No. All modern DNSSEC implementations are online signers anyways, because the BCP mitigation for zone enumeration, "whitelies", depends on that. So what we in fact have is the worst of both worlds: a protocol that makes painful compromises to work in an offline-signer model, and all the operational concerns of online signers. A DNSSEC that was designed for online signers from the jump would be cleaner and more secure. That the root zone was signed with 1024-bit RSA in 2016 is its own dunk, and I think you for making it for me, but of course the root zone isn't the only zone; the 1024-bit root just meant every TLD was capped at that level of security. Now they're not, but the rest of the DNS is still littered with them. See: every DNSSEC survey. And, of course, you've addressed only a small part of that previous argument --- just the key sizes. I don't know what point you're trying to make about BGP. I think you think I'm opposed to RPKI. I'm not.
      - mlyle 7y ago