Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Marek Vavruša <mvavrusa@cloudflare.com> Tue, 21 August 2018 07:30 UTC

Return-Path: <mvavrusa@cloudflare.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5C130E25 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 00:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 Jv_nQmYMzDiT for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 00:30:03 -0700 (PDT)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 6DDE1130E13 for <dnsop@ietf.org>; Tue, 21 Aug 2018 00:30:03 -0700 (PDT)
Received: by mail-yw1-xc29.google.com with SMTP id x67-v6so2725345ywg.0 for <dnsop@ietf.org>; Tue, 21 Aug 2018 00:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TQgGD1wKv/7Nspr9Aakdz2PmCNOST+OWxOdxpZXoV10=; b=vXcqlkp235OSHiUeeA2K+/rMVFBdGPNsFKhhYSJ7MQHyB05j5qBXRMK3EsdQciAIjP fTc6nu51I6PWykFziEJDjIgijVfWwlgmSWKUiyCJ22ZBuUWzd3fySNLkqkQSGC6JBidO OuNiRPuyCCk54MeHaWcbYMBvsPJ/BflKlSk5A=
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:content-transfer-encoding; bh=TQgGD1wKv/7Nspr9Aakdz2PmCNOST+OWxOdxpZXoV10=; b=M4gnLZKAmGKCOCMHO1TrWQ8s4B65GG1uyZPt1SNl0oT0z2SZ9w/oTew22sx8MO7KKy cWiDR1QaeYc50Ie9r99s6rf3QmsszjSSMf+Hq7s4K5CahejfQpv+w1nInJakqrC4vOjY imExah2UDZVuiHfW6Ex8X/ah2J3If/E38Qy+aBUYLQiTneVdQAxhpqqJOyNgasT1ndfg JO85OzfZ5AS4lcr43c+fbTA9wGE3+WnMs8Cwyl6NuQ0Po15Z/vLj6LQS6YE2kypTltMR OMyo2pRj9HGKTXnfW7Ywj8nM0p3h+s6ka1POCm9cRfcd+LpqEM5a9/1cryW89FTu2lfc DopA==
X-Gm-Message-State: AOUpUlGZ1HKc/wH6rSITdnEBSHzXeJyCFXuRsMnp1RWn1jH7mYWYZCr2 jb1R2HV4VQLwt+perOkMAPHxUyohluekc4Vra83bPegUSlE=
X-Google-Smtp-Source: AA+uWPyuiEHhIyFFHpqoApmO/FANg+A5qMOZY4peyaly2dTmwNsrmmLq2fDSrJ8Nw2AikvQ1T4N1oIRdXL9m2sXwIRU=
X-Received: by 2002:a81:250a:: with SMTP id l10-v6mr25972526ywl.222.1534836602558; Tue, 21 Aug 2018 00:30:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:a045:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 00:30:01 -0700 (PDT)
In-Reply-To: <7050b6ed-6e99-314b-153a-f969288191e7@nic.cz>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk> <23C2BA0B-B4A7-49F2-9FFD-90B90E2928B5@bangj.com> <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org> <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com> <20180821014030.C2678AD6354@fafnir.remote.dragon.net> <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com> <5B7B7718.7090301@redbarn.org> <EEEB9610-FB85-475D-ACF4-8F07E9884D8D@bangj.com> <CAPt1N1k=xnSiF_DQXz6OS=MdRe5YHbL0CgXHAUdgWgH4vdBDMA@mail.gmail.com> <DA13BC82-2308-4B28-B86B-A52D678A1BFD@bangj.com> <252FC541-311D-4892-9F0D-B0D7BB2EEC2A@bangj.com> <7050b6ed-6e99-314b-153a-f969288191e7@nic.cz>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Tue, 21 Aug 2018 00:30:01 -0700
Message-ID: <CAC=TB10bYP2UPO9RPs6Tjm9OO_PTUcoQp=VNMLaBjb+mMoVxyw@mail.gmail.com>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m7c5iSBeyv5RzuPIy5EOHW3d850>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 07:30:06 -0000

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <petr.spacek@nic.cz> wrote:
> On 21.8.2018 04:38, Tom Pusateri wrote:
>> Come to think of it, DNSSEC validation in the stub resolver or browser
>> is really a place DoH could shine. Instead of all the round trips
>> required for validating up (down) the chain, the webserver could package
>> up all those validated records and push them so the client/stub could do
>> the validation quickly for all of the links in a page in an order that
>> the user is most likely to need based on previous statistics and
>> scrolling position.
>
> Could you elaborate how DOH helps here? I can't see it now.
>
> We already have RFC 7901 (Chain Query requests in DNS) which allows
> resolvers to get all RRs required for DNSSEC validation in one round
> trip even over "classic" DNS.
>
> This haven't been implemented because up to know browser vendors have
> not been interested in DNSSEC which consequently lead us (resolver
> vendors) to ignore complex RFC with no demand.
>
> >From my point of view DOH does not change anything in this regard,
> complexity on stub & resolver side is the same no matter what transport
> is used.
>
> What am I missing? How does DOH help with this complexity when compared
> to classical DNS?

