On Fri, Sep 22, 2017 at 8:12 AM, Tony Finch <dot@xxxxxxxx> wrote:
> Ted Hardie <ted.ietf@xxxxxxxxx> wrote:
>
>> I think you're underestimating the value of a switch to a multiplexing
>> facilitating protocol/transport. Once this has gotten its legs under it, I
>> suspect that this approach for connecting to caching resolver will perform
>> better than any of traditional upd/tcp connections or the tls/dtls
>> approaches DPRIVE created.
>
> DNS over TCP already supports out-of-order responses. The reason it has
> historically not performed very well is that server implementations have
> handled queries on a TCP connection serially rather than concurrently.
>
> But this is improving. BIND 9.11 (for example) supports concurrent queries
> with out-of-order responses over TCP and TCP fast open, so queries over
> TCP should perform well, and better than UDP for large responses.
>
Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858
("Specification for DNS over Transport Layer Security (TLS)").
So, these are only my personal views / no hats / etc, but to my mind
one of the main reasons that I'd like to see Doh! succeed is for
censorship resistance (in parallel with the dprive work).
Currently plain-text DNS leaks a huge amount of privacy information;
DPRIVE solves much of this, but one weakness is that it is still
clearly DNS traffic[0]. This allows bad, evil, no-good totalitarian
regimes to block it and force you to use resolvers under their control
and so can control what you can reach, or watch where you are going
and send the secret police to "re-educate" you if you are looking at
things you shouldn't be.
.
.
Now, reread the previous sentence with s/ bad, evil, no-good
totalitarian regimes / friendly corporate IT folk / and s/ the secret
police / human resources /.
This allows friendly corporate IT folk to block it and force you to
use resolvers which they control and so can contol what you can reach,
or watch where you are going and send human resources to re-educate
you if you are looking at things you shouldn't be.
This is (I believe) what Elliot was pointing out -- this is important
information for enterprises - it is used to limit liability, ensure
employees are not "wasting time", and corporate security to detect
that they need to re-image Bob's machine *again* because he persists
in clicking questionable links and installing random bits of malware.
Unfortunately you cannot separate case 1 from case 2 -- if you make it
something that enterprise folk can detect / block (on BYOD devices)
then you have provided that facility to everyone. I believe that this
is simply the "encryption should be outlawed / backdoored because it
helps <insert bad guy here>." argument in another guise[1].
If Doh! is done right in my view it should be indistinguishable from
other web traffic and / or the collateral damage from blocking it
would be (hopefully!) politically untenable.
W
[0]: either because it is using the domain-s ports (853) or through
fingerprinting / heuristics of the TLS stream if you do something like
just run it over port 443.
[1]: luckily this isn't at all controversial, and isn't going to suck
this thread down another rat-hole.
> Tony.
> --
> f.anthony.n.finch <dot@xxxxxxxx> http://dotat.at/ - I xn--zr8h punycode
> Faeroes, Southeast Iceland: Southeasterly 4 or 5, increasing 6 to gale 8
> later. Moderate or rough, occasionally very rough later. Showers, rain later.
> Good, becoming moderate or poor later.
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf