7 ms·

Ask HN: I am asked would I prefer 1. to have a pre-generated cryptographic "signature" of every www page that can be checked against some centralized repositor

by gwu78 12y ago

Ask HN: I am asked would I prefer 1. to have a pre-generated cryptographic "signature" of every www page that can be checked against some centralized repository for "authenticity" or 2. to encrypt every www page before transmission or at least have it encrypted in transit? "Both" is not an valid choice. I have no idea why not; as far as I can tell, they are not mutually exclusive. Because I mindlessly support SSL (let's encrypt!) I choose option 2 over option 1. Now I am asked the same question regarding DNS packets. 1. Sign the packets or 2. encrypt them? Do I still choose option 2 over option 1? If I choose 1, those DNS requests will be unencrypted plain text like unencrypted HTTP. Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

danyork 12y ago
> Maybe DNSSEC has nothing to do with privacy regarding DNS requests? DNSSEC has nothing to do with privacy. DNSSEC is entirely about the integrity of DNS requests. DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about. That's it. DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.
- colmmacc 12y ago
  DNSSEC is probably better described as a mechanism to prevent cache poisoning; which is different from the "modified in transit" case. DNSSEC isn't very useful for defending against a MITM: 1. If the MITM goal is to block your domain, they still can by dropping the queries or replies. 2. If the MITM goal is to intercept your content, they don't need to rewrite DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here. Additionally, if the MITM is between you and your resolver: for example in the Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do not validate.
  - danyork 12y ago
    colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query. Yes, "cache poisoning". Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there. If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there. If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater. This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.
    - gwu78 12y ago
      Thank you for the answers. More questions: If I run my own DNS cache on 127., 172.16. or 10. then do I have to worry about "cache poisoning"? Do I still need to verify authenticity of the answers to my DNS requests? What if I can verify the authenticity of the authoritative DNS servers? If we were somehow able to encrypt the DNS packets between my resolver and authoritative servers on the internet, and I have verified the authenticity of those authoritative servers, should I still have concerns that the answers I get could be forged?

by gwu78 12y ago

danyork 12y ago

> Maybe DNSSEC has nothing to do with privacy regarding DNS requests? DNSSEC has nothing to do with privacy. DNSSEC is entirely about the integrity of DNS requests. DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about. That's it. DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.

colmmacc 12y ago
DNSSEC is probably better described as a mechanism to prevent cache poisoning; which is different from the "modified in transit" case. DNSSEC isn't very useful for defending against a MITM: 1. If the MITM goal is to block your domain, they still can by dropping the queries or replies. 2. If the MITM goal is to intercept your content, they don't need to rewrite DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here. Additionally, if the MITM is between you and your resolver: for example in the Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do not validate.
- danyork 12y ago
  colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query. Yes, "cache poisoning". Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there. If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there. If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater. This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.
  - gwu78 12y ago
    Thank you for the answers. More questions: If I run my own DNS cache on 127., 172.16. or 10. then do I have to worry about "cache poisoning"? Do I still need to verify authenticity of the answers to my DNS requests? What if I can verify the authenticity of the authoritative DNS servers? If we were somehow able to encrypt the DNS packets between my resolver and authoritative servers on the internet, and I have verified the authenticity of those authoritative servers, should I still have concerns that the answers I get could be forged?