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

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 19:29 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 5EBE5130E9D for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 12:29:13 -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 sdw_s5X400DX for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 12:29:11 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 75C37130DEE for <dnsop@ietf.org>; Sun, 19 Aug 2018 12:29:11 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id d10-v6so17804164itj.5 for <dnsop@ietf.org>; Sun, 19 Aug 2018 12:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rgQGq09rFYRsXoIWTr5uaglHPj4H2Mpd5AyR6n9yZ7Y=; b=hMAxebsR1xbymhbcoqkub9TEv0BNG1WD7BRgXir4ZSdQZ8A7Ofx1NNPkWfQjXWE9yF j9ZojScIr6MgAW6liebrpGMlF7I8Y3IGA3DNTt0pe0ym6euRtoUSSJumk0anCPe7Ew2J +uDlT8N3/wig7RvIZe6Etk7FaPtMJ0/T9hSLcELIyNOXAcNbTXMRuL7BWc3GwNFObdsU m7pRweaW5KsjqJWAEHy1T1iYmTIsAocLh0up0bFSUNbGr7UQ5ZBz3tzFLaHol92B05fD 9AGhb2y/5pf0aycQ3Qf3NYmRze1DgGd2/GogRAHYdR69lvQyWjGcYqh7a/d2OL9xTRfE D13g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rgQGq09rFYRsXoIWTr5uaglHPj4H2Mpd5AyR6n9yZ7Y=; b=ew7HSwR032r64Yz6Ti/og8p3Wh8iaihVRT002ZQkTRiJ1UYJ1EEzbFd9put13Amag1 ibxrZChpaRDk+npNAEN5yqls7bFoVAP90b/nFLI6Ghsz0DlxcIax8e1vc84vWxopZf2r lnKGNMoM/VDNl5/FQYx5yPA0JsSRhersn9dmusghQQVArOcbkJYx94rO81qz8dDz2lRq njVaYPWan1lPknS0ySmIG2/P8AfRMnFEBr2DUu1h/YbxJ7snSTG1/HcBYt1elU71rvLw dZHiG/wsjlvWZcYJRuIg9Q0iNpsWHt9YvaCI0k4sSXSBPnTeNL9ryXSlsvmjyFwQiORI ojDA==
X-Gm-Message-State: AOUpUlFLi66CMXaNn3j+2o3KRjjQYFqsBVCUYbET4ZRJqcnVpTMhffDw 3a0QI+V7bV0HaXLYh2o9nVehZSZWwIreAhuo/tOJ3xHg
X-Google-Smtp-Source: AA+uWPxckpeUuws5eUTEwdQrdZ4ON9FuTbOLHN+kia1Gp7fl6jpcHJ50fWYmePa0hXJN4z3bChilnjnoR/1zhO8j+Vs=
X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr36707786jad.38.1534706950661; Sun, 19 Aug 2018 12:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 12:28:30 -0700 (PDT)
In-Reply-To: <20180819.204841.532639858.sthaug@nethelp.no>
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>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 19 Aug 2018 15:28:30 -0400
Message-ID: <CAPt1N1nFW_h1i9cetKXm1isp9aUDKH73ZB+3trabFZd9NSDZkw@mail.gmail.com>
To: "<sthaug@nethelp.no>" <sthaug@nethelp.no>
Cc: Doug Barton <dougb@dougbarton.us>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0fdd50573cece25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XmMW-bknw_3xtMUfrk3VSAnZuNM>
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 19:29:13 -0000

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> 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
>