8 ms·

I don't want to go too far OT, but had a question if someone wouldn't mind answering it or pointing me to some materials. I've been digging into DNS and TLS la

I don't want to go too far OT, but had a question if someone wouldn't mind answering it or pointing me to some materials. I've been digging into DNS and TLS lately. Given the way ACME works (essentially using DNS to verify you own a domain before giving you a cert), what's the reason you can't just put your public key in a DNS record? I'm assuming it has something to do with security issues at the DNS level, but don't really know.

jcrawfordor 6y ago
This is basically the idea behind DANE. The problem is that DNS was historically unauthenticated and so just as vulnerable to on-path attacks as HTTP - perhaps more so due to the distributed, hierarchical nature which enables certain types of takeovers. DANE assumes that DNSSEC is in place, so that the DNS records are authenticated. This allows the DNS records to be used to deliver TLS trust information in a way that is still ultimately rooted in a certificate authority (whoever operates DNSSEC for the TLD). Adoption has been limited, mostly because adoption of DNSSEC itself has been limited, arguably because DNSSEC is overcomplicated and high-maintenance, but also just due to a lack of motivation. Similarly, users couldn't care less about how TLS trust is delivered and DANE has never really gotten a big corporate champion to push for it, so there just hasn't been the drive. Industry seems to have chosen DNS-over-HTTPS as the long-term solution to many of DNS's problems, and it clashes somewhat with DANE - I'm sure you could make them work together but it would definitely become awkward
- AndyMcConachie 6y ago
  Where DANE has seen pickup is in the SMTP space. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/
J0_k3r 6y ago
I'd also like an answer for this.
wgetch 6y ago
What happens if both DNS requests are hijacked? Could an attacker return both a different IP and a different public key that correspond to a malicious server? Edit: I should clarify, I think the issue stems from DNS being a potential attack vector itself. You can't blindly trust what DNS tells you. This is precisely the problem that certificate chains (issued by a trusted third party) purport to resolve-- one of trust.
- Ayesh 6y ago
  Well there's DNSSEC. Implementation details (such as lack of practice in key rotation, TTL, etc) aside, DNSSEC works and LetsEncrypt validates it. Then there is Certificate Transparency logs. It will be passive action at this point, but it's an action regardless. Let's Encrypt checks DNS validation and DNS CAA from multiple PoPs, but I don't think it's enforced by CA/B requirements to do so (happy to be corrected).
Polylactic_acid 6y ago
One possible reason is that its more likely that your individual dns is being modified/tampered with than it is for LEs servers. This way your individual ISP can't mess with things.
kilburn 6y ago
As other comments said, DNS is vulnerable to man-in-the-middle attacks without DNSSEC, and DNSSEC is not widely adopted. However, even with DNSSEC, bob could obtain domain.tld's keys and then use them to MITM alice's DNS requests, getting her browser to show a malicious site for domain.tld complete with a trusted certificate. Furthermore, bob can do this for alice and only alice, decreasing the odds of detection by a large margin. With LE you gain: - Targeted attacks harder to pull off, since you would need to successfully attack the LE servers/networks first and then your actual target. - LE participates in the certificate transparency initiative, meaning every time a certificated is emitted for a domain it gets recorded. These things are particularly relevant when you consider that in most cases the DNS is either directly or indirectly controlled by state actors at their root. With DNS-only, they could pull off such targeted attacks without anybody noticing. With LE, they can still pull off these attacks, but there would be a papertrail when that happened.
- tssva 6y ago
  DNSSEC is not about protecting MITM attacks against DNS traffic. DNSSEC is about validating that DNS records have not been tampered with. Are you thinking about DNS over HTTPS and DNS over TLS?
  - kilburn 6y ago
    I've always undrestood that MITM attacks can both be: - active (injecting/tampering with content), which is what DNSSEC protects against. - passive (eavesdropping), which is what DNS over TLS protects against. Am I missing something?
    - tssva 6y ago
      MITM involves monitoring and/or altering the traffic between two endpoints which believe they are talking directly. If DNS traffic between Alice's client and configured DNS server can be intercepted DNSSEC provides no real protection because unlike TLS all information to verify signed records are provided in band via DNS. Once the traffic can be intercepted and return traffic spoofed the attacker can return the appropriate records to make it appear that the response is properly signed without any need of having the DNSSEC keys being used at the authoritative DNS server for that domain. DNS over HTTPS, DNS over TLS and DNSCurve are intended to protect against this type of interception/tampering and should be used along side DNSSEC.