I think Tom is referring to the h/2 push semantics. The resolver can
push the trust chain records
ahead of time, so the forwarder will already have them in cache when
revalidating the final answer.

> Petr Špaček  @  CZ.NIC
>
>
>> Tom
>>
>>> On Aug 20, 2018, at 10:31 PM, Tom Pusateri <pusateri@bangj.com
>>> <mailto:pusateri@bangj.com>> wrote:
>>>
>>> Sure. My point was that there could be legitimate uses of DoH.
>>>
>>> You have to move DNSSEC validation from the resolver to the client in
>>> order to really validate the answers if you can’t trust the resolver.
>>>
>>> Tom
>>>
>>>
>>>> On Aug 20, 2018, at 10:28 PM, Ted Lemon <mellon@fugue.com
>>>> <mailto:mellon@fugue.com>> wrote:
>>>>
>>>> Of course, the question is, how does the consumer of that data decide
>>>> what is okay and what's not?   We can't just say that the server has
>>>> to behave correctly: someone has to enforce it.
>>>>
>>>> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <pusateri@bangj.com
>>>> <mailto:pusateri@bangj.com>> wrote:
>>>>
>>>>
>>>>
>>>>     > On Aug 20, 2018, at 10:21 PM, Paul Vixie <paul@redbarn.org <mailto:paul@redbarn.org>> wrote:
>>>>     >
>>>>     >
>>>>     >
>>>>     > Tom Pusateri wrote:
>>>>     >> ... I don’t know if it’s generally accepted that DoH will replace
>>>>     >> UDP/53 or DoT in the stub resolver or DoH will just end up in the
>>>>     >> browsers as a way to speed up web pages. But if DoH stays in the
>>>>     >> browser and DoT is tried and used on all DNS servers, there’s not a
>>>>     >> problem to solve.
>>>>     >
>>>>     > if DOH is widely used by criminals, botnets, and malware to
>>>>     bypass perimeter security policy, then there will be a big
>>>>     problem and we will be solving it for many years to come, even if
>>>>     the browser is the only thing using it. browsers are where most
>>>>     modern vulns have occurred, and i expect that trend to
>>>>     accelerate. "because that's where the money was.”
>>>>
>>>>     I can see good use cases and bad ones.
>>>>
>>>>     If web servers did DNSSEC validation and only served addresses
>>>>     for names that were validated, I wouldn’t have a problem with
>>>>     that at all.
>>>>
>>>>     If web servers only served addresses for names within the domain
>>>>     of the web server, I wouldn’t have a problem with that either.
>>>>
>>>>     if they start serving non DNSSEC validated addresses for names
>>>>     outside their domain, I think they’re overreaching.
>>>>
>>>>     Tom
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop