Re: [Doh] Seeking input on draft-03

Justin Henck <henck@google.com> Thu, 08 February 2018 18:56 UTC

Return-Path: <henck@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 7EF8F1270AC for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 10:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 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_LOW=-0.7, 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 OQaLscJbT-Ku for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 10:56:02 -0800 (PST)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 6AADC12D969 for <doh@ietf.org>; Thu, 8 Feb 2018 10:56:02 -0800 (PST)
Received: by mail-it0-x230.google.com with SMTP id u12so489100ite.0 for <doh@ietf.org>; Thu, 08 Feb 2018 10:56:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nR5iRBnrSfseY1bCtlr6VlB4jaCcGxwzDOg5EHSf0VI=; b=mg9toSX69h5nPt5oHlj7fUQ+/0pnblPDtKCAjxyDIouPeffqYN+fWSrS5CCcu/AQB9 GpeVUGfA7pkc6a+0Y01YiXLjsMcXegyOreNpcnOFEdIywwzfeEc2sYFzG/W0WvbaXWw7 WMoBQUlnBK4j3GRZI4kuJERTWLndmet+dI1nhncTJpWxQAZ+VhedrCYXa+6fWlM6uXs/ 0+ODDp5oASd8YipbRO3SAeCwqTnGp0YkdNQIuq9ATcQWMCJY/IgQqrJzECAjq5NOAkYL MNtKROO4CXSy57lBvTavCulV8NYS613e/+M8jf3mRGqX/xrKdQGAYsGo4mIKK3PELyTr TkIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nR5iRBnrSfseY1bCtlr6VlB4jaCcGxwzDOg5EHSf0VI=; b=MEZx7bq+3LVjCXhAy88ClDawFk32FnaNnXB0FhLhIV7y5iAR6v6vIYAbVhNkScxKiQ /IQioyWiW3rogEdQaLjO5gmord99G/C0XOQwSJpOeDgZxvD/jSfyl/D79DOk+J54/XSF UXmQlfQUopxLVErPvhzJow19SaZwY/BuNAjOLRPl29xNNpjLOUjyqvC51USC8tpkVgtB rmIUzBTplwHi2aI9lLZFtpj9umggdByzhQhIwuJ+/A+9SAGYuRIm6azWjR7qr6FQLuBn Mac7r+VF84lyplDwTOJS+fvTyRIY5XecyP+bOX/GEKgcKmGMPmFDr7Y/ySCiMBBymi58 t9Tw==
X-Gm-Message-State: APf1xPA7EqnRx/Pxbu+t4j3eXMsu9I4fMdEljHefA6aFGjJzVgSZSeUY Z2JS9COWOAqSEoHWCI9GGsqv+iw6ONDNylg4JNKLK/9J
X-Google-Smtp-Source: AH8x227DKTdBHi/eiyDJ1qx8NN5H1N6EaMpJPo/U3brUCooA5Aunf84nM50dPDYu/7wprRt0AtLvsiesZuVUluL4DDA=
X-Received: by 10.36.221.18 with SMTP id t18mr192808itf.106.1518116161257; Thu, 08 Feb 2018 10:56:01 -0800 (PST)
MIME-Version: 1.0
References: <CAHbrMsDwWvtcZy8fpg9gs3o+gc_umi9okJW6rvv+s4T7K9-sVQ@mail.gmail.com> <MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30@MWHPR08MB2432.namprd08.prod.outlook.com> <CAHbrMsCD4-Syy4+5PhC_c0K5TLR25gMUO5cxJUT3gC8=uT4GpA@mail.gmail.com>
In-Reply-To: <CAHbrMsCD4-Syy4+5PhC_c0K5TLR25gMUO5cxJUT3gC8=uT4GpA@mail.gmail.com>
From: Justin Henck <henck@google.com>
Date: Thu, 08 Feb 2018 18:55:50 +0000
Message-ID: <CAN-AkJsdu05PWFSC2CBGEWk_8dEUsvy2GUQ6rRcc09Xbp0kS6g@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: mbishop@evequefou.be, doh@ietf.org
Content-Type: multipart/alternative; boundary="001a1144e30a85b0410564b7f614"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PZZe4KGr5LHsds7NVWCFrinSjaI>
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:56:13 -0000

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
>