jcrawfordor 6y ago

This is basically the idea behind DANE. The problem is that DNS was historically unauthenticated and so just as vulnerable to on-path attacks as HTTP - perhaps more so due to the distributed, hierarchical nature which enables certain types of takeovers. DANE assumes that DNSSEC is in place, so that the DNS records are authenticated. This allows the DNS records to be used to deliver TLS trust information in a way that is still ultimately rooted in a certificate authority (whoever operates DNSSEC for the TLD). Adoption has been limited, mostly because adoption of DNSSEC itself has been limited, arguably because DNSSEC is overcomplicated and high-maintenance, but also just due to a lack of motivation. Similarly, users couldn't care less about how TLS trust is delivered and DANE has never really gotten a big corporate champion to push for it, so there just hasn't been the drive. Industry seems to have chosen DNS-over-HTTPS as the long-term solution to many of DNS's problems, and it clashes somewhat with DANE - I'm sure you could make them work together but it would definitely become awkward

AndyMcConachie 6y ago
Where DANE has seen pickup is in the SMTP space. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/

J0_k3r 6y ago

I'd also like an answer for this.

wgetch 6y ago

What happens if both DNS requests are hijacked? Could an attacker return both a different IP and a different public key that correspond to a malicious server? Edit: I should clarify, I think the issue stems from DNS being a potential attack vector itself. You can't blindly trust what DNS tells you. This is precisely the problem that certificate chains (issued by a trusted third party) purport to resolve-- one of trust.

Ayesh 6y ago
Well there's DNSSEC. Implementation details (such as lack of practice in key rotation, TTL, etc) aside, DNSSEC works and LetsEncrypt validates it. Then there is Certificate Transparency logs. It will be passive action at this point, but it's an action regardless. Let's Encrypt checks DNS validation and DNS CAA from multiple PoPs, but I don't think it's enforced by CA/B requirements to do so (happy to be corrected).

Polylactic_acid 6y ago

One possible reason is that its more likely that your individual dns is being modified/tampered with than it is for LEs servers. This way your individual ISP can't mess with things.

kilburn 6y ago

As other comments said, DNS is vulnerable to man-in-the-middle attacks without DNSSEC, and DNSSEC is not widely adopted. However, even with DNSSEC, bob could obtain domain.tld's keys and then use them to MITM alice's DNS requests, getting her browser to show a malicious site for domain.tld complete with a trusted certificate. Furthermore, bob can do this for alice and only alice, decreasing the odds of detection by a large margin. With LE you gain: - Targeted attacks harder to pull off, since you would need to successfully attack the LE servers/networks first and then your actual target. - LE participates in the certificate transparency initiative, meaning every time a certificated is emitted for a domain it gets recorded. These things are particularly relevant when you consider that in most cases the DNS is either directly or indirectly controlled by state actors at their root. With DNS-only, they could pull off such targeted attacks without anybody noticing. With LE, they can still pull off these attacks, but there would be a papertrail when that happened.

tssva 6y ago
DNSSEC is not about protecting MITM attacks against DNS traffic. DNSSEC is about validating that DNS records have not been tampered with. Are you thinking about DNS over HTTPS and DNS over TLS?
- kilburn 6y ago
  I've always undrestood that MITM attacks can both be: - active (injecting/tampering with content), which is what DNSSEC protects against. - passive (eavesdropping), which is what DNS over TLS protects against. Am I missing something?
  - tssva 6y ago
    MITM involves monitoring and/or altering the traffic between two endpoints which believe they are talking directly. If DNS traffic between Alice's client and configured DNS server can be intercepted DNSSEC provides no real protection because unlike TLS all information to verify signed records are provided in band via DNS. Once the traffic can be intercepted and return traffic spoofed the attacker can return the appropriate records to make it appear that the response is properly signed without any need of having the DNSSEC keys being used at the authoritative DNS server for that domain. DNS over HTTPS, DNS over TLS and DNSCurve are intended to protect against this type of interception/tampering and should be used along side DNSSEC.