4 ms·

I never understood why they didn’t tried to push OSCP into DNS. You have to trust the DNS server more than you trust the server you are reaching out to as the

I never understood why they didn’t tried to push OSCP into DNS. You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.

woodruffw 1y ago
How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.
- dogma1138 1y ago
  Similarly to how OCSP stapling was supposed to work.
  - woodruffw 1y ago
    “Supposed to” being operative, I think!
cyphar 1y ago
Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...
- jve 1y ago
  > then the entirety of TLS PKI would be entirely redundant... Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
  - cyphar 1y ago
    If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. There would be no need for the authentication provided by CAs, but you would still want to use TLS. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
  - catlifeonmars 1y ago
    TLS != the current TLS PKI, which is the distinction GP is making I think. Although tbh I think that just moves the problem somewhere else (which is perfectly fine if you don’t like the current PKI).
- catlifeonmars 1y ago
  > If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant I’m not sure I understand the logic here. To me TLS PKI and DNS are somewhat orthogonal.
- crote 1y ago
  Does it, though? In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS. Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either. If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
  - ekr____ 1y ago
    > In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS. Yes, except for CT, which can help detect this kind of attack. > Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either. I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly. > If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs. This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
    - cyphar 1y ago
      > This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate. Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that. From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)
- ekr____ 1y ago
  This isn't true. Even if the DNS server is secure, the network between you and the server cannot be trusted.
  - cyphar 1y ago
    If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. I'm saying there would be no need for CAs -- you could just trust self-signed certs. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
cortesoft 1y ago
TLS is to protect you from malicious actors somewhere along your connection path. DNS can't help you. Just imagine you succeeded in inventing a perfectly secure DNS server. Great, we know this IP address we just got back is the correct one for the server. Ok, then I go to make a connection to that IP address, but someone on hop 3 of my connection is malicious, and instead of connecting me to the IP, just sends back a response pretending to be from that IP. How would I discover this? TLS would protect me from this, perfectly secure DNS won't.
- parliament32 1y ago
  If you had a perfectly secure DNS service, you could just stick the certificate fingerprint in DNS and be done. No need for trust stores, CAs, trust chains, OSCP/CRLs...
  - cortesoft 1y ago
    How would you revoke a certificate? If you are running a malicious DNS server, couldn't you just refuse the update and keep servicing the prior results?
    - parliament32 1y ago
      If the DNS service is "perfectly secure", we're assuming MITM attacks are impossible. You wouldn't need to revoke anything, you just update the fingerprint in the record.
      - cortesoft 1y ago
        Why would DNS being perfectly secure make MITM attacks impossible? It might be impossible to hijack DNS, but after DNS resolution happens, then the actual connection via IP address has to happen. If you are saying every packet sent is secure, then it would have nothing to do with DNS?
        cyphar 1y ago
blackcatsec 1y ago
Sounds like something DANE could be used for.

woodruffw 1y ago

How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.

dogma1138 1y ago
Similarly to how OCSP stapling was supposed to work.
- woodruffw 1y ago
  “Supposed to” being operative, I think!

cyphar 1y ago

Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...

jve 1y ago
> then the entirety of TLS PKI would be entirely redundant... Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
- cyphar 1y ago
  If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. There would be no need for the authentication provided by CAs, but you would still want to use TLS. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.
- catlifeonmars 1y ago
  TLS != the current TLS PKI, which is the distinction GP is making I think. Although tbh I think that just moves the problem somewhere else (which is perfectly fine if you don’t like the current PKI).
catlifeonmars 1y ago
> If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant I’m not sure I understand the logic here. To me TLS PKI and DNS are somewhat orthogonal.
crote 1y ago
Does it, though? In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS. Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either. If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.
- ekr____ 1y ago
  > In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS. Yes, except for CT, which can help detect this kind of attack. > Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either. I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly. > If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs. This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.
  - cyphar 1y ago
    > This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate. Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that. From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)
ekr____ 1y ago
This isn't true. Even if the DNS server is secure, the network between you and the server cannot be trusted.
- cyphar 1y ago
  If DNS was presumed secure (i.e., secure against MITM at all points in the chain) you could just stuff the public key into a DNS record (a-la DANE) and remove the need for PKI. I'm saying there would be no need for CAs -- you could just trust self-signed certs. Some might argue DNSSEC solves this already, I'm not particularly convinced it's any better than the original CA cabal.

cortesoft 1y ago

TLS is to protect you from malicious actors somewhere along your connection path. DNS can't help you. Just imagine you succeeded in inventing a perfectly secure DNS server. Great, we know this IP address we just got back is the correct one for the server. Ok, then I go to make a connection to that IP address, but someone on hop 3 of my connection is malicious, and instead of connecting me to the IP, just sends back a response pretending to be from that IP. How would I discover this? TLS would protect me from this, perfectly secure DNS won't.

parliament32 1y ago
If you had a perfectly secure DNS service, you could just stick the certificate fingerprint in DNS and be done. No need for trust stores, CAs, trust chains, OSCP/CRLs...
- cortesoft 1y ago
  How would you revoke a certificate? If you are running a malicious DNS server, couldn't you just refuse the update and keep servicing the prior results?
  - parliament32 1y ago
    If the DNS service is "perfectly secure", we're assuming MITM attacks are impossible. You wouldn't need to revoke anything, you just update the fingerprint in the record.
    - cortesoft 1y ago
      Why would DNS being perfectly secure make MITM attacks impossible? It might be impossible to hijack DNS, but after DNS resolution happens, then the actual connection via IP address has to happen. If you are saying every packet sent is secure, then it would have nothing to do with DNS?
      - cyphar 1y ago

blackcatsec 1y ago

Sounds like something DANE could be used for.