Re: [Doh] Seeking input on draft-03

manu tman <chantr4@gmail.com> Thu, 08 February 2018 19:19 UTC

Return-Path: <chantr4@gmail.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 8A5F01273B1 for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 11:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0Z8ypqlGKc9B for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 11:19:16 -0800 (PST)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 325C7127337 for <doh@ietf.org>; Thu, 8 Feb 2018 11:19:16 -0800 (PST)
Received: by mail-lf0-x241.google.com with SMTP id h78so779975lfg.6 for <doh@ietf.org>; Thu, 08 Feb 2018 11:19:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=01a6SDvn8OHZVDHOwwNuIVVHfYRfCgKxqa0Yaff86wg=; b=tBZnyLBcNYtm2whw/eFOzv6BeaRE4ChdtRLayJRH3u9LNJP2pg10/mItF/nLO0u0Jp 0pAf3dpW6aMyqaDhZk4Gkz+dZprRgRi83UYAiuTurr83m7KZ9aM5LYuch61jOv/Iu/q0 ojeMek1ieV1cSlod1me4WTI0DwrrSs46WRl8H4npgmhCBCsZcb/5K5HIT0FyaPrg23XM TFwtPRPu8D8+Muv9hPX8Ax2SbjdJi1rvnLl31j7k0n/BQJdUAh2BG+qbKBoqUZ1KG9gb /s/G+1LTSlYh6mkPPLrYLtUaM0krjF1hVKvadeUFRo7SVWPi0AP3EzH0DD+CqYZc/6Vs Cosw==
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=01a6SDvn8OHZVDHOwwNuIVVHfYRfCgKxqa0Yaff86wg=; b=OycoP25B3bgblI3NRT8oRt7wWpojpuZdbPC4nGeTljr6MyBhYObmRguLYXzm71BSxR 7IgAAPUJYXXKbdNMH1/sAASS/mW3c1FjpsNoHnigAJUnxZuQYQYeqd4dAzmNBisldXpe bOyNWY1L43dB2rY7NIlCO4V+Oul/uQtFlpISOLGvTkpGyeSirIjErsBBOu2iBBQwO3fz /9uK7Twkk1MhhlWW5ig3I4ZU+Kdv/KDeUX6MXkJDRmnVV7MBL6ECQ2WV9hndgfOFMi2g 5CkcGIiBB7EKllR9MX3X0mTE2IGuvR10RnIn1yerRV41ZM8bQ3/d1OeAFqgzVdR1NvDb UNtA==
X-Gm-Message-State: APf1xPCgH3hYJ39jHPqC7Wt50j83SsOvhoZrBcUb3rO7ZcSCT4/99bI2 lAvg3PsjeJEHOWxlPDFcuruH3yX4zegyXK+K03M=
X-Google-Smtp-Source: AH8x224k6ANkhU3EKlduPCP6I/XVRCmX2LzDWe4lWLJNKO+UFGnpeL7ikBF9mhFRBk139rMxg5NhtqmRci9UD8YdKbE=
X-Received: by 10.46.108.9 with SMTP id h9mr139934ljc.125.1518117554187; Thu, 08 Feb 2018 11:19:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.227.5 with HTTP; Thu, 8 Feb 2018 11:19:13 -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: manu tman <chantr4@gmail.com>
Date: Thu, 8 Feb 2018 11:19:13 -0800
Message-ID: <CAArYzrLfchP+Sd+tRm0Bv+yrUG2ASBmrmQVS7Wt9hztEwpHAUw@mail.gmail.com>
To: Justin Henck <henck@google.com>
Cc: Ben Schwartz <bemasc@google.com>, doh@ietf.org, mbishop@evequefou.be
Content-Type: multipart/alternative; boundary="f4f5e80791188b730c0564b84938"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/w9lAnDjwEXlRMAgWFXVV_260GIE>
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 19:19:18 -0000

On Thu, Feb 8, 2018 at 10:55 AM, 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.
>

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/75 touches on
discoverability.

I am more in favor of a set of simple requirements, so simple client and
server implementation can exist and provide the basics of DOH
functionality.
Optionally, discovery can be used to be more fancy and provide
extensibility, but at the core of it, I would expect that knowing a domain
and optionally an IP (to avoid the chicken and egg issue of being able to
resolve the DOH server IP ) should be enough to be able to access DNS over
HTTPS using GET at a well known endpoint.
Enforcing discovery will most likely slow and prevent new implementations.

Manu



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