4 ms·

With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.) No cryptograph

With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.) No cryptographic system is perfect.

deleted 15y ago
[deleted]
tptacek 15y ago
This comment is tautological. The verification you're talking about works on the same principle as X.509 (SSL/TLS) does; all it does is attempt to give individual DNS zone holders the ability to sign their own names. But every zone has a parent zone upon whose security it depends. The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server. "No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.
- beaumartinez 15y ago
  What I meant was there are mechanisms that let you determine that a DNS answer is correct. I won't say more regarding this matter because you know a lot more about cryptography than I do. What do you think the best solution for this kind of problem is? PGP?
  - tptacek 15y ago
    I literally think 99.999% of the problem with HTTPS/TLS is UI. The UI for certificate management and validation is virtually unchanged since the 1990s. More importantly, Mozilla, Google, Apple, and Microsoft --- however well they mean --- are not appropriate stewards for the security of the whole fucking Internet. We need the secure UX required to outsource CA management to trusted third parties that unskilled users can reasonably choose among. Back to DNSSEC: What we do not need to do is take this extremely complex policy problem and bake it further into the Internet's infrastructure, so that only the greybeards at the IETF and the product managers at the five largest software companies in the world get to make choices about the Internet's security model. Today's HTTPS debacle was brought to you by a policy mistake. When we originally deployed HTTPS/TLS, we did not understand enough about the forces acting on us to make totally safe policy decisions. What we need is more flexibility and more thought, not the exact same system we have now baked into one of the core protocols on the Internet.
    - tlrobinson 15y ago
      Have you written about possible solutions? I'd be interested to hear them.
      - tptacek 15y ago
        Wouldn't it be neat if there was a dialog somewhere in your browser that gave you the option of trusting anything Colin Percival trusted, or anything that the EFF trusted?
        JoshTriplett 15y ago
        Seems like an awesome plan, but making it scale requires a lot of work. In this system, how do banks ensure their site shows up as secure in people's browsers? How do random sites of varying popularity? Actually, for many people their bank seems like a good start for the trust chain; visit them in person and get the information you need for your trust root. And unlike the certificate companies, banks have end-users as their customers, not people who want certificates.
- marshray 15y ago
  DNSSEC may have a lot of the same design limitations as HTTPS PKI, but it could still be an improvement if it represented a parallel, redundant piece of security. But what we see is CAs authenticating cert applicants based on DNS (the ability to receive email verifies your "control" of the domain) and DNSSEC rooting to a Verisign-managed registry, just like the early days of SSL PKI.
  - tptacek 15y ago
    Only if that parallel, redundant piece of security (a) isn't relied upon as a single point of failure by any component of the rest of the system (note how many DNSSEC advocates seem to want DNSSEC as a replacement for the X509 PKI), and (b) doesn't have 15 years of its own security vulnerabilities in store for us.
    - marshray 15y ago
      Yup. a) a rare opportunity missed b) I'd like to think we know more than we did 15 years ago, but compatibility with the existing DNS brings new challenges too
stock_toaster 15y ago
That may be true, but you have no guarantee that the IP that is returned actually routes where it should, or that a resulting connection is to one of google's actual servers. note: Nothing against dnssec. I think it is an improvement, but I don't see how it would have helped in the situation in question.
- tptacek 15y ago
  I don't think DNSSEC is an improvement. I think that when you take a fragile and problematic security model, reimplement it from the bottom up in a setting that's even more restrictive than HTTPS, bake the result into the core of the Internet (or rather, the fraction of the core of the Internet that knows how to be a full-fledged DNS server), cause untold disruption the network as a whole and incur tens of millions of dollars in administrative overhead that could have gone to other security objectives, you are very likely looking at a measure that maybe just maybe might be a tiny step backwards.
tlrobinson 15y ago
"With SSL when you make a request to google.com you can verify the answer is actually from google.com." That's exactly what SSL is supposed to do, and tptacek is saying DNSSEC has the same problems as any PKI, including SSL. And more importantly, using DNSSEC without SSL, even if you know you have the right IP address you don't you're not being MITM'd.

