https://dnscrypt.info You'll note that the FAQ <https://dnscrypt.info/faq/> includes a comparison with IETF solutions. Some remarks:
1) dnscrypt "Cannot be MITM’d by standard tools" vs. DNS-over-TLS "Readily compatible with industry-standard TLS interception/monitoring devices" This seems a strange approach of security. Using non-standard and little-known tools in the hope there will be less ready-made kits for script kiddies, works only on a very short term. It is a bit like "I coded my own CMS in PHP, it is full of security holes but because it is not the standard Wordpress / Drupal security holes, I'm secure". 2) dnscrypt "Specifically designed for DNS" I'm not sure why it's counted as a strength… 3) dnscrypt "Post-quantum version in developement" <https://github.com/jedisct1/dnscrypt-proxy/tree/pq> Buzzword-compliant, for sure but, in the current state of DNS security (zero encryption most of the time), the problem of quantum computers breaking RSA, ECDSA and EdDSA is not my biggest concern. Also, TLS may incorporate post-quantum crypto, no? (For those who want to follow the IETF work on PQ, see draft-hoffman-c2pq.) 4) DNS-over-TLS "Not well understood even by its proponents" I confess, I understand nothing to TLS but I assume the RFC 7858 authors are better than me. 5) DNS-over-TLS "Padding rules haven’t been specified" No longer true now that draft-ietf-dprive-padding-policy has been submitted to IESG 6) DNS-over-TLS "TLS is a generic transport mechanism. It doesn’t support reordering and parallelism" It seems they didn't read RFC 7766 (which, alas, is far from being implemented everywhere.) 7) DoH "Uses standard HTTP/2, on the standard port (443)." Not sure it is a good thing that all the Internet runs over port 443 :-( _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
