5 ms·

I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You start with a BGP hijack, which lets you impersonate anybody

I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. You then use that specific control to get a CA to forge a certificate for you (and if the CA is capable of using any information to detect that this might be a forgery, the attack breaks). And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking--impersonating somebody to the nameserver and getting the account switched over to them.

iscoelho 1y ago
> I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You claim it is fine-tuned, but it has happened in the real world. It is actually even better for attackers that it is "obscure", because that means it is harder to detect. > but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. Yes, all layers of the stack need to be secure. I am not making assumptions about the other layers - this thread is about DNS. > if the CA is capable of using any information to detect that this might be a forgery They are not. The only mitigation is "multi-perspective validation", which only addresses a subset of this attack. > And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking Yes, because other kinds of DNS hijacking are solved by HTTPS TLS. If TLS and CAs are broken, nothing is secure.
- dwattttt 1y ago
  > You claim it is fine-tuned, but it has happened in the real world. Sure, but it seems like his comment is still responsive; if DNSSEC is deployed, they perform a BGP hijack & can impersonate everyone, and they just impersonate the server after the DNS step? If that's the threat model you want to mitigate, it seems like DNSSEC won't address it.
  - iscoelho 1y ago
    > and they just impersonate the server after the DNS step? Yes, there are different mitigations to prevent BGP hijacking the webserver itself. Preventing a rogue TLS certificate from being issued is the most important factor. CAA DNS records can help a bit with this. DNS itself however is easiest solved by DNSSEC. There are a lot of mitigations to prevent BGP hijacks that I won't get too much into. None are 100%, but they are good enough to ensure multi-perspective validation refuses to issue a TLS certificate. The problem is that if those same mitigations are not deployed on your DNS servers (or you outsource DNS and they have not deployed these mitigations) it is a weak link.
    - tptacek 1y ago
      I don't see you responding to the question. You're fixating on protections for DNS servers, because that is the only circumstance in which DNSSEC could matter for these threat actors, not because they can't target the address space of the TLS servers themselves (they can), but because if you concede that they can do this, DNSSEC doesn't do anything anymore; attackers will just leave DNS records intact, and intercept the "authentic" server IPs. So far your response to this has been "attackers can't do this to Cloudflare". I mean, stipulated? Good note? Now, can you draw the rest of the owl?
      - iscoelho 1y ago
        I am focusing on DNS because this thread is about DNSSEC. The topic of doing it in to the TLS servers themselves is a tangent not relevant to this thread.
        tptacek 1y ago
        No, I'm sorry, that's not the case. You're focusing on DNS servers as the target for BGP4 attacks because if you didn't, you wouldn't have a rebuttal for the very obvious question of "why wouldn't BGP4 attackers just use BGP4 to intercept legitimate ALPN challenges". The thread is right here for everyone to read.
cyberax 1y ago
> You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. An attacker impersonating a DNS server still won't be able to forge the DNSSEC signatures.
- tptacek 1y ago
  No, they can't. Why would they bother? They'll just impersonate the IP the CA uses for the ALPN challenge.
  - cyberax 1y ago
    Well, this won't work with DNSSEC. It's a good argument for it.
    - akerl_ 1y ago
      An attack against BGP where the attacker takes over traffic for an IP address isn't at all prevented by DNSSEC. The sequence there is: 1. I hijack traffic destined for an IP address 2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.
      - cyberax 1y ago
        Sure. But you won't have a TLS certificate for that address, if the host uses a DNS-based ACME challenge and prohibits the plain HTTP challenge: https://letsencrypt.org/docs/caa/ https://letsencrypt.org/docs/caa/ So DNSSEC still offers protection here.
        1y ago

iscoelho 1y ago

> I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You claim it is fine-tuned, but it has happened in the real world. It is actually even better for attackers that it is "obscure", because that means it is harder to detect. > but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. Yes, all layers of the stack need to be secure. I am not making assumptions about the other layers - this thread is about DNS. > if the CA is capable of using any information to detect that this might be a forgery They are not. The only mitigation is "multi-perspective validation", which only addresses a subset of this attack. > And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking Yes, because other kinds of DNS hijacking are solved by HTTPS TLS. If TLS and CAs are broken, nothing is secure.

dwattttt 1y ago
> You claim it is fine-tuned, but it has happened in the real world. Sure, but it seems like his comment is still responsive; if DNSSEC is deployed, they perform a BGP hijack & can impersonate everyone, and they just impersonate the server after the DNS step? If that's the threat model you want to mitigate, it seems like DNSSEC won't address it.
- iscoelho 1y ago
  > and they just impersonate the server after the DNS step? Yes, there are different mitigations to prevent BGP hijacking the webserver itself. Preventing a rogue TLS certificate from being issued is the most important factor. CAA DNS records can help a bit with this. DNS itself however is easiest solved by DNSSEC. There are a lot of mitigations to prevent BGP hijacks that I won't get too much into. None are 100%, but they are good enough to ensure multi-perspective validation refuses to issue a TLS certificate. The problem is that if those same mitigations are not deployed on your DNS servers (or you outsource DNS and they have not deployed these mitigations) it is a weak link.
  - tptacek 1y ago
    I don't see you responding to the question. You're fixating on protections for DNS servers, because that is the only circumstance in which DNSSEC could matter for these threat actors, not because they can't target the address space of the TLS servers themselves (they can), but because if you concede that they can do this, DNSSEC doesn't do anything anymore; attackers will just leave DNS records intact, and intercept the "authentic" server IPs. So far your response to this has been "attackers can't do this to Cloudflare". I mean, stipulated? Good note? Now, can you draw the rest of the owl?
    - iscoelho 1y ago
      I am focusing on DNS because this thread is about DNSSEC. The topic of doing it in to the TLS servers themselves is a tangent not relevant to this thread.
      - tptacek 1y ago
        No, I'm sorry, that's not the case. You're focusing on DNS servers as the target for BGP4 attacks because if you didn't, you wouldn't have a rebuttal for the very obvious question of "why wouldn't BGP4 attackers just use BGP4 to intercept legitimate ALPN challenges". The thread is right here for everyone to read.

cyberax 1y ago

> You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. An attacker impersonating a DNS server still won't be able to forge the DNSSEC signatures.

tptacek 1y ago
No, they can't. Why would they bother? They'll just impersonate the IP the CA uses for the ALPN challenge.
- cyberax 1y ago
  Well, this won't work with DNSSEC. It's a good argument for it.
  - akerl_ 1y ago
    An attack against BGP where the attacker takes over traffic for an IP address isn't at all prevented by DNSSEC. The sequence there is: 1. I hijack traffic destined for an IP address 2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.
    - cyberax 1y ago
      Sure. But you won't have a TLS certificate for that address, if the host uses a DNS-based ACME challenge and prohibits the plain HTTP challenge: https://letsencrypt.org/docs/caa/ https://letsencrypt.org/docs/caa/ So DNSSEC still offers protection here.
      - 1y ago