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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 25 March 2019 08:15 UTC

Return-Path: <brian.peter.dickson@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 7483D120365; Mon, 25 Mar 2019 01:15:03 -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 veLOkNFIu_fs; Mon, 25 Mar 2019 01:15:02 -0700 (PDT)
Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 08256120368; Mon, 25 Mar 2019 01:15:02 -0700 (PDT)
Received: by mail-qk1-x744.google.com with SMTP id w20so4753521qka.7; Mon, 25 Mar 2019 01:15:01 -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=fSYb+edvJcgmgtcaDcDWxsHZTfMTt+/G+ZtMsKLzXxQ=; b=JSkPdWgpJYaWLzCE4o0H3Vy3hojqJ9FltcJrlLPHuZOsUqAmvMXtYW8OWJ4f+9aQmN DIwSAPxVyweOaHD9rTCTXUZJecbuhh3asuOkR+0S7xyEoGqEbqh0YQbkGCjJWENTzlwP kJY/uggskV/BZXyhBpGoai67Bp7/9gu2g7877V83NpwpMWguHlqjle2Zq1pbTqCGL8E1 lUOk6AB6Gfb5Uca9r08mpkr1rHkpNwVuzdnBf382H0P+cEnkLnjRSn7x6ZPBmrMzlAyr w4WR4IYXws2B5YKg8ko2IlkKQl590dD80ODENb4S2C9zd2llNoLkyYVm9CPsX0p8uvok vs6g==
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=fSYb+edvJcgmgtcaDcDWxsHZTfMTt+/G+ZtMsKLzXxQ=; b=mowLAaFhSkYzFZwyHmLpTzzGtAZzACh4cfTMBOiOfaFYFW4kKEAi8n90Dfm6rZRDjK LQkkrCOlkR/c+xx8k3dnYFgt3Ntvb4ZAhnqUylcN4DRw2+8xxqTjnprZfkVMszhmpMOe d4weHZgBqt9ODcoD5GbbDm0+XWdSSMIuv5NcagP689CeciRNW8vTZ6FdhBSp4tJ5J71G 9LOGsuh4S7X21Y/yQvW/gqet8iquDNilwGs8YQq/5JAMCvBGNkKBGURY0UFlsnZn+yKY +Fo2/nV8bmLTwiRh5BKN5nlgPMEjCv6lOMTnQBrF67VVc+pKFPkpHaR38zldXFzs9/YG EDdg==
X-Gm-Message-State: APjAAAVc76he4DfNrZsn67WCdQ7FliGiA/Fhp+X+nClxqJKBddua6b50 4fnQw5letjdyxevUpGt1IDViEu2C7wAV5nxXh9A=
X-Google-Smtp-Source: APXvYqz6rmoyMIhy5Bnc9Qa6SS4ta9SXn8B8l7MXyhKq4jjMvf8whPOt3VNYlf26BxgiXLzLx1GImtcLFAiHqmu/4X4=
X-Received: by 2002:a37:2c82:: with SMTP id s124mr12376539qkh.286.1553501701202; Mon, 25 Mar 2019 01:15:01 -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>
In-Reply-To: <CAOdDvNqKja9SRWa7FpjnGR3XZbVwZbitoU0yuWc+oXw3xXFEQA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 25 Mar 2019 09:14:44 +0100
Message-ID: <CAH1iCiq-XaeTN_O7rDkKQy6OQaqqyMb=dFoQ-gAEjTMOsVbcBQ@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: "Winfield, Alister" <Alister.Winfield=40sky.uk@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>, "doh@ietf.org" <doh@ietf.org>, "wjhns1@hardakers.net" <wjhns1@hardakers.net>, "dnsop@ietf.org" <dnsop@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="0000000000000ee5b20584e6cd51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KsWVvs1EuiuY3rUPUg1BxRV7ZPI>
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:15:04 -0000

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