I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.
And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.
fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.
On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <brian.peter.dick...@gmail.com>
wrote:
>
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus <mcma...@ducksong.com>
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>> traffic,
>>
>
> not all clients acknowledge a network's right to do such things at all
> times. And of course it would be useful to tell the difference between
> policy and a RST injection attack.
>
> If the client does acknowledge the network has the right to set policy -
> then the policy can be set on the client using existing configuration
> mechanisms that allow the client to differentiate between authorized
> configuration and perhaps less-authorized folks identifying their DNS
> traffic. This is well worn ground in the HTTP space.
>
>
> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>
> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>
> Brian
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
