Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver

Ben Schwartz <bemasc@google.com> Wed, 24 October 2018 17: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 9C1B71277D2 for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 10:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 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, 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 KGAt_ZazPQTN for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 10:05:23 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 45382130E39 for <doh@ietf.org>; Wed, 24 Oct 2018 10:05:23 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id p83-v6so3591732iod.12 for <doh@ietf.org>; Wed, 24 Oct 2018 10:05:23 -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=wJkLF9nNEACpj8x02mscdr7I64EhJ3j3evRz6mN2jps=; b=hQJD5zCqlMvjvwuk7urURseLy/K9y11OA2tGdeB7wf6gnzzg6vI3E7LJai1rNiWE/2 w9Y1y6C+0qy+drRivAFZ16J44M1Qd+E1jwExSdR6uV8UfLa72hoadtARYtoiOhdhRwhK DsEY0vs5N5p0ktV5s1ssJyC0ZKPMVwnzbDRzxSCWJ8bZGH88WJOPm6rRPlQ5HrgWrbBM HZD/mSqjSSjCNaKD2+A6g9gD/BoR0EtUh7wFi6+hbNjixr+tPqQiZEEcMkOvIh6kbgps WmQvXcPbm06q5fc6hkx0zjoj0cylFwhMaJFmsVQqIXN0iT635ZKO4vgo9c023hjPAVgj XCKw==
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=wJkLF9nNEACpj8x02mscdr7I64EhJ3j3evRz6mN2jps=; b=pAngJ9+PnQl16+t14UgoT8LQ1KNXd7d94o3slowDDNa37wxk9sZJiOPSDFVa/aDwRk Kv4ikKg8gVHuXUGHdXddnpUR7k1pR71oZvpzCBReWfE8UBZ6rJS6FEr8sM9+drNP2fjT B/cyFeGS0Dr1h9UTaPkp6CBmjpqcP4uHW+AWN2qD8utzZXewytwwh2ZL9nMzMzFfpSzu Fd5he4rubR2ht+w0Sgw5N5tZn+L/ZIpos38/LQ+e4xKz2P19cKo3l3Org4NSv41md5O1 yVMhIGw6B3rVk62pPwCIYPpYuLL8LXBR4Ho/OaYNLo9SWSW63ztv4yk1LWmfbi/o4OZy qtiw==
X-Gm-Message-State: AGRZ1gJHqsvnO5QfwVuUp1lb3SuaCr2eed0Oc+0Yu/oHZWu4YXw+Pf5k zXcsyKwpsO4fBQJTdtrhfUMAPiS0M6q5eilKsR6w36QX26aRNw==
X-Google-Smtp-Source: AJdET5e/iJmfdjdQ4MLRqzdzuf5R6NgGeQf9AQV9tB+Ni//6ryGuVuNTzbHl2N4+aaM009I05sx5ddmsPpdoW3bUg38=
X-Received: by 2002:a5e:de45:: with SMTP id e5-v6mr12479033ioq.235.1540400721640; Wed, 24 Oct 2018 10:05:21 -0700 (PDT)
MIME-Version: 1.0
References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> <CAJ9-zoUtsunVNuuMOdhJfsE9qqD9bNW_YA4z3Gr1_zormLku=Q@mail.gmail.com> <003601d46b81$341b13d0$9c513b70$@sebbe.eu>
In-Reply-To: <003601d46b81$341b13d0$9c513b70$@sebbe.eu>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 24 Oct 2018 13:05:09 -0400
Message-ID: <CAHbrMsDCj1EmYkG6=uGqEefaXEfv3z+UQ8bSuV1UrUS6dckqgA@mail.gmail.com>
To: sebastian=40sebbe.eu@dmarc.ietf.org
Cc: ulrich@wisser.se, DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000dc4a410578fc7d46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/iD2FcsoH7B4Hsg2CRbE0jOskYok>
Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH 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: Wed, 24 Oct 2018 17:05:26 -0000

Hi Sebastian,

