Re: [Doh] Associating a DoH server with a resolver

Ben Schwartz <bemasc@google.com> Tue, 23 October 2018 21:05 UTC

Return-Path: <bemasc@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 EF766130E8B for <doh@ietfa.amsl.com>; Tue, 23 Oct 2018 14:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 0Vp_NP6nKieI for <doh@ietfa.amsl.com>; Tue, 23 Oct 2018 14:05:30 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 D677C130F5B for <doh@ietf.org>; Tue, 23 Oct 2018 14:05:29 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id q70-v6so3619633itb.3 for <doh@ietf.org>; Tue, 23 Oct 2018 14:05:29 -0700 (PDT)
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=MbWeBOOhRl0h6nxKkB76EPP6osljfYJw4QeZiAhke14=; b=FNLvg8ite0vgd23SzQaXljhlpp5pYWTb9KdAl7vPoWY6zKRFKpYKFzU2ZvXQ95yI1o wfxJy3ld7tGyHEraZBwRoi1sORTiRkCxqckVgx2lYPqxcMHkVg5Zky23LbOiRlAAZe2m CWHGZlAqGmsj0vtza/0I+N1O6WEOYhIC4SGcLmaECjdd9ht8Y7bPDyY5JUpcDfTo3CfH OmbtRIsAnTN3ExoQ6Gzs2sHSywKqD5Zz0gWOrNJ9lWrdOTPBKujgxn2G44z7GVK50S/G z+MVcy2qaKHCbXgY1/fcg4NEsBqrzOkSE1MT6zXrw42ZDqFGfKWn9dBR608lTY2hyWMo x/GA==
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=MbWeBOOhRl0h6nxKkB76EPP6osljfYJw4QeZiAhke14=; b=MZjR1zEUN27XUlwpyk0L1GV2R++ShM+RGSiCGahGjyirnuVh+IgKwCBzGHAXzx3GHL fRR/q4xz9DbVStRR6UmCovCLBo+5N+C+0MJ6RowAfHsqnNNOoC5GQ0AV/BYZhIclU1Bd RCeSfjoTcza1/dBUBNCD4zuMHo0aG2s/Ny77VS+ROXPCLHK/e5PDh66E2U+YIxsqq0mm WbNglT2+jMsiJXK9s1plCVsLdYn4PidoA40iVsfTbCtY/cQ4H1fu6eUIb/aMLU5wA49f fWyOYTH7Z3WzmW3kVBeoJ+jl9HpcVtDrPjt9MNjpOytpu2DZ40CNp2rGzqDJnpDiAkFF Zoyw==
X-Gm-Message-State: AGRZ1gJyajyBsbW5JZNOGbhJ9Sx52hQ1oxYm/3IEJ3Th5bV1xhcCXeD1 h8SPrY4pckeQzwMewJNkMDcyhed0/vfhTwbh8vK0Og==
X-Google-Smtp-Source: AJdET5fCBbNBr3wIz3myBwTJ0g3HpyY34fybHtAnPKSIZC9nYXs7X2Z4sIAQJi8pFuU75BXmRd1o/JgpgeieR9FDXg4=
X-Received: by 2002:a05:660c:284:: with SMTP id s4mr851559itl.162.1540328728522; Tue, 23 Oct 2018 14:05:28 -0700 (PDT)
MIME-Version: 1.0
References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org>
In-Reply-To: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 23 Oct 2018 17:05:17 -0400
Message-ID: <CAHbrMsCg61hQs2+yZk2Cyrn5VSAR--=sXaUNhH+7Wgp+6zBG=Q@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000bcf87a0578ebbafa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/-wNtFMSgRKx5O8sY4dzmE0acbj8>
Subject: Re: [Doh] Associating a DoH server with a resolver
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Oct 2018 21:05:36 -0000

Hi Paul, thanks for the continuing work on this topic.

Two related questions:
1. Does the resolver have to return its own IP in the RR for
resolver-addresses.arpa, or can it return some other IP addresses?
2. If a client has some OS-specific way to enumerate the DNS server IPs for
the default network interface, is it still required to perform "Step 1"?
(Most OSes do have some enumeration mechanism like this.)

Other minor comments:
On Section 4, User Interface: I don't see the need for a user interface
here.  In my view, opportunistic security generally shouldn't require user
action and shouldn't produce a user-visible change.

I think interaction with DoT is worth discussing here, even though it's
probably trivial.  If I can probe for DoT and (with this draft) DoH, which
one do I probe first, and which should I prefer if both succeed?

--Ben

On Tue, Oct 23, 2018 at 4:15 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

> Post-RFC-publication greetings. One of the topics that has been active in
> the DNS community since the standardization of DoH is how a browser or web
> application could use the resolver that the operating system on which it is
> running as a DoH server, or at least to use a DoH server associated with
> that resolver. I have taken a few stabs at designing a protocol to make it
> possible to fulfill that need; the result is the draft below.
>
> The draft is still in a very early stage. In fact, I've changed the
> underlying mechanism three times already because I forgot what browsers and
> operating systems could not do. I *think* the current draft is possible,
> but would not be surprised if someone pointed out that even this attempt is
> wrong. Regardless, the desire for such functionality seems strong.
>
> Also note the Security Considerations section of the draft. In short: all
> this gives you is opportunistic encryption because (I believe) we can't get
> any better now. I would be happy to be wrong about that, of course.
>
> Thoughts?
>
> --Paul Hoffman
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Associating a DoH Server with a Resolver
>         Author          : Paul Hoffman
>         Filename        : draft-hoffman-resolver-associated-doh-04.txt
>         Pages           : 8
>         Date            : 2018-10-23
>
> Abstract:
>    Browsers and web applications may want to know if there are one or
>    more DoH servers associated with the DNS recursive resolver that the
>    operating system is already using.  This would allow them to get DNS
>    responses from a resolver that the user (or, more likely, the user's
>    network administrator) has already chosen.  This document describes a
>    protocol for a resolver to tell a client what its associated DoH
>    servers are.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-04
>
> https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-hoffman-resolver-associated-doh-04
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>