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

Marek Vavruša <> Tue, 21 August 2018 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAC34130E88 for <>; Mon, 20 Aug 2018 19:47:57 -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 lqw5T2W9BmcN for <>; Mon, 20 Aug 2018 19:47:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68213130ED9 for <>; Mon, 20 Aug 2018 19:47:55 -0700 (PDT)
Received: by with SMTP id c1-v6so3774492ybq.5 for <>; Mon, 20 Aug 2018 19:47:55 -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; bh=8OZFD41pA7bj6B8XTi3i9yCXdhd5s7qzZHmlbzWFHzU=; b=toebfB4yIr8gJO2b5Hk2qWkkUe4K+RuAoc+tqD+Ugi4Y/3/HJTYoKyGO8hsnpEucmv QyB1944zmEzfHp68NOB8JpmE86TervqDFbIguiOv8GmSthedtK+vWwrCy/R3KC4P3U19 w917Vz5dIB7AZO7h/hV+6vI+L2AjWoQOTpEqc=
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=8OZFD41pA7bj6B8XTi3i9yCXdhd5s7qzZHmlbzWFHzU=; b=micR/uCmx+ukZu6EU7YUxK+AoSQuBv9YEcXbe/E3aj4YLD4bf+4+Fn/rfd/2S3mpYT eSvTIbK1JoWUE/WJaDcWh7orCMtmjPkZieBzGbB8l1x3MCZU1U2vJ3NwtO5Kr3PjIf06 1uIjjh7zMqmxcGMt39XMV/4o9lS3/EcgW+TbsBRwG8mxlKbQ73GRWxS6ytVu5hwAQGC1 mrpKHNaB1sh9BSgzogi8iNTj4Q21poLEh3E1IPemkwhHDA0l91wX2uT4nyD07yQTBYWL nIUmnW4UFLHf9h0PnOVOvGrOMizrqK8okbn7EJZNkW/P7H6ngobvGCmh8Vx/rT2FybBl /dmg==
X-Gm-Message-State: AOUpUlFwvjKCVoztm1V6MFDxe7b+xT2d527sXx6WFiC3k5OjyQI6RL8X db+zYvpcqoS3bgRmMzvYs5xKmplwrWwxeQTHhniGTw==
X-Google-Smtp-Source: AA+uWPzmkFsv8+kizRbHZMSxQJuZZA+N3cqn2DN2VeOnznsPNQrCEX+Kn5CGhj7OPqRRKJpN0JxHDmzVjNmxlaLBZUo=
X-Received: by 2002:a25:9a49:: with SMTP id r9-v6mr5952109ybo.163.1534819674455; Mon, 20 Aug 2018 19:47:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:a045:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 19:47:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Marek Vavruša <>
Date: Mon, 20 Aug 2018 19:47:53 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: Paul Ebersman <>, dnsop <>, Tom Pusateri <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 21 Aug 2018 02:48:08 -0000

On Mon, Aug 20, 2018 at 7:31 PM, Ted Lemon <> wrote:
> This is why we need to actually think about trust and not just handwave.
> There are a number of serious misconceptions in what you've said, Paul.

I'm still not sure that IETF should define the provider of trust, as
the trust is relative.
But you're right Ted, it should definitely be at written down and formalized
if we want to move forward.

I have to compose my thoughts on this first. I'll try next weekend if I get
some of that bravery or willpower back.

> DHCP _is_ worse than TOFU, because there is an opportunity for attack at
> every lease renewal, not just the first time you ever talk to a particular
> DHCP server.   I actually proposed a protocol that would have worked nicely
> for TOFU, but it didn't get consensus, so we don't even have TOFU-level
> authenticity.
> The rest of what you said is nice, but "we have to balance theoretical risk
> versus sane and widespread deployment" is a statement that sounds a lot
> better if we do the math.   If we just decide to do something without doing
> the math, then we aren't really balancing anything.   We're just deciding
> not to do our homework, because math is hard.
> On Mon, Aug 20, 2018 at 10:26 PM, Paul Ebersman <>
> wrote:
>> ebersman> That may be the consensus at the IETF but it's not even close
>> ebersman> the consensus with ISPs, nor large enterprise. That seems to
>> ebersman> cover most of the eyeball/consumer... DHCP is still how much
>> ebersman> of the world gets connected and that hasn't changed in decades.
>> pusateri> You're misquoting me and arguing against a point I didn't
>> pusateri> make. There was no one saying we don't need DHCP. There was a
>> pusateri> general agreement that DHCP should not be extended.
>> pusateri> The DHC working group never completed the work for DHCP
>> pusateri> authentication. It's not trustworthy enough in its current
>> pusateri> form to add more things to it.
>> And I'd argue that this is also an IETF opinion, not the majority of the
>> internet. There's a reason it's still the most widespread configuration
>> management for devices. "Not trustworthy enough to extend" is a fine
>> academic opinion but doesn't hold water in the marketplace.
>> DHCP is no worse currently than TOFU. We trust that the OFFER packet
>> will be from the DHCP server we're supposed to use. Trust On First
>> Use. Not great but it works more than not. At least that's the argument
>> I kept hearing for TOFU. We actually have operational experience of
>> decades for DHCP and this isn't a wide spread enough problem to kill any
>> innovation forever because it's not perfect.
>> If we want the world to use what the IETF develops, we have to be able
>> to balance theoretical risk vs sane and widespread deployment.
>> If not, someone will just wind up shoving this into yet another DHCP
>> vendor option and every vendor will be different. That will be even less
>> secure.
>> _______________________________________________
>> DNSOP mailing list
> _______________________________________________
> DNSOP mailing list