This is definitely a topic of interest, but it may be outside of the DoH
Working Group's charter.  Discussions on this topic have been moved to
their own special mailing list:
https://mailarchive.ietf.org/arch/browse/resolverless-dns/

I encourage you to read the messages there, and also to send your thoughts
to that list.

Thanks,
Ben Schwartz

On Wed, Oct 24, 2018 at 6:06 AM Sebastian Nielsen <sebastian=
40sebbe.eu@dmarc.ietf.org> wrote:

> 1: Yes, but the server should supply the whole chain to the root, thus the
> client only need to do root validation.
>
> 2: yes.
>
> 3: The reason to require DNSSEC signature for third-party domains is so
> not a hostile WWW server can replace answers to third party domains, for
> example loading paypal.com in a frame and then pointing paypal.com to
> themselves.
>
>
>
> 4: The server should point this out to the administrator during
> configuration. The thing is that the client should refuse to accept
> non-DNSSEC signed responses for reason 3. The server could just refuse
> queries for domains not DNSSEC signed, like for domains not in the ACL, but
> the server should of course keep the domain in the ACL in case it selects
> to start DNSSEC signing in the future, but for such domains cache updating
> could be done less often, for example weekly.
>
>
>
> During configuration of the ACL, or startup of the server software, and if
> it doesn’t have any cache data written, the server could simply “prime” the
> cache by doing one request for all domains in the ACL, for all record types.
>
>
>
> *Från:* Doh <doh-bounces@ietf.org> *För *Ulrich Wisser
> *Skickat:* den 24 oktober 2018 11:54
> *Till:* Sebastian Nielsen <sebastian=40sebbe.eu@dmarc.ietf.org>
> *Kopia:* doh@ietf.org
> *Ämne:* Re: [Doh] Suggestion: The final endpoint should be able to
> temporarly act as a recursive DoH resolver
>
>
>
> I can see the reason behind this but would like to point out a few details.
>
>
>
> - clients would have to do dnssec validation
>
> - servers would need to not only provide answers to queries, but also the
> dnssec chain for the validation
>
> - what should happen with not dnssec signed answers? Dropped? How will the
> client get an answer in that case?
>
>
>
> Additionally, I think it should be made clearer that an endpoint should
> only answer for a known list of domains, as to not get abused by clients.
>
> - what should a server do if a not dnssec signed domain is configured in
> it's list?
>
>
>
> /Ulrich
>
>
>
> Sebastian Nielsen <sebastian=40sebbe.eu@dmarc.ietf.org> schrieb am Mi.,
> 24. Okt. 2018 um 11:38 Uhr:
>
> I have a suggestion for extending the DoH specification:
>
>
>
> The final endpoint, should be able to act as a authorative and sometimes
> recursive DoH resolver if it has support for the DoH protocol, during the
> normal HTTPS connection.
>
>
>
> This could mean that once you reach a WWW server, theres no need for
> looking up domains like static.example.org and such since the result of
> such domains could be returned by the original HTTPS server over the same
> connection as the website traffic goes over.
>
> If the HTTPS server has other domains for example
> ads.thirdparty-example.org as links it could return those aswell but only
> if they are DNSSEC signed, and for security, a DoH client should only
> accept results for a third-party domain if the result is DNSSEC signed.
>
>
>
> To avoid abuse, a WWW server supporting this extension should only allow
> queries for its own domain and subdomains, and also queries for any
> resources it has been configured to resolve (and this type of configuration
> could be done automatically by for example a script on the web server that
> adds all external links to its ACL)
>
>
>
> This would mean an WWW server serving content for itself and also have
> links to ads.thirdparty-example.org could have those 2 domains cached in
> its internal DoH resolver and resolve for those, thus once you reach a
> webpage’s server, you no longer need to talk to your recursive DoH serverl,
> which also increases privacy.
>
>
>
> This could lead to much faster response times aswell, as the WWW server
> would have the information about all its linked hosts permanently cached
> and updated regularly.
>
> Think like OCSP stapling but for DNS responses instead.
>
>
>
>
>
> Best regard, Sebastian Nielsen
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
> --
>
> Ulrich Wisser
>
> ulrich@wisser.se
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>