Re: [Doh] Seeking input on draft-03

Justin Henck <henck@google.com> Thu, 08 February 2018 19:17 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 82C2C127337 for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 11:17:11 -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 oO72MKuITmwC for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 11:17:09 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 CB1FE1273B1 for <doh@ietf.org>; Thu, 8 Feb 2018 11:17:08 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id t22so6952661ioa.7 for <doh@ietf.org>; Thu, 08 Feb 2018 11:17:08 -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=bisI+qHi5WqbKtzAiU2M+Lae02NZmwhP25hTNCbhDA8=; b=BIkhlMK5R7Rg+KMO0AgQRMrfxh+ymeYhXu5Rhn7Ky0mAxe9xidy4US/+5eDithxsiZ 7S4R1aBqCDcj1wF6WphaaV3T2c6ZNX5pkkEEC5qvpfKeQ31fZODctP7UFJjJIFvwwFGC eZ3emchaMM1mwOnDKChIHHTW2Kv57cSO88tvwQwCoB1DBE+7O/VWPFWV63hMmb+R2P6n j3HXfN3qgFB2qLEzZBWbbhVxIxsNCrf7hizGLvkt8LcOxrKMGLbKCQgiudw8L3MmSp5S TLlvQqUhB1Ngkl0Z6JgsHN8KeuTUcRdnToxMnPeUKtlUERO1Okx2qvqj3S3Bujsetn/P srPw==
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=bisI+qHi5WqbKtzAiU2M+Lae02NZmwhP25hTNCbhDA8=; b=uENuIhS48ub6oIWGcZf6SM0HC+ZewvSAktltegg0hy/IRsvxIM4lqLpdu/cZ0iwkns 8bkBUjDoT7pt4WohWCQijbMOj40yLyDoSzgSQYyocvIoPAnK9L5DjVm4w8LL+FF36msV OFFET5NHUVOt7qfs8CT3zL0YrK2Svzw6QAplc7FV88JOcnxQXX5J7lPWS/x1/6HmWPAS Ygk23bm53eXXp7r5Sd4Iz84jO3t63dKcvYfCfvI4cH8ryWZsP9ohpcb6yigfsQjL0QFO lyI5uE99PiIUGoXF9xO8w++mSB2x3/QDvCNGDIIzYe4Qy1wwT6TW8OMedmVdNWbzUv38 9n1A==
X-Gm-Message-State: APf1xPCoWS+7/AKpRDuxnT6tLXxk/C8ceB8yi4WARS0+fkdSA/6nzdWR QQ9TCcHEqSZs7EaizYGhZAdr5zb+rPaFaoy8AF3KK36G
X-Google-Smtp-Source: AH8x224p7xYuvIVgrzst5FBY5v3ZjhLWSCWl9ukJOVn/L0oBbR0KKTMLGRaPDJAKPuFt6G7CPs3a803tVH2i9k8LqEg=
X-Received: by 10.107.201.136 with SMTP id z130mr304912iof.257.1518117427523; Thu, 08 Feb 2018 11:17:07 -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> <CAN-AkJsdu05PWFSC2CBGEWk_8dEUsvy2GUQ6rRcc09Xbp0kS6g@mail.gmail.com> <CAAedzxqUE7AzioT5gJJs_sjq0GQjUZyhr4JBZTAv6pQjf32g6w@mail.gmail.com>
In-Reply-To: <CAAedzxqUE7AzioT5gJJs_sjq0GQjUZyhr4JBZTAv6pQjf32g6w@mail.gmail.com>
From: Justin Henck <henck@google.com>
Date: Thu, 08 Feb 2018 19:16:56 +0000
Message-ID: <CAN-AkJsDba0qf7raYBAwbQK7F6Ov=6CXVVcAK=fFRrfRupmp4g@mail.gmail.com>
To: ek@google.com
Cc: Ben Schwartz <bemasc@google.com>, doh@ietf.org, mbishop@evequefou.be
Content-Type: multipart/alternative; boundary="94eb2c0b8cd8ff64fa0564b8410a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ORt1YSw-sx6Sy7c_j9drG5Udbgc>
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:17:11 -0000

That would work for the situation I specified, but I think that a
.well-known pointer provides the additional benefit of serving more
technical users with an advanced configuration. (It is also in-line with
the intended use of .well-known as I understand RFC 5785.)

Specifically, if an implementer creates an advanced setting whereby you can
configure a DOH server with both a domain and an IP (to eliminate the need
for bootstrapping) then you have made the user's life easier. And, although
a URI is not supposed to change, a .well-known/dns pointer requirement
would ensure that capricious servers don't break manually-configured
clients.


Justin Henck
Product Manager
212-565-9811
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B


On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <ek@google.com> wrote:

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