4 ms·

> Confidentiality isn't the killer feature/flaw here; integrity is. I initially posted "Authentication, too" in response to this, but then I reread the page an

> Confidentiality isn't the killer feature/flaw here; integrity is. I initially posted "Authentication, too" in response to this, but then I reread the page and it says it doesn't provide authentication. ...in which case, I don't really understand this at all. What good is integrity if there's no authentication? Doesn't that mean an active network attacker can completely swap out the DNS response for a different one, but just can't modify it (short of creating a brand new one)? If that's the case, it seems completely useless. It claims to protect against man-in-the-middle attacks, but I don't understand how that's possible if there's no authentication. I'm sure I'm missing something here.

tptacek 15y ago
DNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader". You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
- FaceKicker 15y ago
  Signed using a pair of static keys? So...it is authenticated then? Or are they more like SSH keys/self-signed certs where you just trust the key belongs to who you think you're talking to the first time?
  - tptacek 15y ago
    SSH is an authenticated protocol. The trust anchor scheme SSH uses is "key continuity". The same model has been proposed as a replacement for TLS CA certs. DNSCurve doesn't specify a key management scheme, but to the extent you want to call a bunch of web pages on Bernstein's site a "spec", it specifies "static keys". Static keys are a perfectly viable trust anchor scheme; like they say about routing, "if you can get away with it, the best protocol is static".
    - mike-cardwell 15y ago
      The trust anchor scheme SSH uses is "key continuity" There is also RFC4255 which allows people to publish fingerprints of their SSH server public key in DNSSEC secured "SSHFP" RRs. If you have a resolver which supports DNSSEC, you can run this command: ssh -o "VerifyHostKeyDNS yes" grepular.com You wont be prompted to verify the fingerprint as usual, because OpenSSH will already have done that verification using the DNS. You also know for sure that grepular.com has resolved to the correct IP address. There is also "VerifyHostKeyDNS ask", which just displays the result of the lookup, but still allows you to confirm the fingerprint. DNSSEC allows you to do stuff like this because it secures the integrity of the record all the way from the authoratitive DNS server to the users resolver. There's also DANE (still going through the standards process) which allows you to publish a fingerprint of your SSL certificate on a domain/port basis, in DNSSEC secured DNS. If you install a Firefox addon named "Extended DNSSEC Validator", visit https://grepular.com/ https://grepular.com/ and click the lock button to the left of the address bar, you will notice it says: "Domainname is secured by DNSSEC and the certificate is validated by CA and DNSSEC" This is because I'm following the latest draft of the DANE protocol. Will be nice when the spec is finalised and browser support becomes native. I don't like that any CA can currently generate a cert for my domain. Another benefit that DNSSEC brings is with PKA records. I publish a record in the DNS which contains a URL to my public PGP key, and its fingerprint. You can automatically download my key and encrypt something using it by typing: gpg --auto-key-locate pka -ear mike.cardwell@example.com Replacing "example.com" with "grepular.com". Because I also have DNSSEC set up on my domain, if you have a DNSSEC supporting resolver, you know that the fingerprint you've received hasn't been tampered with on the way. Of course, somebody could compromise my DNS server or the end users resolver. I'm not claiming that DNSSEC is a perfect solution. All I'm saying, is that the integrity that it provides to DNS lookups is massively valuable. By the way, I wrote a long article about setting up DNSSEC on Monday: https://grepular.com/Understanding_DNSSEC https://grepular.com/Understanding_DNSSEC [edit] I forgot to mention the "Certificate Stapling" functionality built into Chrome now. https://dnssec.imperialviolet.org/ https://dnssec.imperialviolet.org/ uses a self signed certificate, but Chrome users wont get any notification about that because of the tech described here: http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html [edit2] Another benefit I forgot to mention. I use third party DNS slaves for redundancy. Because I'm using DNSSEC, those third parties can't serve up different records to the ones I configured, either on purpose or because they've been compromised. Well, they could, but DNSSEC supporting resolvers would just SERVFAIL the modified responses.
