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