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

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 23:46 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D85130E09 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 16:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6mIWgyOtDWr for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 16:46:36 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38F5130E07 for <dnsop@ietf.org>; Sun, 19 Aug 2018 16:46:36 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id 72-v6so18279786itw.3 for <dnsop@ietf.org>; Sun, 19 Aug 2018 16:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0iV/+X0ARYLnd1hwH/fzcCH8NTvSyD/zRPJifIT6iGI=; b=yIEZE9J4D3GnqhV0gutVHid3f90eB6ycpFs0WpIFfdb1wad7TsFKXezIzBWl4SxQYH W8Ghtli6tmDlaNdgHB7+53H93OBMVbcykPyeaQtgjA/FaV8OO56PPsBdQMAQGlZL6/1o qZ3+pu6BoY6BpVePgAHKyrTZv5K2rtrn35FMdbJLAvuJJvQVz6vEdbtpv4im/1xTHAJs OpOiqkgQQ5YsT9Apim6HDhMd9Q4i0V1E5CQ/jmUsnPxb/nR6e1kIiN8YxrjJIg+edRIh V2puPyrg/sOsV81D8mADTxxPSvK66uEmJVTLp/y7X/LsElVfXMmcDVVu2w52mo4fsrw3 L0lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0iV/+X0ARYLnd1hwH/fzcCH8NTvSyD/zRPJifIT6iGI=; b=K6uScy0gR+5MCDKxO83yzQWAyGf8JV8OjiBuO2t3+QACbsKBIt9HY3UzA33qr+cG+t CQwQv777WCTYBqy1MApA/0z7m2gfViPlLxHpzNB5AwV/XbqJCjKyj3mxKuWtkV298vH5 //Uod1rG9Iy6uFME9HQD3X94Y2/KneDvY+BPrPI3dnvgqeOjfnSxmp78ewHyzEzfPeZn YmByYJm6mDMufTyB5rhIrR4+HJC+jwqIs+cho+ajZYDV7/DBvXbVFxNBhIuqsH5wnEgD jKbLdL4aOYuuAjcqRXESOUJA8MI6pY1inl0sCM/T0VfiCfEMspHJZSYbAfuqYLh9DEKM Nj+Q==
X-Gm-Message-State: AOUpUlGu7sDC8aAKSVW8GlYbL3L3ma4ef//jj3u89asDDrMgLcyvmdIg Qe7odtK5poS7/5+Xs81W7J5f2VUOCJ8IQFe/PRZi5E94
X-Google-Smtp-Source: AA+uWPwz0OV5b+/r2QrBqKD0FUbIni1hDzMgToV2IKvqWo6a5WnOFm1hTMtArQGC2ENkb1EdkGHSrLqHGN576VSPisM=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr31852144itr.57.1534722395678; Sun, 19 Aug 2018 16:46:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAPt1N1nEH86yPvtoNqJ+xM-OFunEqr2x8s2LV_yFU1fkVt9WUQ@mail.gmail.com> <53074d98-a8ef-9127-edc7-d3e3188c2453@dougbarton.us> <CAPt1N1muo07jvDmyM+oL96Ow1RXGcsgVKX51S86CUcedirzvew@mail.gmail.com> <20180819.204841.532639858.sthaug@nethelp.no> <CAPt1N1nFW_h1i9cetKXm1isp9aUDKH73ZB+3trabFZd9NSDZkw@mail.gmail.com> <40510317-dadc-7d93-543a-7da71fafd288@dougbarton.us>
In-Reply-To: <40510317-dadc-7d93-543a-7da71fafd288@dougbarton.us>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 19 Aug 2018 19:46:23 -0400
Message-ID: <CAPt1N1kHHKwKiKsncK7QjHNPsCs5mCOzp_=1LO=Ci3HfQ9dw7Q@mail.gmail.com>
To: Doug Barton <dougb@dougbarton.us>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003945830573d26736"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fqo4MGKmlHFUmNuNT-Pm0JlgBII>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2018 23:46:39 -0000

A user who relies on the dhcp server for dns server info is no worse off.
The problem is that if your host lets the dhcp server override the DoT or
DoH configuration you entered manually, you are a lot worse off. So you
have to specify how you’re going to handle this. I’m not saying don’t do
it. I’m saying figure out how to specify it so that either that is the only
use case, or the other is the only use case, or the implementor knows how
to make the right thing happen for both cases. Don’t just pretend there’s
no conflict.

On Sun, Aug 19, 2018 at 6:07 PM Doug Barton <dougb@dougbarton.us> wrote:

> I agree with Steinar's sensibilities on this, FWIW.
>
> Ted, you've restated your thesis several times now, but what I haven't
> seen is an answer to my question, so let me pose it a different way.
>
> How is a user that relies on the DHCP server's DOH or DOT resolving name
> server instructions worse off than one who relies on the DHCP server's
> ordinary resolving name server instruction?
>
> Also, we're not talking about introducing a new service here, we're
> talking about a configuration detail for a service that not only already
> exists, but is critical to get any real work done once you're on the
> network.
>
> Doug
>
> On 08/19/2018 12:28 PM, Ted Lemon wrote:
> > I am indeed saying that when the IETF publishes a standards track
> > document with an applicability statement, the IETF is recommending that,
> > where applicable, the specification be used.
> >
> > The problem with not deciding on the trust model is that it would be
> > impossible to write a clear applicability statement, and hence the
> > protocol would be implicitly applicable in all cases.   When you are
> > designing a protocol with very serious and significant trust
> > implications, this is a really bad idea.
> >
> > Think about DHCP providing an SMTP server address.   Does that make
> > sense?   What is the trust model?   The IETF does indeed recommend this
> > for IPv4, but we didn't do it for IPv6 because we'd realized by the time
> > we did RFC 3315 that not every single thing you can in principle
> > configure with DHCP should be configured with DHCP.
> >
> >
> > On Sun, Aug 19, 2018 at 2:48 PM, <sthaug@nethelp.no
> > <mailto:sthaug@nethelp.no>> wrote:
> >
> >     > The DHCP solution is compatible only with trust relationship two.
>  So if
> >     > the IETF were to recommend this way of configuring DoH and DoT, we
> would
> >     > essentially be throwing away the privacy benefits of DoH and DoT
> (assuming
> >     > that such benefits exist).
> >
> >     I don't believe people are saying that the IETF should *recommend*
> >     this way of configuring DoH and DoT - they're saying the DHCP option
> >     should be *available*.
> >
> >     Are you saying that all DHCP options introduced so far have been the
> >     IETF recommended way of configuring things?
> >
> >     Are you saying that no new DHCP option can be made available unless
> >     the IETF recommends this way of configuring things?
> >
> >     Both of these sound equally unreasonable/unlikely to me...
> >
> >     Steinar Haug, AS2116
> >
> >
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>