Re: debcheckroot v2.0 released
On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote:
>> There are a few reasons why I believe that DANE / TLSA DNS RR answers
>> are quite trustworthy:
Yes, DANE / TLSA DNS RR answers seem trustworthy. What I don't
consider trustworthy is the clear-text traffic between the client and
the DNSSEC enabled resolver.
Let's say that I'm using 1.1.1.1 as my resolver. Cloudflare comes up
with a trustworthy answer, but I don't trust the clear-text traffic
from Cloudflare to my PC. With DOH, I can trust the answer that comes
back from Cloudlfare to my PC.
>> * DNS responses are much faster than establishing a TCP connection
>> (1.5RTT), usually only about 40ms also because DNS servers tend to be
>> near the user if not provided by the ISP while the server you wanna
>> contact is usually in another country or another federal state. As we
>> know from the Snowden Revelations spoofing connections only works if the
>> spoofed response is faster than the original response. My idea about it
>> is that the NSA and related intelligence simply do not have an
>> infrastructure to spoof DNS responses.
Maybe not.. but I keep going back to the basic idea (prejudice?) that
clear-text traffic is inherently untrustworthy. What any particular
group can/can't do is not an interesting question to me.
>> * There is a public/private key signing infrastructure for DANE as well
>> but I consider that more secure than a gpg private key used on a system
>> with emailing or web browsing. I believe it is much more hard to get
>> into a server than is to get into a client.
>>
>> Finally DANE has been invented for the reason to restore trust in the
>> internet - as it was there initially when there was no operation Quantum
>> insert or similar operations. I´d believe the DANE system has been
>> designed secure as to serve its purpose. Finally my own practical
>> experience with DANE is very positive. It appeared to be the only way to
>> prevent site spoofing:
>> https://lists.debian.org/debian-security/2020/01/threads.html
>> https://lists.debian.org/debian-security/2020/02/threads.html
>> https://lists.debian.org/debian-security/2020/03/threads.html
>>
>> The reason why browser developers have not adopted DANE yet is that
>> they side with intelligence (secret services) as the following bug
>> report shows me:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802
If I'm understanding your bug report correctly, I'm not at all
surprised they didn't change anything. It seems like what you want is
the modern equivalent of the Cert Patrol addon; it's a shame that
functionality isn't in firefox any more :(
> Finally I have forgotten about the most important reason why DANE is
> much more secure than other methods:
>
> * There is a regular, secure and automatic key rotation for DANE. With
> GnuPG keys can be happily stolen as they remain valid for a year or more
> and as there is no secure way to redistribute a new key.
Yes, GPG Key distribution/revocation seems to be a weak point.
> Concerning DoH/DoT I would rather believe these technologies to be
> detrimental as encryption adds an additional error prone overhead but
> does not contribute anything to the authenticity of the reply.
I don't trust clear-text communications; it seems like DoH/DoT solves
that problem.. at least for dnssec enabled domains. While encryption
adds an additional error prone overhead, I'll still take that risk
over the risk of using a clear-text communications channel.
> Encryption can be a source of arbitrary code execution exploits if not
> implemented properly. Encrypting DNS would have other application
> purposes and makes sense as long as you use a proxy. If you connect
> directly hiding the domain name is ineffective because someone who spys
> at the connection also knows the IPs you connect to and via SNI the
> cleartext of the domain you surf at.
Yes, but "trusting the answer" and "keeping my communications private"
are not quite the same thing. If we're talking about "trusting the
answer" I'll take DoT or running my own dnssec enabled resolver. When
I'm more concerned about "keeping my communications private" I'll take
TOR & accept the trade-off of slower speed.
Regards,
Lee
Reply to: