On Sun, 26 Apr 2015, Watson Ladd wrote:
If what we end up with is doing the same crypto operations as DNSCrypt, but with the extra complexity of managing connections (opening, closing, resuming, etc), what is the advantage?
I've said this before...... My understanding of dnscrypt is that it is just a static preconfigured VPN using some custom way of sending an X.509 certificate over TXT records, using some adhoc headers thrown in. The closest thing to a specification I can find is: https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES which states: One or more TXT records are returned, each containing a signed certificate. The provider public key is only used to verify a certificate, never for authenticating/encrypting queries. Certificates have the following header: - 4 byte magic header DNSC - 2 byte major version - 2 byte minor version Followed by signed content (the signature adds 512 bits to the payload): - server 256-bit public key - 8 byte magic header to use for queries using this specific key - 4 byte serial number - 4 + 4 byte validity period (two timestamps) I'm unsure why we need a new way to authenticate that shoves certs in adhoc TXT recods. Why not use TLS on some other port, even if we then later to DNS on port 53 with whatever dnscrypt magic? If this is a really cool way of doing things (which I don't think it is) than we should not be using TXT records but a new RRTYPE. It also seems rather hardcoded with odd values, very un-agile and centered on The One True Encryption Protocol. And dnscrypt is then topped of with: This is the current structure of the second version of the protocol. Don't assume anything about its length, it is very likely to change after a version bump. So the designers have no idea if they are going to completely rewrite this. Does not sound like it is anywhere near ready for standardization. Which is why dnscrypt is not a real contender and we should steer this discussion back to the 3 considered proposals.
We know that approaches similar to DNSCrypt don't have these problems.
So this seems to be a statement that cannot be translated into technical terms. What is this "similar approach" that is missing from the other proposals that supposedly makes dnscrypt so much different and better? In fact, I see nothing that makes dnscrypt any better that using a preconfigured X.509 based IPsec VPN possibly limited to udp/tcp 53 traffic selectors. dnscrypt might be a nice hack to solve a short term issue in light of hostile and/or never-upgraded networks with some success of bypassing the network administrator restrictions. But it is not an architecture for future deployment. Paul _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
