Re: [Doh] WG Review: DNS Over HTTPS (doh)

Eliot Lear <lear@cisco.com> Thu, 21 September 2017 07:02 UTC

Return-Path: <lear@cisco.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0213292F; Thu, 21 Sep 2017 00:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 f8R1i-haZbkg; Thu, 21 Sep 2017 00:02:42 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC513308F; Thu, 21 Sep 2017 00:02:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7493; q=dns/txt; s=iport; t=1505977362; x=1507186962; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=SxXrumKWy9gGpr7lw9K8dYM1/AbwoJzdXCYAUs1GBU4=; b=SvOLhGaiY9gITM8RRe1vnMIUCoG6ZNH8eWYtF4w47hJKM+gHTq4jZkfw N/iV9PmjsMJ+bETzdg6t3bv1qDIgM59fHVVldnLckNoXkkNxIp6coAIiP ls9wZLpxxP78RAzV+ZAT2MkLKvkdntLDBmxYaxOkH9bs0h/bbYXTxoHBb w=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAQC4YsNZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW6EHYsUkE0rkGuHUAcDhTsChSwUAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FI0gOEAsEFCoCAlcGAQwIAQEQih+nPYInJ4pXAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDg+DK4U3K4J9iA6CYAWhE4Q7giGNe4tXhySVOoE5NiFBTDIhCBwVSYUZHIF?= =?us-ascii?q?pPolYAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,424,1500940800"; d="asc'?scan'208,217";a="655804045"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 07:02:39 +0000
Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8L72dU3006047; Thu, 21 Sep 2017 07:02:39 GMT
To: Adam Roach <adam@nostrum.com>, Toerless Eckert <tte@cs.fau.de>, ietf@ietf.org
Cc: doh@ietf.org
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <c06bfd5a-743a-aa9f-68b4-4a60badc8bed@cisco.com>
Date: Thu, 21 Sep 2017 09:02:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="shAxErH3h3UbOorpaSKGwQKjQfTD08wbp"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/uE_psrVsBX-j9bkavY_wC2wBWY4>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 07:02:45 -0000

Hi,

On 9/21/17 12:54 AM, Adam Roach wrote:
> The issue with putting discovery in this charter is that it's the
> wrong community of interest and expertise for what you propose. I
> would imagine that this is the same reason that RFC3315bis is being
> done in DHC rather than V6OPS (although -- full disclosure -- that
> decision is a bit outside of what I tend to track).

The IETF has provenance over the DNS standards, and that ought not be so
quickly relinquished.  That includes discovery, which we have covered in
the past through mechanisms such as DHCP and RA.  We needn't be the only
ones to speak on the subject nor need there be only a single method
defined within IETF, but not speaking about it at all runs the risk of
creating a massive mess for enterprise deployments, because if the wrong
resolver is discovered, any number of functions commonly used in
enterprises will break, not the least of which would be malware
detection.  Perhaps enterprises could put up with that if they knew how
to regain the capability, and that ties back to discovery (and scoping).

Within the IETF, because the group isn't formed, you can't say whether
or not you have the correct community of interest engaged to do any of
the work because you have bypassed the BoF process that asks important
questions.  In fact, in this thread, apart from two people (myself and
PHB), I'm not sure ANYONE outside the author or the IESG and IAB has
actually stood up and said they're interested in this work.  But even
putting that aside, because you haven't held a BoF, you don't really
know whether or not you will have the right people in the room to handle
discovery.  And people are having trouble answering THAT question
because the goal is not clear (although mnot seems to have some notions
which sound ok).

What bothers me about this discussion is that adding a DHCP option is
not difficult, and the current operating model of the dhcp working group
is that they don't do options, but leave that to other wgs.  And so you
are creating a vacuum for this possibility through the exclusion clause
in the charter.

I am**not saying that the work has to be done all at once, by the way,
or in one document.  The discussion on the IETF list demonstrates, if
nothing else, that at least one clear theory of operation should also be
documented.

Eliot