Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Brian Dickson <[e-mail]>]

On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <[e-mail]>
wrote:

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

Actually, it really is.

At a minimum it needs to be treated as an assertion that is subject to
validation or refutation.

This is a refutation:

The DoH operators who have made public statements (google and cloudflare
are two I am aware of), have specifically indicated that NO OTHER HTTPS
TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.

So, the handshakes and sharing argument is specious at best, and bogus at
worst.

The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
DoT does not require the encoding/decoding of the DNS messages (plus all
the other HTTP overhead).
Both DoT and DoH require DNS messages in wire format be constructed first,
and after whatever decoding, wire format responses processed by the client.

A cursory analysis of the logic -- extra encoding vs no extra encoding --
essentially proves by "the triangle inequality"* that DoH cannot be faster
than DoT when comparing same-client to same-server.

Brian

*(the sum of lengths of two sides is greater or equal to the length of the
third side) In this case two sides are the same length (processing of TLS
and DNS) and the other side is extra processing of HTTP encoding, headers,
etc., and the sum is (HTTP + common path) , compared with (common path).
HTTP is not a zero-cost flow, so HTTP + x > x. QED.



>
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus <[e-mail]>
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> [e-mail]> 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
>>
>