deleted 15y ago
[deleted]
- tptacek 15y ago
  You're not thinking this through; there has to be a trust anchor somewhere, be it a config file with a known-good server key, or a CA signature, or a "this is the first time I've seen this pubkey, accept it forever?" dialog. In your protocol, any server can read that message and encrypt a valid-looking response.
  - dsl 15y ago
    Oops. I deleted my response because I saw you replied and addressed the authentication issue. Apparently I wasn't fast enough. :) The trust anchor is the --provider-key command line parameter. Any server that has the corresponding private key can encrypt a valid response. (and to be clear, its not my protocol.)

tptacek 15y ago

DNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader". You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.

FaceKicker 15y ago
Signed using a pair of static keys? So...it is authenticated then? Or are they more like SSH keys/self-signed certs where you just trust the key belongs to who you think you're talking to the first time?
- tptacek 15y ago
  SSH is an authenticated protocol. The trust anchor scheme SSH uses is "key continuity". The same model has been proposed as a replacement for TLS CA certs. DNSCurve doesn't specify a key management scheme, but to the extent you want to call a bunch of web pages on Bernstein's site a "spec", it specifies "static keys". Static keys are a perfectly viable trust anchor scheme; like they say about routing, "if you can get away with it, the best protocol is static".
  - mike-cardwell 15y ago
    The trust anchor scheme SSH uses is "key continuity" There is also RFC4255 which allows people to publish fingerprints of their SSH server public key in DNSSEC secured "SSHFP" RRs. If you have a resolver which supports DNSSEC, you can run this command: ssh -o "VerifyHostKeyDNS yes" grepular.com You wont be prompted to verify the fingerprint as usual, because OpenSSH will already have done that verification using the DNS. You also know for sure that grepular.com has resolved to the correct IP address. There is also "VerifyHostKeyDNS ask", which just displays the result of the lookup, but still allows you to confirm the fingerprint. DNSSEC allows you to do stuff like this because it secures the integrity of the record all the way from the authoratitive DNS server to the users resolver. There's also DANE (still going through the standards process) which allows you to publish a fingerprint of your SSL certificate on a domain/port basis, in DNSSEC secured DNS. If you install a Firefox addon named "Extended DNSSEC Validator", visit https://grepular.com/ https://grepular.com/ and click the lock button to the left of the address bar, you will notice it says: "Domainname is secured by DNSSEC and the certificate is validated by CA and DNSSEC" This is because I'm following the latest draft of the DANE protocol. Will be nice when the spec is finalised and browser support becomes native. I don't like that any CA can currently generate a cert for my domain. Another benefit that DNSSEC brings is with PKA records. I publish a record in the DNS which contains a URL to my public PGP key, and its fingerprint. You can automatically download my key and encrypt something using it by typing: gpg --auto-key-locate pka -ear mike.cardwell@example.com Replacing "example.com" with "grepular.com". Because I also have DNSSEC set up on my domain, if you have a DNSSEC supporting resolver, you know that the fingerprint you've received hasn't been tampered with on the way. Of course, somebody could compromise my DNS server or the end users resolver. I'm not claiming that DNSSEC is a perfect solution. All I'm saying, is that the integrity that it provides to DNS lookups is massively valuable. By the way, I wrote a long article about setting up DNSSEC on Monday: https://grepular.com/Understanding_DNSSEC https://grepular.com/Understanding_DNSSEC [edit] I forgot to mention the "Certificate Stapling" functionality built into Chrome now. https://dnssec.imperialviolet.org/ https://dnssec.imperialviolet.org/ uses a self signed certificate, but Chrome users wont get any notification about that because of the tech described here: http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html [edit2] Another benefit I forgot to mention. I use third party DNS slaves for redundancy. Because I'm using DNSSEC, those third parties can't serve up different records to the ones I configured, either on purpose or because they've been compromised. Well, they could, but DNSSEC supporting resolvers would just SERVFAIL the modified responses.

deleted 15y ago

[deleted]

tptacek 15y ago
You're not thinking this through; there has to be a trust anchor somewhere, be it a config file with a known-good server key, or a CA signature, or a "this is the first time I've seen this pubkey, accept it forever?" dialog. In your protocol, any server can read that message and encrypt a valid-looking response.
- dsl 15y ago
  Oops. I deleted my response because I saw you replied and addressed the authentication issue. Apparently I wasn't fast enough. :) The trust anchor is the --provider-key command line parameter. Any server that has the corresponding private key can encrypt a valid response. (and to be clear, its not my protocol.)