One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson <brian.peter.dick...@gmail.com>
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <mcma...@ducksong.com>
> 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 <
>> 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
>>>
>> _______________________________________________
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
