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

Ted Lemon <> Sun, 19 August 2018 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40EF0130DD1 for <>; Sat, 18 Aug 2018 18:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 lzOMfjjPTtAl for <>; Sat, 18 Aug 2018 18:38:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD0D6130DCF for <>; Sat, 18 Aug 2018 18:38:04 -0700 (PDT)
Received: by with SMTP id 72-v6so16245112itw.3 for <>; Sat, 18 Aug 2018 18:38:04 -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=K4o8u3CrUKpWXzkzCLixPwD3uTBBqi8pUd0rVlqj548=; b=PYfzanWjyeyc7Wp4M8Runbv9jhLEJCXKOqe2RWOK+bKPvBrhxYplfW1eOsx0qkpyQE VJdy771+zeizmy9Ja1sZSFSYYeDZ13x5z178fIu/zPZ3dUl6L9WhlVSn4I3xA9jfO9Wz H7eEIOZzZauAaAhjmtXBzIeUmOmJUAOrBlH0EGsavOUmerc14sL1gX7bff2Hu8B/1XGe jXOebusU+ZsJ6eHVdH9vAnMn0zG5ps628OHWOKixKiWGYxdnqzZvPKu4h8+zW3jKaWKQ LuFR9ufntZl/2J8r4Gs8HLFhfj5S0geSXO64U6Swy8uowuYCBKS09Vg92SfMTKMwzSyM RblQ==
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=K4o8u3CrUKpWXzkzCLixPwD3uTBBqi8pUd0rVlqj548=; b=L8ZaswVfzQ2S2utP4V8utfP3QYW1VIvzwtE5zDgl4MfXdVJFfooSmFoe5jfMMhGP3B iBmynaXoaxuzQw+tgDwB8RREMXG6ovK9N+cCYa1EHBIhpYhUiIH4VrzBT0pcuEzAp73B BLMUve0mWAkFiGXkfI4wC5t+ViAPPyFL3qDKdLDYMydiRO+rC6EMtQj1cVd4rtFsFbwF 6lm+8qDBZFdK64MOTnyCrPF93ObOzSyVwxazOWfT4HbYk4xIJR94b5SEwkkVf9EOOEq+ HtOcdFz4gplXF7ajM3d8nTzm6+4ddFAABZQSCZjEcTh1WJd3BfRrinNAdYnwtS5xQQAr WJ0w==
X-Gm-Message-State: AOUpUlEokm18eVphTxsjgcVyAC3xKzCLaDiMkqyopq12YREQ60qvZf4F bvu61hEAlxGXy7TLeEvwCrxI51DN9zsMLmczsfaptw==
X-Google-Smtp-Source: AA+uWPwdp+9Ksrd5eUS/Zsa0Uo17vTMHQPoqtbuuknQCqEpw3RBFfnO8tGrarCEy45QshQfC0yFUuZtBx70a2NFZgRI=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr29397300itr.57.1534642683887; Sat, 18 Aug 2018 18:38:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 18:37:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 21:37:23 -0400
Message-ID: <>
To: Paul Vixie <>
Cc: Marek Vavruša <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000007dd760573bfd8d9"
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: Sun, 19 Aug 2018 01:38:07 -0000

On Sat, Aug 18, 2018 at 9:21 PM, Paul Vixie <> wrote:
> Ted Lemon wrote:
>> The thing is that most devices don't connect to just one network.   So
>> while your devices on your network can certainly trust port 853 on your
>> network, when they roam to other networks, they have no reason to trust
>> it.
> that's far afield of my stated use-case.
> if i receive advice and pre-shared key, concerning tcp/853, from my dhcp
> server, the tcp/853 service i'm advised to use may not be on my own
> network, it could be part of my corporate VPN, or an anycasted commercial
> service, or almost anywhere else.
> in that case, my DHCP transaction was local, and my resulting TCP/853
> transactions won't be local. and in that case i will have a greater reason
> to trust the pre-shared key and the TCP/853 advice because of where i
> received it, than i would have reason to trust privacy or integrity of the
> path to a UDP/53 + TCP/53 ("traditional DNS") server.
> roaming is another matter, because in those cases, i'll speak DHCP to some
> new network provider, and will receive some advice concerning an RDNS
> service from that new DHCP transaction, which will obviate any previous
> advice, or whether i took that advice, or how trustworthy that advice
> turned out to be.

If you are trusting a "pre-shared key," why not just pre-share the DoT
server information?   If you are using the pre-shared key as a way to
validate a server whose IP address may change over time, why not configure
the pre-shared key with a domain name?

... If you have devices that never roam to other networks, that's
>> fine, but we have to design for the more general case.   There's no way
>> with DHCP for the device to tell that it's connected to a particular
>> network, other than matching IP addresses, which isn't a great idea.
> if i'm not roaming, i won't receive RDNS advice from the other DHCP
> servers that i never come into contact with. this seems a non-sequitur.
> if i am roaming, then anyone who hands me an address via DHCP should feel
> free to advise me as to what DNS service i use, including a TCP/853 service
> for which a pre-shared key may be needed. because the network operator may
> forbid and prevent the use of other DNS services which i may prefer, it
> would be wise for me to listen to that advice, and consider following it,
> especially if my usual service can't be reached while operating on said
> network.
> roaming is off-topic. DHCP authentication and integrity is off-topic. this
> is a simple proposal to allow a network operator to include TCP/853 ("DoT")
> advice including pre-shared keys in their DHCP responses. it ought to be
> drama-free.

The reason it's not drama-free is because you can't just hand-wave the
threat model.   What you just said is a fine way for you, Paul Vixie, a
knowledgeable user, to configure your device, but I can't explain this
threat model to a typical end user, and they have no basis for deciding
what they should do.   You mention the GFWoC, and that's certainly a use
case we need to consider, but we also need to consider the use case of the
malicious coffee shop network that wants to harvest your passwords.   I
don't know if you have friends who've been taken by this scam, but I have,
and it cost them a *lot.*   So how does my host tell the GFWoC from the
malicious coffee shop server?   Assume that it can't ask me to figure it
out—it has to follow some decision heuristic that is programmed in at the