Subject: [dns-privacy] New dnscrypt Web site

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 15 Feb 2018 10:45:29 +0100

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 :-(

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 19 Feb 2018 11:33:25 +0000

> On 15 Feb 2018, at 09:45, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> https://dnscrypt.info
> 
> comparison with IETF solutions.

I suspect this might be partly in response to Tenta’s page (published last December) arguing for DNS-over-TLS rather than DNSCrypt  :-)

https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt <https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt>

Sara.

---

From: Brian Hartvigsen <[email-masked]>
Date: Tue, 20 Feb 2018 12:37:16 -0700

On 2/15/18, 2:45 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]> wrote:

    https://dnscrypt.info

    

Honestly, I'm not sure this is something I'd call out as a major benefit personally, but not for the reasons you listed.  It's the same as if you don't install the root certificate I want you to on my network -- you just don't get access at all.  But in some cases, that's exactly what the end user wants.

The cryptography primitives behind DNSCrypt has been tested, evaluated, and are published via IETF (RFC7539 & RFC7748.)  The entire DNSCrypt protocol has been published for some time (since 2011 iirc, version 2 in 2013.)  I read this section to be that DNSCrypt doesn't have a root certificate store that you can install a custom root to -- the industry-standard way of TLS interception/monitoring.  You either have the private key matching the fingerprint I want, or you don't.  (Of course, if I'm retrieving that public key from DNS/HTTP/etc, what proves that I have the right key...)

Joke used to be that everything would run over port 80, I guess at least it's now encrypted right?

-- Brian