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

Ian Swett <ianswett@google.com> Mon, 25 March 2019 08:28 UTC

Return-Path: <ianswett@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69571120373 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:28:39 -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 IijKQImK3C4x for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:28:38 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 8E600120365 for <dnsop@ietf.org>; Mon, 25 Mar 2019 01:28:35 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id o10so928243wmc.1 for <dnsop@ietf.org>; 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=jVPxLVbg97UQP7r2Nd0vXJ5c7Nea6YLqniA4Eh1qt4g83vR4L0oRNJ72Ng+BMtPZ6O LDN584tXe1SiDtW1lr22GI7hKKw7EwLWhYHDq1mVKzDo9xA6HxliDXfKYtaB9R5DS6ls Vtfr5I2xkYVwuSSHcAAlNpjJidaXzpyEqsEboFcpFyfL69peojlKb/rpV2tLLoKDWRcO 3AHZ/hrRqe0I5QybL0JS34BzZ664604dfbScxO4CMzUl99XZX88HKv/UPwTaxJ7KkF/t iHe5YEGmfS6oJfe5f1ttYYizEuY7eNtQxfLe+DNZ4BALXOH5hCbe00HHsilDTJLY5TXa OxSQ==
X-Gm-Message-State: APjAAAXZZuIaMcDsh0CyG7fp3rE5bz9Yt0voTbIPMUg+Rd71z1ebJ5h5 A5wl0LGZlzNBGIsG5xD1ZoQ5dGAXPkkkZdeZneKT1Q==
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> <CABcZeBPmpN-cEPK92QQW3bkvc41Cx5g7B_YuUXCJK3j1qF995Q@mail.gmail.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <CAOdDvNqb2+4Az+g608QRjYt+ZdUt1L9GAc=MJM3-xd0ZNmeBEQ@mail.gmail.com> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> <CAOdDvNrQiM2bpi65tCvwjanQTM1KtcZjRL0aOwS2oAryTR-YEA@mail.gmail.com> <E7E54A3B-4C85-4B64-BEFD-51891534DC9D@gmail.com> <CAOdDvNqKja9SRWa7FpjnGR3XZbVwZbitoU0yuWc+oXw3xXFEQA@mail.gmail.com> <CAH1iCiq-XaeTN_O7rDkKQy6OQaqqyMb=dFoQ-gAEjTMOsVbcBQ@mail.gmail.com>
In-Reply-To: <CAH1iCiq-XaeTN_O7rDkKQy6OQaqqyMb=dFoQ-gAEjTMOsVbcBQ@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 25 Mar 2019 04:28:21 -0400
Message-ID: <CAKcm_gNfx6nx9f1C+=VkUHyPjsP7S4yjEUo_xq76GsNT5gzY3A@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, Eric Rescorla <ekr@rtfm.com>, "doh@ietf.org" <doh@ietf.org>, "wjhns1@hardakers.net" <wjhns1@hardakers.net>, "dnsop@ietf.org" <dnsop@ietf.org>, "Winfield, Alister" <Alister.Winfield=40sky.uk@dmarc.ietf.org>, "huitema@huitema.net" <huitema@huitema.net>, "vittorio.bertola=40open-xchange.com@dmarc.ietf.org" <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f34570584e6fd15"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9mbt9ao_pwlb95Njy9LXd9yXmyI>
Subject: Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 08:28:39 -0000

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.dickson@gmail.com>;
wrote:

>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <mcmanus@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.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@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
>