Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon <> Mon, 20 August 2018 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EC86130E84 for <>; Mon, 20 Aug 2018 11:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Eky_q63_uOEi for <>; Mon, 20 Aug 2018 11:03:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 517A4130E4A for <>; Mon, 20 Aug 2018 11:03:57 -0700 (PDT)
Received: by with SMTP id h20-v6so589030itf.2 for <>; Mon, 20 Aug 2018 11:03:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CeDPLlHONkZI86UmWemZ/tSw2TC9fzDJ/Ug6rKccn+A=; b=kj+ZexyFIHmfW9eP3EL3Jv9pmk521TRb5khWnNSlatJLWg8DT5qmfeKJraiGR+huDH u6qpxs7uNSzWDSV7ITAl2JPdUblYKmHitIz28bD+fVDxPhX6MfXZcG2yN1wmQqcfA4Gi cv4mBdkuOhX2A1+E0V0z16OrzMqqcHbF1anh55VwvfdRkzgcC2FX+mBqqrpa9D6BLBEo OpMrgQ8l8tT5HE0GKzEL/KaAhbQZ81oP/3jQj5xgc4Y8LDIYMBFumJf2T/BwWR1oOaBq pQFbGwI+V8R5jNaITPMzW98eXL9dW4odWSoiQsYfWreoB8Vy+w0EV2SvOIgLNVr8Jm1k gKyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CeDPLlHONkZI86UmWemZ/tSw2TC9fzDJ/Ug6rKccn+A=; b=uML/RXNRlgtHhwYX11F7eQscAty/yChs9ndLxDcmCt/qnubX8yG7vIYR/wVNfG1HGw xmcGzjinu22PqpQGjpYwxwHadqiUwMASiSTPe4ti189EJtMQTPTJFKLETQ54RH0XUPZI yg2a4y27WzkeOo6myeqqfTduKAM2vEGfa29MN4CpJcFDIhkIyJvaSGF7mqjqUUpuQRWw yy5iAtp0/539e3ajxv8LhGyApKk/yfHHOw0kIyPujA8ycv8nZNgzxvAUOCIYm8/0UReF LydZpXV7/xhTZx4ocUdXKc/+unnBgEcAYp8y0mZwKpTyDXC+he1qfuB+DuEwwzz+HrGq NyxA==
X-Gm-Message-State: AOUpUlFesOBQ8UTm/BQmaM/x87jj2UDqSLiMBucT52R/HgfgoBbvzQs5 D1d6xrZqx19zA/6ry3RWVmoreHYdOMBPjVJpWRCQwQ==
X-Google-Smtp-Source: AA+uWPwgp14mS5MW8oGGW1y+2A7CZBKW4+OCUZP5z3lM+Qqh2Re0V8NqNFMeDXMR0i0YbgWVyVaN8Jp1gmhHDabZnQU=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr34596711itr.57.1534788236598; Mon, 20 Aug 2018 11:03:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 11:03:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 20 Aug 2018 14:03:15 -0400
Message-ID: <>
To: Paul Vixie <>
Cc: Joe Abley <>, dnsop WG <>
Content-Type: multipart/alternative; boundary="000000000000a607240573e1bb6b"
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Aug 2018 18:04:00 -0000

On Mon, Aug 20, 2018 at 1:53 PM, Paul Vixie <> wrote:
> Preventing user behavior tracking seems like a pretty valid use case.
> it would be, if it was cheap to block. that is, on my network, under my
> rules, user behavior tracking may be my policy. a user who wants to avoid
> that tracking should ask for non-tracking. if they won't ask, or if i say
> no, then the default should be non-functionality.

Well, the success of the HTTP Do Not Track header field certainly supports
your argument here...

> the DOH people are trying to ram something down the throats of network
> operators worldwide, and i'm gagging on it. a deep breath won't help.

this has nothing to do with what i use. for me it's about employees, family
> members, and visitors. for turkey and china and others, it's about national
> law. the ietf has not been knowingly and deliberately hostile to local
> network policy before now. this is a sea change. it will not end here, and
> it will escalate.

I think HTTPS was pretty hostile to local network policy.   Indeed, there
was a big argument about that in the TLS working group over the past few
IETFs.   If you don't want people to use DoH, there's an easy solution,
which you already need to use regardless: you have to MiTM their HTTTPS
traffic.   If you don't agree that you have to MiTM their HTTPS traffic to
achieve what you want, then I think we are not arguing about the same thing.