Re: [Doh] Seeking input on draft-03

manu tman <chantr4@gmail.com> Thu, 08 February 2018 21:36 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 6C96012D7E5 for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 13:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.458
X-Spam-Level:
X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 as2lys-Y2Lk1 for <doh@ietfa.amsl.com>; Thu, 8 Feb 2018 13:36:15 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 5405112751F for <doh@ietf.org>; Thu, 8 Feb 2018 13:36:14 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id a204so8432338lfa.2 for <doh@ietf.org>; Thu, 08 Feb 2018 13:36:14 -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=EptNbqgwVYxbWL2Bof59m09oVfdaCnfsz44ZLy/yJ4Q=; b=TaZhv5997u/RRZZvDyyY25pskZX7wO98uptwoyLEedVZp72ao7QxW8Ta+gepnyxVqJ swCGVBXkDTpFCBWFJsOzE3hlVp+wX40Av/oZ33q1pGvpslN/8+PhmJlbcKTZYsiJd/+C FZ+xGWNopaHj/37ayXWaKfD9FYl6VhZkSCnbLI29QGdz5Xok+hp33Tk1KTV3v2Jk5IBT dMxnuG+s12fXO+war7J1WD7+/d9KqqSaksKHILA+gX7Zt2Ad4u0PJ5k2ctJqRWuRryfO cuh/TkEW4mJFX0i5xC5ttFT9Kd4P7QFW88qzlW79wZiNi7IEuX/RRcNQGDTTV1wd1zqS JTpw==
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=EptNbqgwVYxbWL2Bof59m09oVfdaCnfsz44ZLy/yJ4Q=; b=Q0h2yy9c264vZ0Ht0vIVGklF+ltFpS2DHG+B7PH8A0yvSkvtsLzEN8Sy9sL05z1br7 OMZC3JDGIqhRZqs7LP70b5IORUdnF9KIYFbayk2M/nv/6zpHiLbD3XRA4AgcDnpd3muM Ktn6MGegwfvj7ueEWoE7cGlgz1ukQRWMBfemuVKs9+/BQ33RZC4gZvO/daTw7H1SxSvS mFaqFHuvpASwXJgXWJO6PjiWDpq79hz5yFct8AeMw1qBI60bYJ3Tw5lKBONHFT98L+5M hGIZQso8gXS5b+2rsYj4uTtsbZuZBReZzSeaTyXLWX/NFWz+hL1e9+PkKkQrhxAs/QVS VszQ==
X-Gm-Message-State: APf1xPA2cvr7V+oEBFJ7FGrzui6VQqNEmg3JTJNQMvJOm7/eTE/JALeS RBCZT9YO/eJmJirRtxHoqF1o+8PSwP4KBT+pUjw=
X-Google-Smtp-Source: AH8x226g8gSVy+j30cl3hNOT3t/jGLXlcK8yQv6xmkBba0ejWHoEvUBDi51DlLLTBXTmxiuwIJaW/ORpn+Q/zaHJxQA=
X-Received: by 10.46.17.91 with SMTP id f88mr382664lje.54.1518125772397; Thu, 08 Feb 2018 13:36:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.227.5 with HTTP; Thu, 8 Feb 2018 13:36:11 -0800 (PST)
In-Reply-To: <CAN-AkJuNUuM85ie+pgqTuQD9SgZ-PpV7hj6K-7oUhrSvGiOhaw@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> <CAAedzxqUE7AzioT5gJJs_sjq0GQjUZyhr4JBZTAv6pQjf32g6w@mail.gmail.com> <CAN-AkJsDba0qf7raYBAwbQK7F6Ov=6CXVVcAK=fFRrfRupmp4g@mail.gmail.com> <f718b5d15a564d63a0e46543e1d56fbd@usma1ex-dag1mb3.msg.corp.akamai.com> <CAN-AkJuNUuM85ie+pgqTuQD9SgZ-PpV7hj6K-7oUhrSvGiOhaw@mail.gmail.com>
From: manu tman <chantr4@gmail.com>
Date: Thu, 8 Feb 2018 13:36:11 -0800
Message-ID: <CAArYzrLRx=4E07Uhh53APbCiZ_kzNjizO3VwaenXhMvjsPyECg@mail.gmail.com>
To: Justin Henck <henck@google.com>
Cc: rhewitt@akamai.com, Ben Schwartz <bemasc@google.com>, ek@google.com, doh@ietf.org, mbishop@evequefou.be
Content-Type: multipart/alternative; boundary="94eb2c1c0a1c6361050564ba332f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/WRMAnAw7idRA7E6I-PwLKf1QEUY>
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 21:36:18 -0000

On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck <henck@google.com>; wrote:

> 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.
>
>
> I may be misunderstanding, but doesn't this imply either a fixed path, or
> a discoverable path via another (e.g. .well-known/dns)?
>

Yes, I mean to have a fixed well-known path that provides DOH service (as
in actual DNS queries) that can be used universally. So, any clients, given
a domain, can use DOH without having to go through the steps of service
discovery indirections.
What I understood from you original comment was to use this as an entry
point to discover alternate locations, delegation... I think it is worth it
but should be optional.

At the end of the day, either accessing a discovery endpoint or DOH service
endpoint, the client will need to be told where to get it. Having a
predefined entry point would make this easier.


>
>
> On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory <rhewitt@akamai.com>; wrote:
>
>> Additionally, using /.well-known/ would allow for URI Template discovery,
>> if required - client retrieves URI Template from e.g.
>> /.well-known/doh.template and then uses that to build DNS request URI.
>>
>>
>>
>> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for
>> @mnot's suggestion.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Rory
>>
>>
>>
>> *Rory Hewitt*
>>
>> Senior Solutions Architect
>>
>> Global Services & Support
>>
>> Akamai Technologies
>>
>> Tel: (408) 650-0035
>>
>>
>>
>> *From:* Justin Henck [mailto:henck@google.com]
>> *Sent:* Thursday, February 8, 2018 11:17 AM
>> *To:* ek@google.com
>> *Cc:* Ben Schwartz <bemasc@google.com>;; doh@ietf.org;
>> mbishop@evequefou.be
>> *Subject:* Re: [Doh] Seeking input on draft-03
>>
>>
>>
>> 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 <(212)%20565-9811>
>>
>> google.com/jigsaw
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__google.com_jigsaw&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=N-RLQbYhldj1naDovU3jQQtWdiNb5pbKuxXJJ3p663Y&e=>
>>
>>
>>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
>> >
>> >
>> > _______________________________________________
>> > Doh mailing list
>> > Doh@ietf.org
>> > https://www.ietf.org/mailman/listinfo/doh
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
>> >
>>
>>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>