7 ms·

because I can have my certificate authority in my DNS records and my app can verify the CA cert is from a trusted/verified source

tptacek 1y ago
This would theoretically be possible if browsers did DANE and didn't, because of middlebox fuckery, have to have a fallback path to the X.509 WebPKI because DNSSEC requests get dropped like 5% of the time. But because that is the case, no browser does DANE validation today, and when they did, many years ago, those DANE CA certs were effectively yet another CA; they actually expanded your attack surface rather than constricting it. Even if that wasn't the case --- and it emphatically is --- you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments, most of which have a demonstrated aptitude for manipulating the DNS.
- saurik 1y ago
  > ...you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments... WebPKI is already making this mistake (due to ACME). DANE at least is honest about it?
  - tptacek 1y ago
    No, because DANE lacks the transparency capabilities.
    - saurik 1y ago
      This seems like the wrong trade-off; and, if it really mattered, we--including you--should be working to push DNSSEC/DANE to improve, not for people to double down on WebPKI. Maybe we need to be advocating for DNS transparency, for example; but like, the road to there is through DANE, not through WebPKI: staunchly shilling for WebPKI isn't helping either the situation, the ecosystem, or the landscape. OK, even so, let's examine it? The premise of CT is already a bit dubious: it involves being able to figure out, after the fact, that there was a certificate issued which should not have been issued, and the attack has already been performed. The only reason this makes any sense at all is because it (supposedly) provides an incentive to people not to participate in the attack in the first place... ...but, the assumption of this is pretty much always that the party that is at fault in such a scenario is always the CA. Only, the premise of ACME undermines that: if the government decides to take over the DNS record, Let's Encrypt absolutely will issue the certificate, and it absolutely wouldn't be their fault. If we did punish them for it, then what we are really saying is that ACME is a bad idea within WebPKI. (BTW: a big part of your argument against DNSSEC always relies on "people aren't able to do it correctly", and if we apply that to CT the situation also sucks: as the expiration time for certificates goes lower and lower, the number of certificates I'm being issued goes up and up, and unless I have a durable central log of my requests--and no normal installation does--I can't verify any of the information from CT anyway.) (Yes: we could build that software, so that Apache won't re-issue my certificates without first making sure that the request has been logged durably into a database, and there is software that also goes around scavenging CT to check if my certificate is mis-issued, but I hesitate to be that charitable, given that you have spent years ignoring people who assert that clients, not resolvers, must verify DNSSEC.) (And, to take this as a moment to push back here on another of your refrains: yes, people can get DNSSEC wrong and accidentally publish their keys... but, the likelihood they will do something that dumb--despite not doing so for TLS--is way lower than the almost-certainty that they aren't going to even know what CT is, much less track it--and, critically, report after-the-fact "oops too late" attacks--for mis-issuance.)
      - tptacek 1y ago
        The problem you're up against in writing persuasively to me is that I have a bunch of reasons to dislike DNSSEC. The transparency and root-of-trust issues are the ones that, in my experience, are most legible to people who aren't deep into cryptography. But they're not my biggest issue. I think the fundamental design of DNSSEC is wrong. Its role in Internet security is mostly as a vector to keep 1990s cryptography in common use. Offline signing was wrong. Signing and not encrypting was wrong. The model we ended up with for authenticated denial is wrong. The trust model is wrong. Top-down deployment, rather than bottom-up with incremental value: wrong. It's really hard to look at DNSSEC as a design and find anything right with it. I don't blame the DNSSEC authors for this; they were working with constraints and assumptions that got rewritten in the 2000s. I do blame the DNSSEC non-authors who refuse to accept the idea that the IETF could have gotten something wrong and are still trying to push this contraption on people. Finally, as I keep saying: we're never going to get "DNS transparency". Governments run the roots of the DNS hierarchy. Governments don't run CAs, and even then, a single browser had to amass so much market power that they could dictate terms to the CAs (and, in the process, kill some of the largest CAs) in order to make CT happen. That simply cannot happen with the DNS. The dumbest thing about all of this is that the only purpose DNSSEC still serves is as an extra layer of authentication for domain-based WebPKI challenges. Nobody needs to change their zones to get better security than that! We can just run a protocol between the CAs and the registrars (it exists!).
        saurik 1y ago
        > Governments don't run CAs, and even then, a single browser had to amass so much market power that they could dictate terms to the CAs (and, in the process, kill some of the largest CAs) in order to make CT happen. If we accept this thesis, it means that the only reason we are able to have a secure internet is because we also have a monopoly on browser technology; and like, we don't want there to be a monopoly on browser technology, right? That means the current situation is unstable at best until we finally manage to regulate that monopoly out of existence... or, and maybe you feel this is the worst case scenario, attempt to turn it into a public good. > Governments run the roots of the DNS hierarchy. That this is true has some devastating consequences that I feel as if I've never seen you discuss, as TLS has not, does not, (seemingly) will not, and potentially even cannot fix the problem that a government is in a position to subvert the DNS hierarchy: it is just a fundamental property of deciding to build the web on top of a federated namespace managed by governments. We need to fix this at the web-protocol level by ditching the current TLD authority for something that isn't governmental (and is more distributed, not federated). I mean, let's look at surveillance that doesn't even require a certificate: 1) governments are in a position to redirect traffic to websites within their namespace by forging the DNS records anywhere under their TLD; 2) IP doesn't provide any protection against someone forwarding the encrypted packets; and 3) TLS only encrypts the content, but doesn't have any mechanism to encrypt the metadata of the communication channel (timing and length)... ...this is already devastating, as not only does it let you target small regions of people and determine if they are accessing a website, it also (and this is the thing that I find not enough people really internalize correctly) let's you know exactly what those users are accessing with high certainty, as you can see the approximate size of the responses to their requests. This technique has been successfully implemented in the past to figure out not merely which page of a site you are visiting, but what region of Google Maps you are looking at (based on patterns of map tile sizes), what video on YouTube you are looking at (based on patterns of video chunk sizes), and (maybe the most incredible) what your search query is (based on patterns of type-ahead suggestion lists: every keystroke causes a new request with a new JSON response of a different size; I think they did it for PornHub). > Finally, as I keep saying: we're never going to get "DNS transparency". I think you're throwing up your hands in defeat at something that we actually can fix in the browser stacks: simply add a new TLD that stores all of its second-level records on a blockchain. We already have some of these... they aren't designed well, as they don't have people who actually know much about the needs of internet protocols involved (the level of "defeat snatched from the jaws of victory" in this space is simply insane), but if people like us constantly point in the correct direction, we can pull this off. Or like, hell: maybe you find distributed blockchain tech distatesful... what if the EFF partnered with Google to manage a new TLD? Hell: Google already manages a TLD in a similar conceptual space (the one where Chrome requires HTTPS on all connections)! And then, what if they decided that DNS transparency was important enough to implement a scheme similar to the CA transparency lists for it? It would take some effort to come up with the correct design for this, but it isn't as if CA transparency was easy to pull off or is in any way perfect even today: it is a shaky system that only sometimes helps, but you care anyway! That isn't going to happen if you just write off DNS transparency as so impossible that it isn't even worth discussing. If you, instead, consistently said DNS transparency is really important, even though it is hard, maybe people at Google, EFF, Apple, Mozilla, or who all else might be relevant for this might suddenly get inspired to work on it... and, sure: to do it as a new TLD doesn't fix the problem immediately, but new websites are launched all the time, new TLDs already are successfully booted (even by Google), developers seemingly like to jump on fad TLDs, and if you start somewhere, maybe the pressure will slowly cause some of the existing TLDs to do something similar. Sure, DNSSEC might be a non-starter... but like, replacing DNSSEC is equivalent to fixing it, if you are willing to take a long-enough term approach to your advocacy efforts.

