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

Ted Lemon <> Sun, 19 August 2018 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FB11130F70 for <>; Sat, 18 Aug 2018 17:48:44 -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 fRyWfHg-4Dzs for <>; Sat, 18 Aug 2018 17:48:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41BD5130F6A for <>; Sat, 18 Aug 2018 17:48:41 -0700 (PDT)
Received: by with SMTP id p81-v6so16322585itp.1 for <>; Sat, 18 Aug 2018 17:48:41 -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=ZEcEM4iVqvxUVN+Sq2b9OT90fhg6q7qbnEyWOrJqshQ=; b=aesC5u/PqIonlcklq9hfzqN447YIP1R8QFnQx1fZr6ROdPzadiWRUBfcKiC0fae0W5 Qm1yicRrPA7o48N3CdWgZGJCLgq2t47a1YW2oZwxx7imXEImVB4sjrDSAeCko285c/kv NlYtfG1BsCbXWBbtPfZMbe5WpttwHILmqoEOFu9D1BpX34rNDusHyDyUYY1Y9fU060Xr PUxvQu16UV+fgIe632+5JYlZckmuc/WcsKTeKtS89IRhmdU7kX9xxhIM/C7DggCsKFVK L/+lC/dLOuDRixAg4elkDLB/krzoz1h0MRljr3u+x/xq+nY/kOip5kGnSGLqFdxDUKGQ 55Qw==
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=ZEcEM4iVqvxUVN+Sq2b9OT90fhg6q7qbnEyWOrJqshQ=; b=V7iTDau0Llxu1rlGO77Lbr+6MMEl4IdF4Zl5JR1P79UTPdfRR2HAT9leaejtiwBe/t YfQpyQfoO1z9UcaC8NPSl9ebI3mafuOFFNjB3wE1NQ1yiMOnp0ZR4H1xva413LilFa5f FRA6S0ZvLBOWlIVG8BqtpdthpGzkDEaQOA7437HhuLOSqI9w0ABxzagnzfVV+DJl47Yu 6byc8n39g/+gz6BJfj9vmUoNEC49Ejgbp5c4AvKmy7RzOg5BnF2MM+AUVAbTX6GzLmU2 rD0tn2CikWxm2oHG6NvNV/DEaJkIAwjq7Y7jQ/GzzdecqUigheGLz8N+gA/WDI5Mpt7i WsXw==
X-Gm-Message-State: AOUpUlEhwA+jCVb8JYcz9mwZ6mVFoH6OQAFIkOma5Ff4JfLj4Ng2snMl GD+iCbubMQaJAUF9GuGzxo7nvKeoMVkVzYY7kOL9IQ==
X-Google-Smtp-Source: AA+uWPzqnL6v/tbceCdtjYNrSf78/RsAMxZQ1id+jXTV8R2LZjSC+40VJ3AkXtZ4cxCdn3F0tyV7wl1M+dyHWg6L4QE=
X-Received: by 2002:a02:b70b:: with SMTP id g11-v6mr36622165jam.34.1534639720535; Sat, 18 Aug 2018 17:48:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:48:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 20:48:00 -0400
Message-ID: <>
To: Marek Vavruša <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="00000000000066bb6e0573bf27a3"
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 00:48:44 -0000

On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <>

> > You say that your proposal does not impact DoT's ability to address the
> > threat model or use case that is the reason it is being used.   But this
> is
> > doesn't make sense to me.   The trust model for DoT and DoH right now is
> > that they are configured by the user for the user's reasons, or by the
> > service provider for the service provider's reasons.   You are proposing
> This is the issue that the draft is trying to solve. The service
> provider doesn't have a way
> to configure DoT on the stub resolver. This problem is described in
> What I'm trying to address more specifically is

 The document explicitly says that it doesn't have a trust model for DHCP.

> The "DHCP authentication" does exist, I believe you're referring the
> deployment status.

No, I'm referring to it doesn't exist.   There is no deployable DHCP
authentication.   The DHC working group tried to come up with one, and
ultimately concluded that it was not worth it, because the only thing that
should ever be trusted from a DHCP server is information about the local
network.   DoH and DoT are out of scope for DHCP according to this
reasoning.   Bear in mind that we were more optimistic about authentication
when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
RFC3315, is not as optimistic, and only provides for authentication using
IPsec between server and relay, and authentication for the purpose of doing
Reconfigure; this authentication is not sufficient to provide assurances of
trustworthiness.   It's about as secure as a TCP sequence number.

> I'm happy if we say the draft must depend on RFC3315, or discuss the
> trustworthiness of the responses,
> but surely there must be a way forward if we want to keep the
> recursive DNS (last mile) decentralized and free from tampering.

There is a way forward: seriously figure out the threat model.   Tom
Pusateri and another author already did a DHCP document; the reason we
didn't advance it is that we weren't able to come up with a threat model
where configuring DoT or DoH made sense.   Until someone does that, there
is no point in doing further work on a DHCP option.   If we do do further
work on a DHCP option, Tom's document is more complete than yours.