Re: [dns-privacy] New dnscrypt Web site

[Brian Hartvigsen]

On 2/15/18, 2:45 AM, "dns-privacy on behalf of Stephane Bortzmeyer" 
 wrote:

https://dnscrypt.info

You'll note that the 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".

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...)

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

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

-- Brian


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] New dnscrypt Web site

[Sara Dickinson]

> On 15 Feb 2018, at 09:45, Stephane Bortzmeyer  wrote:
> 
> https://dnscrypt.info
> 
> You'll note that the FAQ  includes a
> 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 


Sara. 


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] New dnscrypt Web site

[Stephane Bortzmeyer]

https://dnscrypt.info

You'll note that the 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"

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