tptacek 1y ago

This would theoretically be possible if browsers did DANE and didn't, because of middlebox fuckery, have to have a fallback path to the X.509 WebPKI because DNSSEC requests get dropped like 5% of the time. But because that is the case, no browser does DANE validation today, and when they did, many years ago, those DANE CA certs were effectively yet another CA; they actually expanded your attack surface rather than constricting it. Even if that wasn't the case --- and it emphatically is --- you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments, most of which have a demonstrated aptitude for manipulating the DNS.

saurik 1y ago
> ...you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments... WebPKI is already making this mistake (due to ACME). DANE at least is honest about it?
- tptacek 1y ago
  No, because DANE lacks the transparency capabilities.
  - saurik 1y ago
    This seems like the wrong trade-off; and, if it really mattered, we--including you--should be working to push DNSSEC/DANE to improve, not for people to double down on WebPKI. Maybe we need to be advocating for DNS transparency, for example; but like, the road to there is through DANE, not through WebPKI: staunchly shilling for WebPKI isn't helping either the situation, the ecosystem, or the landscape. OK, even so, let's examine it? The premise of CT is already a bit dubious: it involves being able to figure out, after the fact, that there was a certificate issued which should not have been issued, and the attack has already been performed. The only reason this makes any sense at all is because it (supposedly) provides an incentive to people not to participate in the attack in the first place... ...but, the assumption of this is pretty much always that the party that is at fault in such a scenario is always the CA. Only, the premise of ACME undermines that: if the government decides to take over the DNS record, Let's Encrypt absolutely will issue the certificate, and it absolutely wouldn't be their fault. If we did punish them for it, then what we are really saying is that ACME is a bad idea within WebPKI. (BTW: a big part of your argument against DNSSEC always relies on "people aren't able to do it correctly", and if we apply that to CT the situation also sucks: as the expiration time for certificates goes lower and lower, the number of certificates I'm being issued goes up and up, and unless I have a durable central log of my requests--and no normal installation does--I can't verify any of the information from CT anyway.) (Yes: we could build that software, so that Apache won't re-issue my certificates without first making sure that the request has been logged durably into a database, and there is software that also goes around scavenging CT to check if my certificate is mis-issued, but I hesitate to be that charitable, given that you have spent years ignoring people who assert that clients, not resolvers, must verify DNSSEC.) (And, to take this as a moment to push back here on another of your refrains: yes, people can get DNSSEC wrong and accidentally publish their keys... but, the likelihood they will do something that dumb--despite not doing so for TLS--is way lower than the almost-certainty that they aren't going to even know what CT is, much less track it--and, critically, report after-the-fact "oops too late" attacks--for mis-issuance.)
    - tptacek 1y ago
      The problem you're up against in writing persuasively to me is that I have a bunch of reasons to dislike DNSSEC. The transparency and root-of-trust issues are the ones that, in my experience, are most legible to people who aren't deep into cryptography. But they're not my biggest issue. I think the fundamental design of DNSSEC is wrong. Its role in Internet security is mostly as a vector to keep 1990s cryptography in common use. Offline signing was wrong. Signing and not encrypting was wrong. The model we ended up with for authenticated denial is wrong. The trust model is wrong. Top-down deployment, rather than bottom-up with incremental value: wrong. It's really hard to look at DNSSEC as a design and find anything right with it. I don't blame the DNSSEC authors for this; they were working with constraints and assumptions that got rewritten in the 2000s. I do blame the DNSSEC non-authors who refuse to accept the idea that the IETF could have gotten something wrong and are still trying to push this contraption on people. Finally, as I keep saying: we're never going to get "DNS transparency". Governments run the roots of the DNS hierarchy. Governments don't run CAs, and even then, a single browser had to amass so much market power that they could dictate terms to the CAs (and, in the process, kill some of the largest CAs) in order to make CT happen. That simply cannot happen with the DNS. The dumbest thing about all of this is that the only purpose DNSSEC still serves is as an extra layer of authentication for domain-based WebPKI challenges. Nobody needs to change their zones to get better security than that! We can just run a protocol between the CAs and the registrars (it exists!).
      - saurik 1y ago
        > Governments don't run CAs, and even then, a single browser had to amass so much market power that they could dictate terms to the CAs (and, in the process, kill some of the largest CAs) in order to make CT happen. If we accept this thesis, it means that the only reason we are able to have a secure internet is because we also have a monopoly on browser technology; and like, we don't want there to be a monopoly on browser technology, right? That means the current situation is unstable at best until we finally manage to regulate that monopoly out of existence... or, and maybe you feel this is the worst case scenario, attempt to turn it into a public good. > Governments run the roots of the DNS hierarchy. That this is true has some devastating consequences that I feel as if I've never seen you discuss, as TLS has not, does not, (seemingly) will not, and potentially even cannot fix the problem that a government is in a position to subvert the DNS hierarchy: it is just a fundamental property of deciding to build the web on top of a federated namespace managed by governments. We need to fix this at the web-protocol level by ditching the current TLD authority for something that isn't governmental (and is more distributed, not federated). I mean, let's look at surveillance that doesn't even require a certificate: 1) governments are in a position to redirect traffic to websites within their namespace by forging the DNS records anywhere under their TLD; 2) IP doesn't provide any protection against someone forwarding the encrypted packets; and 3) TLS only encrypts the content, but doesn't have any mechanism to encrypt the metadata of the communication channel (timing and length)... ...this is already devastating, as not only does it let you target small regions of people and determine if they are accessing a website, it also (and this is the thing that I find not enough people really internalize correctly) let's you know exactly what those users are accessing with high certainty, as you can see the approximate size of the responses to their requests. This technique has been successfully implemented in the past to figure out not merely which page of a site you are visiting, but what region of Google Maps you are looking at (based on patterns of map tile sizes), what video on YouTube you are looking at (based on patterns of video chunk sizes), and (maybe the most incredible) what your search query is (based on patterns of type-ahead suggestion lists: every keystroke causes a new request with a new JSON response of a different size; I think they did it for PornHub). > Finally, as I keep saying: we're never going to get "DNS transparency". I think you're throwing up your hands in defeat at something that we actually can fix in the browser stacks: simply add a new TLD that stores all of its second-level records on a blockchain. We already have some of these... they aren't designed well, as they don't have people who actually know much about the needs of internet protocols involved (the level of "defeat snatched from the jaws of victory" in this space is simply insane), but if people like us constantly point in the correct direction, we can pull this off. Or like, hell: maybe you find distributed blockchain tech distatesful... what if the EFF partnered with Google to manage a new TLD? Hell: Google already manages a TLD in a similar conceptual space (the one where Chrome requires HTTPS on all connections)! And then, what if they decided that DNS transparency was important enough to implement a scheme similar to the CA transparency lists for it? It would take some effort to come up with the correct design for this, but it isn't as if CA transparency was easy to pull off or is in any way perfect even today: it is a shaky system that only sometimes helps, but you care anyway! That isn't going to happen if you just write off DNS transparency as so impossible that it isn't even worth discussing. If you, instead, consistently said DNS transparency is really important, even though it is hard, maybe people at Google, EFF, Apple, Mozilla, or who all else might be relevant for this might suddenly get inspired to work on it... and, sure: to do it as a new TLD doesn't fix the problem immediately, but new websites are launched all the time, new TLDs already are successfully booted (even by Google), developers seemingly like to jump on fad TLDs, and if you start somewhere, maybe the pressure will slowly cause some of the existing TLDs to do something similar. Sure, DNSSEC might be a non-starter... but like, replacing DNSSEC is equivalent to fixing it, if you are willing to take a long-enough term approach to your advocacy efforts.