On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu <valentin.g...@gmail.com>
wrote:
> On Mon, 25 Mar 2019 at 09:15, 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.
>>>
>>
>>
>> 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.
>>
>
> That may be true for Google and Cloudflare right now. But if I will be
> running my own DoH server it would probably be on AWS or compute engine
> along with any other website I'm currently running, so the connection
> sharing WILL happen.
>
Okay, that's a useful anecdote/datapoint.
Have you considered whether you will need to operate DoT as well, in case
DoH is blocked from some networks that do not also block DoT?
I.e. fallback from DoH to DoT rather than fall all the way back to Do53?
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
