Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C21120373 for ; Mon, 25 Mar 2019 01:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.501 X-Spam-Level: X-Spam-Status: No, score=-12.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V83e2EMGrRFZ for ; Mon, 25 Mar 2019 01:28:39 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFCF120379 for ; Mon, 25 Mar 2019 01:28:35 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id v14so7999817wmf.2 for ; Mon, 25 Mar 2019 01:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U2DwHRbWY1As9zGVJsy0R1Uw3WPDleACy9pcQqC0Rrk=; b=V8qK4pvIGdmJU+9wjkAwRZvlDK2cG4b3urAfmmsem0OGmoJw3OLNKq+m2L571XijYk ySlxZESxUVA0mkRzBzWA+Q9iD/sVA0Qur2ZALWclMoQSsBwDI/70N8gZEN7mzmogo5il FkBJQ0l6PG+tdBea8XJsqkui3nkwrqCazNQTfwCVXiyz7ulmp+Kn+fNhCmI1BxWPKH4B qyQ9sSVcxpBdJ8funqmg3zCWAYij/DMTaJx05qRQb/zTIqIfGmzrlI8ueSWJtnn9uzzA 83n6LlqZk9k1iiWtdZy1GRr63aZsg+zbeBkO/0JIoBzRqYjxKUT/ZABIXqNlJ1UX7jNZ sTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U2DwHRbWY1As9zGVJsy0R1Uw3WPDleACy9pcQqC0Rrk=; b=kOAmWGjgXsrpe4AELzeNm/GC3+EQO0H58t2F2Jw0HxhwNE8OdfcKPwF54EIP8GKOKC GBxsKvNzIuJRcQcDQxmiOCH/DAhPYiSaEiq4W0H8KiHaMMHIUbYujnN+s0F4e1qKlKse n6pFBIEDfcmOq/i5ZkTCvPnahfTn+l12v66oGdR12gtk1XKQZYwaeYle7/vBUiSMIzNi CKZ9lGLf1k3oXk7sUHcneLMGREE4hIoiWrEuPco95q3iUcD6R4VjzZW9aqOxvGtEAgAk 3F9DkImX3DX38pY1ZoGAn1oG/tv5QLaKu/qRUHlcbSeQKwozAPnh5HB33lbMlxr7v7IH sEBw== X-Gm-Message-State: APjAAAXPUdVfubsQDj1tmdTS0oKT85HZdX2LaTlw2I8n1kNnwUjQPma1 P5v4EP8vT3Dvd/LDh1ijdR2ehj/SjFrXjGShcRseag== X-Google-Smtp-Source: APXvYqzE0EQsJhR2eNp7OwgiA7NOkbRPefgcpZYGHdgvZ2ONTYJl+j6vmvyQVa5X2YdXHP6TwclVogTaBo8U/ZMZwmY= X-Received: by 2002:a1c:9c0e:: with SMTP id f14mr11050652wme.78.1553502513842; Mon, 25 Mar 2019 01:28:33 -0700 (PDT) MIME-Version: 1.0 References: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net> <1878722055.8877.1553241201213@appsuite.open-xchange.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> In-Reply-To: From: Ian Swett Date: Mon, 25 Mar 2019 04:28:21 -0400 Message-ID: To: Brian Dickson Cc: Patrick McManus , Eric Rescorla , "doh@ietf.org" , "wjhns1@hardakers.net" , "dnsop@ietf.org" , "Winfield, Alister" , "huitema@huitema.net" , "vittorio.bertola=40open-xchange.com@dmarc.ietf.org" Content-Type: multipart/alternative; boundary="0000000000007f34570584e6fd15" Archived-At: Subject: Re: [Doh] [DNSOP] [EXTERNAL] Re: New I-D: draft-reid-doh-operator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:28:41 -0000 --0000000000007f34570584e6fd15 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > > On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus > 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.dickson@gmail.com> wrote: >> >>> >>> >>> Sent from my iPhone >>> >>> On Mar 24, 2019, at 10:42 PM, Patrick McManus >>> wrote: >>> >>> >>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < >>> brian.peter.dickson@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 > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000007f34570584e6fd15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One way DoH may be faster than DoT in the near future is t= hat DoH can go over HTTP/3 via QUIC and avoid head of line blocking like Do= 53.

On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson <brian.peter.dickson@gmail.com> wrote:
=


On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <mcmanus@ducksong.com<= /a>> wrote:
<= div dir=3D"ltr">
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 net= work to provide a clear channel for traffic analysis and downgrade triggers= .

fwiw - there are lots of reasons an ht= tp client is going to be interested in an http substrate beyond just traffi= c analysis defense. It has the potential for better overall application res= ponsiveness - by sharing connections and handshakes with other http data. I= don't think that particular discussion is important to this thread.







Brian

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

=C2=A0

On Mon, Mar 25, 2019 at 6:35 AM Brian Dickso= n <br= ian.peter.dickson@gmail.com> wrote:


Sent from my iPhone

= On Mar 24, 2019, at 10:42 PM, Patrick McManus <mcmanus@ducksong.com> wrote:

On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <brian.peter.dickson@gma= il.com> wrote:

This is important for network operators in identifying encrypted= DNS traffic,

not all cl= ients 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 R= ST injection attack.

If the client does acknowledg= e the network has the right to set policy - then the policy can be set on t= he 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 s= pace.

What I find interesting, is that as far as I ca= n tell, everything you wrote applies equally to DoH and DoT, if the transpo= rt is the only difference. E.g. Same client browser, same DNS service, acce= ssed via DoH or DoT.

Are you suggesting (or claimi= ng) otherwise, and if so, please elaborate?

Brian= =C2=A0
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000007f34570584e6fd15--