With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.) No cryptographic system is perfect.

deleted 15y ago

[deleted]

tptacek 15y ago

This comment is tautological. The verification you're talking about works on the same principle as X.509 (SSL/TLS) does; all it does is attempt to give individual DNS zone holders the ability to sign their own names. But every zone has a parent zone upon whose security it depends. The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server. "No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.

beaumartinez 15y ago
What I meant was there are mechanisms that let you determine that a DNS answer is correct. I won't say more regarding this matter because you know a lot more about cryptography than I do. What do you think the best solution for this kind of problem is? PGP?
- tptacek 15y ago
  I literally think 99.999% of the problem with HTTPS/TLS is UI. The UI for certificate management and validation is virtually unchanged since the 1990s. More importantly, Mozilla, Google, Apple, and Microsoft --- however well they mean --- are not appropriate stewards for the security of the whole fucking Internet. We need the secure UX required to outsource CA management to trusted third parties that unskilled users can reasonably choose among. Back to DNSSEC: What we do not need to do is take this extremely complex policy problem and bake it further into the Internet's infrastructure, so that only the greybeards at the IETF and the product managers at the five largest software companies in the world get to make choices about the Internet's security model. Today's HTTPS debacle was brought to you by a policy mistake. When we originally deployed HTTPS/TLS, we did not understand enough about the forces acting on us to make totally safe policy decisions. What we need is more flexibility and more thought, not the exact same system we have now baked into one of the core protocols on the Internet.
  - tlrobinson 15y ago
    Have you written about possible solutions? I'd be interested to hear them.
    - tptacek 15y ago
      Wouldn't it be neat if there was a dialog somewhere in your browser that gave you the option of trusting anything Colin Percival trusted, or anything that the EFF trusted?
      - JoshTriplett 15y ago
        Seems like an awesome plan, but making it scale requires a lot of work. In this system, how do banks ensure their site shows up as secure in people's browsers? How do random sites of varying popularity? Actually, for many people their bank seems like a good start for the trust chain; visit them in person and get the information you need for your trust root. And unlike the certificate companies, banks have end-users as their customers, not people who want certificates.
marshray 15y ago
DNSSEC may have a lot of the same design limitations as HTTPS PKI, but it could still be an improvement if it represented a parallel, redundant piece of security. But what we see is CAs authenticating cert applicants based on DNS (the ability to receive email verifies your "control" of the domain) and DNSSEC rooting to a Verisign-managed registry, just like the early days of SSL PKI.
- tptacek 15y ago
  Only if that parallel, redundant piece of security (a) isn't relied upon as a single point of failure by any component of the rest of the system (note how many DNSSEC advocates seem to want DNSSEC as a replacement for the X509 PKI), and (b) doesn't have 15 years of its own security vulnerabilities in store for us.
  - marshray 15y ago
    Yup. a) a rare opportunity missed b) I'd like to think we know more than we did 15 years ago, but compatibility with the existing DNS brings new challenges too

stock_toaster 15y ago

That may be true, but you have no guarantee that the IP that is returned actually routes where it should, or that a resulting connection is to one of google's actual servers. note: Nothing against dnssec. I think it is an improvement, but I don't see how it would have helped in the situation in question.

tptacek 15y ago
I don't think DNSSEC is an improvement. I think that when you take a fragile and problematic security model, reimplement it from the bottom up in a setting that's even more restrictive than HTTPS, bake the result into the core of the Internet (or rather, the fraction of the core of the Internet that knows how to be a full-fledged DNS server), cause untold disruption the network as a whole and incur tens of millions of dollars in administrative overhead that could have gone to other security objectives, you are very likely looking at a measure that maybe just maybe might be a tiny step backwards.

tlrobinson 15y ago

"With SSL when you make a request to google.com you can verify the answer is actually from google.com." That's exactly what SSL is supposed to do, and tptacek is saying DNSSEC has the same problems as any PKI, including SSL. And more importantly, using DNSSEC without SSL, even if you know you have the right IP address you don't you're not being MITM'd.