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

Valentin Gosu <valentin.gosu@gmail.com> Mon, 25 March 2019 08:52 UTC

Return-Path: <valentin.gosu@gmail.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 8F18D1203EF; Mon, 25 Mar 2019 01:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.001
X-Spam-Level: ***
X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 e6pcNM4QHQ78; Mon, 25 Mar 2019 01:52:15 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 0419C1203CD; Mon, 25 Mar 2019 01:52:14 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id y63so1024805itb.5; Mon, 25 Mar 2019 01:52:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a8+ctBOkEF6JUuPyF694pOmMlluB+1FwDEEIfOExWTg=; b=s+8zVM+OKhlNEB9R4VYyRptUoogidunChkFxgOqlqOLLYRwffxXq83uyEAJmBdz+AR LnKrdx5W+zbDC/X5NcY0TApu3Pe6VrjMZfnpYkcGZr8766W83ynY2nLGQV6YCnW4T/P0 YVZ9szNDm+VBERFOvCwrV58t8qOeyDgcd5xfQTb52vB6S+hXPT3XSQ/RgZhLdtQ4uPKK 8VlzdLB5Eh19KufZ1yGtKVGSbPZSykHc7DbhM4hJsyCJPoW4h2hCxLN+/snuQoixJpFB k620q3aIZAvPs5b++WCkVuVBUNwyOJtG7GQ3BW8CUeYbcCQXKNpdGA6ePKdyFHDMCj33 1/tA==
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=a8+ctBOkEF6JUuPyF694pOmMlluB+1FwDEEIfOExWTg=; b=hoYv8gbMwTbr/JhX0y6y8t2XYFkxVlXodXyOfmxtAMduowPYMYnuTmyqxUgoteCYt3 NhFegz6K/jPKW8yPT+Nvx+4Yibb/r643+Db5oVvIv3HXhK83FdwcX5yIvxORVvK/H19A Y2skysTBBiKsHb3+fzWVBlCsBYpBH6pRgaI9LgVszJKm5wEbgKDl12S+4f2Y6nS63Nos hEjG2hPi46jMGrleXWbXV6QUb9q0Zv3NnY4+rWhLEEFLo7R2vIoKKGJ4B3+U9K3VqBus lUQ+XyhOH6SPRspC+updbDXE6RLNZOYJodnZzlhuDUToxFp4FoeDNvv2jF5D3jk+at2C UZ6w==
X-Gm-Message-State: APjAAAV+ONLCgLYFA95ULDqFQXi6TkszKLd2MtdIm5ZpO8eeEmk7d0KH SQ6jSBryQNVVnEvyEbDnyn2uuaawgFIPmUBf9WQ=
X-Google-Smtp-Source: APXvYqynO15yvlIcjauV2wjdPZLNLjIgZt9k4cPoOZzOdC40SLjbUHlvLFBxQppTLSl7u3eBqFwNDMSBVwo4sLTiq8Q=
X-Received: by 2002:a24:d245:: with SMTP id z66mr11400557itf.47.1553503933223; Mon, 25 Mar 2019 01:52:13 -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: Valentin Gosu <valentin.gosu@gmail.com>
Date: Mon, 25 Mar 2019 09:52:01 +0100
Message-ID: <CACQYfi+Z5afYmenU20wDnsZbV2r-LX7K07+y=CBDzHvjU9hSVg@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="00000000000018d7970584e75208"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GeONcpRIcKUj5hj6e5mzx5JotGs>
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:52:21 -0000

On Mon, 25 Mar 2019 at 09:15, 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.
>

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