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

Joe Abley <jabley@hopcount.ca> Wed, 20 March 2019 11:38 UTC

Return-Path: <jabley@hopcount.ca>
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 3D0A612423B for <dnsop@ietfa.amsl.com>; Wed, 20 Mar 2019 04:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 HuMyCr3XlYa8 for <dnsop@ietfa.amsl.com>; Wed, 20 Mar 2019 04:38:19 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 F0F5B130ED9 for <dnsop@ietf.org>; Wed, 20 Mar 2019 04:38:18 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id j9so2365775wrn.6 for <dnsop@ietf.org>; Wed, 20 Mar 2019 04:38:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nroxriPw49FcN0DkaybBkMS8nLs5CD+/YXuXi6CAwnU=; b=DQfZ5kojv2TlCeexOrnYjUKfMw3ErvME17EYJlTtZIsQrMYklGZLAAXBCkIS+pFzh2 D/uINPPQrY3NitdxWHpAFLSxTow5e0Q6fXduVSildBocOsgbmYiLrnTmiL6W1aPlUlCH JG4yTRlvg5hKavMtyrTutxXsYb4w9QIQwT8WQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nroxriPw49FcN0DkaybBkMS8nLs5CD+/YXuXi6CAwnU=; b=apYXDWQH3Gt1U4yn3vplhQWcmpInn7Js9K357suBMebJww09z3WglcUrrEJk7p7rik qfsgodTAYxKMnDgR350vupcv+AsHSm2dlFS2KL77WSvW+z2hsN+BcgBj3Q1fmYsTegua yaMmOc6c1OM5NNmGOiPp2RTvan7xkr8HyBkHApf5Hge30e9gVcYKf+glsNp3l8STl3px b7JUSf3S3ebt/bf+uXmMhg6wpmXtnNdgKbUZPwHylcdZ+MjCSQwwkMrhrqQQYQM/fa78 Ljn2+OfSu9wG1Cq9Qy+wbPlABxRjjZhBEo2pYpIHoEuY0ZzzGmcs95+42uPPVPDfd3A5 i4Tw==
X-Gm-Message-State: APjAAAWRRtb4gCCv3s0eRFDxL/kREFRW2cbb+BawTHeDeRev0euXnG0S FlNeXrWLshUuaeSO0PFUTXJLgw==
X-Google-Smtp-Source: APXvYqxnDg6CWZc681MvMGChkwu6noTRxxU7fHOsdD57x3f0BMrYd+2fBWk/SyANzqdzn+mmr0Bw2Q==
X-Received: by 2002:a5d:4a8a:: with SMTP id o10mr21576206wrq.189.1553081897379; Wed, 20 Mar 2019 04:38:17 -0700 (PDT)
Received: from [192.168.122.171] ([41.216.172.202]) by smtp.gmail.com with ESMTPSA id s4sm1552800wmc.34.2019.03.20.04.38.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Mar 2019 04:38:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net>
Date: Wed, 20 Mar 2019 12:38:05 +0100
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, dnsop <dnsop@ietf.org>, paul vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Transfer-Encoding: quoted-printable
Message-Id: <91A0BBD0-CB73-498E-B4E0-57C7E5ABE0B4@hopcount.ca>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net> <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net> <b8c58757-3945-ea19-b018-8e59292abf30@cs.tcd.ie> <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com> <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net>
To: Jared Mauch <jared@puck.nether.net>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sBnJDZO-_tmAzIZp53Xy643L9M8>
Subject: Re: [DNSOP] [Doh] 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: Wed, 20 Mar 2019 11:38:21 -0000

[There is actually a proposal at the bottom of this e-mail. Bear with me.]

On 20 Mar 2019, at 11:09, Jared Mauch <jared@puck.nether.net>; wrote:

> Often as an industry we may discuss various solutions that are great for oneself but don’t scale when looking at the big picture.

I think what we are seeing is the fundamental tension between privacy and control. You need to give up some privacy in order to make the control possible; you need to give up some control in order to afford privacy.

Some in this thread want certainty that they are able to exercise control, e.g. for devices in their network.

Some in this thread want certainty that they can obtain privacy, e.g. for for their device in any network.

When those people meet, the pitchforks come out. This is already true today; it's not a new DoH problem. I think the balance of the tensions has shifted with the prospect of a change in default behaviour, not because any of this is fundamentally new. The change in defaults tips the power balance (e.g. the balance of cost) between control and privacy. This is Paul's basic point, I think.

Some people seem to be getting worked up about whether the desire for control is more important than the desire for privacy. I don't think that question has an answer, but I think most reasonable people could acknowledge that both positions exist. This is Stephen's basic point, I think.

It's possible today to communicate over covert channels in order to avoid control. This is different from *all* communication happening over covert channels so that no control in the future is possible. That's not how things happen today; that would be a change, a new situation. This is your basic point, I think (that's how I read "scale" in your e-mail, above).

Seems to me that there's a middle ground within sight here.

Standardise this privacy mechanism, and specify (with reasoning) that it should be implemented such that the existence of the channel (but not the content) can be identified as distinct from other traffic by third parties. Maybe specify use of a different port number, as was done with DoT.

Those who choose to ignore that direction and create a covert channel using port 443 instead will do so. Nothing much we can do to stop that today (I guarantee it is already happening). The future is not really different.

Of course when people shift the focus of the conversation from DoH in general to resolverless DNS, and want to interleave DNS messages with HTML and cat GIFs over the same HTTPS bundles, the pitchforks will need to come out again. So keep them handy.


Joe