Re: [Doh] Seeking input on draft-03

Erik Kline <ek@google.com> Thu, 08 February 2018 18:59 UTC

Return-Path: <ek@google.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 2539B126E3A for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 10:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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_RP_MATCHES_RCVD=-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=google.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 8feHwH_Rm-5Z for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 10:59:21 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 64222126DFF for <doh@ietf.org>; Thu, 8 Feb 2018 10:59:21 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id x62so3366430ywg.11 for <doh@ietf.org>; Thu, 08 Feb 2018 10:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aGUA+DPNFq5VvazO1vwL14GJax3EjRrTyigkhzg1/HY=; b=EnFU4N7I7P2xScbPQSeKkVAdodTloYol1QYyh3hdOUD5dDEUuhzfmwFNwJxHMjE0RQ mlr3TvBB04xIIpepnl4B7ucC8oepy8yYAFNMMSwP4yD5S7G5ceANds9/c/hgYoOEDdhk AQmWPzzLz/jdv4lcGB1j1IgxRde+QvQXtDG1j+xKhU17/mBMqymwXxef/VHGhC5jzYHo d7hUojOxWAhLbR7aMj8hQV/AIgnDmrxITnERbvnjp9RZTOXdn4WOHKXwWqcdgJterVK5 rSRYzEWExL0yN3TBsGTj98YQ70u2eGNyqD3BNv+WazpvUumHg79pgNEDNXjjxQRms3TP 0UMw==
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=aGUA+DPNFq5VvazO1vwL14GJax3EjRrTyigkhzg1/HY=; b=d2rN5mvan1XLzE+JC+9U59b/U4V9Mzp0uZ8gjtaBp+gQBLuL7AVf9OMTTq6FLzQV9d 6f2OPLS3BafXsc8iCdWWeDcCSMVMh7gQpjmse00EEksAwQl2sZwcT2oqJ5VM8Bka3Azi ynEsNZlkgeW5AxHU+2+YvnN+oiZ4xB62/Ovc7YAbuEY6b44Fhgp7+ALGbhtPUEnAY6GY cp2ZfGGUPh/mHVX0uAh8emfC4N+0OlNtjfADXDq/IlfHloJZQiS8Fk+GPe99P8Tuyafd L21aauAu1VDWdAlDow+82EHMUu3CZys2AyiJQG6Vrl6qWi0phAC5TpI6RCQesCaCT6tV sDVg==
X-Gm-Message-State: APf1xPC46oYfT8JtTySsxE9UuSmgVwl4wjOEzrUVmJvRucCW6zh6h3st vNm0KOs9GImTiV3IyGrsFJWZmhrBSm8j0/oUYGol0w==
X-Google-Smtp-Source: AH8x226QqrPV92Pcr0XaoKQJ8hH6uIxWML8cQ3FTUD03l5E5xl6CX2a2HNai76RhHbyrySbaDjnnawOG4gPXDdod98o=
X-Received: by 10.37.216.17 with SMTP id p17mr43167ybg.198.1518116360144; Thu, 08 Feb 2018 10:59:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.239.9 with HTTP; Thu, 8 Feb 2018 10:58:59 -0800 (PST)
In-Reply-To: <CAN-AkJsdu05PWFSC2CBGEWk_8dEUsvy2GUQ6rRcc09Xbp0kS6g@mail.gmail.com>
References: <CAHbrMsDwWvtcZy8fpg9gs3o+gc_umi9okJW6rvv+s4T7K9-sVQ@mail.gmail.com> <MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30@MWHPR08MB2432.namprd08.prod.outlook.com> <CAHbrMsCD4-Syy4+5PhC_c0K5TLR25gMUO5cxJUT3gC8=uT4GpA@mail.gmail.com> <CAN-AkJsdu05PWFSC2CBGEWk_8dEUsvy2GUQ6rRcc09Xbp0kS6g@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Thu, 8 Feb 2018 10:58:59 -0800
Message-ID: <CAAedzxqUE7AzioT5gJJs_sjq0GQjUZyhr4JBZTAv6pQjf32g6w@mail.gmail.com>
To: Justin Henck <henck@google.com>
Cc: Ben Schwartz <bemasc@google.com>, doh@ietf.org, mbishop@evequefou.be
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c068a146a18cc0564b80291"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/8TD0mYE9C-_p9kuSyf2rOd02EzI>
Subject: Re: [Doh] Seeking input on draft-03
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, 08 Feb 2018 18:59:24 -0000

Sounds like you might want a (TXT) record at the zone cut level?

On 8 February 2018 at 10:55, Justin Henck <henck@google.com>; wrote:
> I would like to see a way for clients to discover a DNS server hosted on a
> certain domain.  Perhaps a .well-known/dns path that contains a relative
> pointer and other metadata.  I'm imagining a use case whereby the user could
> choose to rely upon an organization that they find trustworthy which is
> offering DNS, without needing to do a significant amount of discovery (e.g.
> "maybe known.tld has a DNS server?").  You could of course also have an
> absolute pointer, but then you have to account for the situation whereby
> known.tld might delegate to unknown.tld.
>
> Justin Henck
> Google
>
>
> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com>; wrote:
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be>; wrote:
>>>
>>> I’m inclined to think this is a positive change.  We’re trying to do
>>> something better than the current world of “trust the local DNS server
>>> because unauthenticated DHCP says so”, and promiscuous trust just because a
>>> server claims it support DOH via a .well-known endpoint isn’t really any
>>> better.
>>
>>
>> To be clear, the draft never proposed promiscuous trust, which would
>> indeed be highly problematic.  However, draft-03 does include additional
>> language clarifying this point.
>>
>>>
>>> The client should know the hostname(s) of the DOH server(s) it wants to
>>> use
>>
>>
>> In draft-03, "knowing the hostname" is not sufficient, because there is no
>> default path for DOH.  This is the change on which I am seeking input.
>>
>>>
>>> , and it should authenticate the DOH server against that hostname.
>>
>>
>> Yes, definitely.  (I believe the draft is clear on this point, but feel
>> free to suggest improvements.)
>>
>>>
>>>   If a server hosts content and also wants to also serve DOH, there are
>>> ways to present a hostname that covers both names (or present two
>>> certificates) on an HTTP connection.
>>>
>>>
>>>
>>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz
>>> Sent: Thursday, February 8, 2018 10:05 AM
>>> To: doh@ietf.org
>>> Subject: [Doh] Seeking input on draft-03
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> The authors of draft-ietf-doh-dns-over-https have been making good
>>> progress, and a draft-03 is now ready with several changes and
>>> clarifications.
>>>
>>>
>>>
>>> One important difference is that draft-03 no longer proposes a
>>> ".well-known" entry.  In draft-02 and prior, clients could check for the
>>> presence of a DOH service at the default path, given only the domain name of
>>> a server.  In draft-03, there is no default path, so clients must be
>>> configured with the full URL of the DOH endpoint.
>>>
>>>
>>>
>>> Is this change compatible with your use cases?  Would this alter the way
>>> users interact with your systems?  How do you think DOH client configuration
>>> should work?
>>>
>>>
>>>
>>> Please respond with your thoughts,
>>>
>>> Ben Schwartz
>>
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>