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

Marek Vavruša <> Sun, 19 August 2018 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0ED130F6A for <>; Sat, 18 Aug 2018 17:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XxvVMS1J5PDj for <>; Sat, 18 Aug 2018 17:53:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A51CB130F32 for <>; Sat, 18 Aug 2018 17:53:10 -0700 (PDT)
Received: by with SMTP id w76-v6so5713771ywg.4 for <>; Sat, 18 Aug 2018 17:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dkhGs4py9h64DXTjSXthrVPDuW3HDDu4wZWVv7ArKOk=; b=sfZzF/f3L8DJ5GzpbVlt4RSd/nFBeOIIFTcl7Y903Osa+luzS5P9YWGUhoBFiyAbK2 E2LFFIyC3Uqm4KiGes1zSRo2MFDU3JLJCh0T2t6FJ08XEJRugzpcWBgsOyghbhDOvpGN QRRzshk6FgZkZ+eaoiTJaMo81lQ454cCiiCs8=
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:content-transfer-encoding; bh=dkhGs4py9h64DXTjSXthrVPDuW3HDDu4wZWVv7ArKOk=; b=qztO5lQGe9o6bNOwB0kPhvzGbtDXKjZXOlgsxW4dv18RN1RM1cl2Y3oqDZlbnbfGU6 Aoz5i4+1JSrnzaYGIy5zc+RN+Y3s0+ZuCMIrugNN2TyV+nwzYE1W5n+cHTjIdNNh/UF0 t1AsjFyPawTCiKQBM24qVDeCBgalacaXDMc8pUM1iSDMhiFyB4rJijFm07HwRyi4G6hk 8zSS6tmwOvps7wbA3mxQOpL8fxwHGZgNmEABbxA626GWVO1KyH72xAvoTUJdqKALKJBy wkcxLQHPb8JU0PyWPg8N+hhwQN1z4gebGOfgocvi7ZpiNA5kO3Q9b4tl02k9IWIoEU6O kW2g==
X-Gm-Message-State: AOUpUlFPqD0CZHzZleLVWLKmByOn0lgsvFTrxgrKAS9jYpnkSd7TiJmn SB2Y33J+d45mEq2X9eqdp0AYL9CP+uPmFPjajWG6dg==
X-Google-Smtp-Source: AA+uWPxVickMPkp2kEvktNDMy7mt7sALX1MF3QuQxxnWvlA5Oh3QjTqFsTPqXsmfNChaHcuLt55Y7ItV047jQ9scUlQ=
X-Received: by 2002:a81:5009:: with SMTP id e9-v6mr23051703ywb.128.1534639989934; Sat, 18 Aug 2018 17:53:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:53:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Marek Vavruša <>
Date: Sat, 18 Aug 2018 17:53:09 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:53:13 -0000

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <> wrote:
> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <>
> wrote:
>> > 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.

Can you share the link for the draft for a reference?