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

Ted Lemon <mellon@fugue.com> Wed, 22 August 2018 18:35 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 2A5AA130E17 for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 11:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] 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 emWjTQelpqNC for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 11:35:42 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 95275128B14 for <dnsop@ietf.org>; Wed, 22 Aug 2018 11:35:42 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id y12-v6so2204979ioj.13 for <dnsop@ietf.org>; Wed, 22 Aug 2018 11:35:42 -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=Uws2QBpOgXrStnQ7zEvvdcvKFo1oGGCcvs/EazQ3z5w=; b=BBpTmTCHJfOGw+hMq/2X774UB1oVYUwqO5RYmXRQRJj9DknLy+LX9eZrXBHEec5dEt xFF3FtWOr9XrZ9zRAAJAWs8E4gJQM+JpSk40PA4r4zcicexR1y9cun68u8Q/6r2S+waY tEMXO3kzT5Lltk90bbqsxMPTmi0Tl0Vm2rvKWxT8+It2E0pMY2hz4f81fg3aFkKK0rQL pkWCKJZKaNJMHkE5BZKYTSD6sUoLEK0k7fBnZDVyWzQ72ek8KKtvo1nh0uAFgeBKxSnz QqtV4L7NTqjons6wQl3DIFQXlzZWkkiz6FdGNAP6mU6qYgj0Atrpr+mjDabsisyg6FA4 fw9Q==
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=Uws2QBpOgXrStnQ7zEvvdcvKFo1oGGCcvs/EazQ3z5w=; b=Y6JBp7ZvJ0nx6mkq30ey3TC8fywLQPwj8pwxIx4eYeucBJROKYkxZvjoXEsznQryXr Yx4L6cVAMLonVBQD6V/PjX9JA3QVUqBB+BZQ+GI9SJvYb4VuKeuGAp6ngp2AevRjuGvo xNqnb54OtIIzLze4SiYgrhofXxnxX1yjU6Ow12mWPb4h6pfa4sluLKRhMkooc/fwMei8 +EPYsCjyz9axCdGUh1l2sV1wIVh8D3ISaSsFUtreCPvq0TouywHEf/Bo2/tqyJMbT2lu oTUPm7DAoQ1HgyPfBQNeDHiQ2RrMZ+HbHG9XibkfGSY8BaL3M+8v3lqdiK0e59x3/0VZ CBnQ==
X-Gm-Message-State: AOUpUlFrabGOjl/WslurR7Gzco0YkZ4piLqY/0uq9I5pICLmM/k+31Zj vHjRTktlzYKMZq245CkZ8SetZ9/4aVtthfiqn/hmMw==
X-Google-Smtp-Source: AA+uWPya+zYYDGBdyQa9k8E61kMhwWaUcypMxL3/gjPodkyV52kaiTI78fondH9UAMhOGfCyIdtw8hOf7uFvM1w+V84=
X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr48974036ioe.85.1534962941705; Wed, 22 Aug 2018 11:35:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a006:0:0:0:0:0 with HTTP; Wed, 22 Aug 2018 11:35:00 -0700 (PDT)
In-Reply-To: <5B7DAA47.6010503@redbarn.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com> <471139805.18285.1534847636363@appsuite.open-xchange.com> <FBE862C5-6999-4D2F-A877-4ACDF1F5FBF1@virtualized.org> <318323950.21554.1534926760460@appsuite.open-xchange.com> <CAPt1N1nFATxZQaw0kEwpaAFK67otwVCLfvOgg8+CLDasV66MQw@mail.gmail.com> <5B7DAA47.6010503@redbarn.org>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 22 Aug 2018 14:35:00 -0400
Message-ID: <CAPt1N1=5p9EZ0yjsVcTLRRZbxdyEwzeY+wNs3AnrDv3xbs7_cw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, dnsop WG <dnsop@ietf.org>, David Conrad <drc@virtualized.org>
Content-Type: multipart/alternative; boundary="000000000000e2936e05740a6868"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3y8bKfIe803QTN6aVY0qgq5Ablo>
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: Wed, 22 Aug 2018 18:35:45 -0000

It's never been up to the DHC working group to decide whether new DHCP
options are architecturally good.   People have often used the DHC working
group as a way to skate by due diligence on architectural considerations;
this was considered to be a problem even before I was chair, and we burned
a lot of time evaluating bad ideas before we decided not to be the place
where new work on DHCP options is done by default.   If a DHCP option were
to be entertained, this WG, the dprive WG or the DoH WG would be where it
would have to happen, not because the DHC working group is freezing new
features, but because it's not in their charter.

That said, you responded to a message where I talked about what I think we
ought to do to move forward by saying that moving forward is impossible
other than by just adding a hack somewhere.   I don't think that's true,
and in fact I'm feeling like I need to write up a threat analysis because
even though it's not something that I want to work on, it sounds like most
people assume it's impossible and I'm just suggesting it as a roadblock,
and the people who get that it's necessary don't seem to be any more
enthusiastic about doing it than I am.   I'd appreciate it if, when I've
written that analysis, you could contribute to it, but I'll understand if
you don't have time or don't think it's worthwhile.

On Wed, Aug 22, 2018 at 2:24 PM, Paul Vixie <paul@redbarn.org> wrote:

>
>
> Ted Lemon wrote:
>
>> Again, to repeat myself once more, one more time, I am asking that we
>> actually decide what to recommend, and not just say "we all already all
>> know what the right behavior is."   If we all agreed on what the correct
>> behavior was, we wouldn't be having this discussion.   Maybe if we tried
>> to describe what we all think the correct behavior was, we would realize
>> that we do agree on it, but we haven't done that yet.   And the possible
>> set of all behaviors is more complicated than you suggest.
>>
>
> with regard to dhcp, if the dhc wg is freezing new features pending
> authentication capabilities which are not forthcoming, then dhcp is off the
> table for DoT discovery.
>
> in that case, the purported android approach of "use DoT if it works" may
> be the only way forward. this means when current unauthenticated dhcp tells
> you what your rdns servers are, you'll try each of them with TCP/853 and
> use that if it works, else fall back to whatever you did before, which is
> probably UDP/53 falling back to TCP/53.
>
> --
> P Vixie
>
>