IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 02:35 UTC

Return-Path: <mellon@fugue.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 CA09A130DF6 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=fugue-com.20150623.gappssmtp.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 TuQKz6pWgUJv for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:35:23 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 148C3130E02 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:35:23 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id h20-v6so2212495itf.2 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BtU5Ttdjb04cNtw6sguvbFTt9gcEWQHv2NM4LJvfdzo=; b=rtIwdzOTLob8Zvg50Zd1/+5yqqzogFr718/dRm5/Bj9h2Hz0XmE7XV1NcSowBnfmOA TMHELxiPIDzlJTo+NJzYn5cQ7avnNaL7OMXcg8iovrxr7FYw1U63RhhK1bHFa6J8RPoe jCsoaisdQS0+3C2tA+c70/zM6ZwAMBAvFeZwwB3ryF2EXgFWyMWa5GYAbevRpK14qiZL YY7ZQHNO/6c8jnD8Mei4UHa/p+GeCnpQkGFgrCquKBiFQ7Pq2kg9u2Q5eY7pnnUWEAQm 4fcFhPGw3e45N3X4ZeT/GDPvrqAQo+Ab5uNht9VuJTW/pMrzMUxiUzNIb3eCsnejcoVm aBog==
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=BtU5Ttdjb04cNtw6sguvbFTt9gcEWQHv2NM4LJvfdzo=; b=Iap/0Cq87efgdsoxfwcriDsE3BJ/rI0dzTA4i78hTXwsap25zRPpjme1jGQk1vbF+1 oQMt2BfawVYmKgPoWMh3REYjkjgSSkEHe0ci0oaYDuCYEYaErLvaJBhFq2w2r4kQIwvb O14atIBcaioBRjuyRZ5rrFbGGLc3z+FfIS+80KkK5nYKjFHoH3/s9Hid99zTwO6Mc9Br k839FPVBHv11v8Gv0QSbzTf+6+innhvR1yd1/3myDYddTrJDCw0+C6EeeAzUph/gf7ND tcArCoPQj/oK2eByHXIZ0HxcGYrT7QvAwc51vNmpcaXDcvPqvT71oFbUMe0XowypN2Jy 8Ztw==
X-Gm-Message-State: AOUpUlE1VES8CroUDcVcyOTfHSxTEAL8z8OZMD8Z9wkQomUuTrgv7nAg 8OdSh623ECTT+Cu7WDi5WDs/ubtl6EKOihT2Cpxw1Q==
X-Google-Smtp-Source: AA+uWPzAUYiq3KL+MXhUNghQMRlev2t3bkkw5OTGNvWOy/FYUBM/eUfpKwE8pBbBQMr0FEONAtlxmZHtqZbEjYot6V8=
X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr36516067itb.95.1534818922355; Mon, 20 Aug 2018 19:35:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 19:34:41 -0700 (PDT)
In-Reply-To: <DA13BC82-2308-4B28-B86B-A52D678A1BFD@bangj.com>
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>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 20 Aug 2018 22:34:41 -0400
Message-ID: <CAPt1N1nOR+epq8SsNNiZ4_vHjcWK6oFYdoXnMch43Y2F8PD2sQ@mail.gmail.com>
To: Tom Pusateri <pusateri@bangj.com>
Cc: Paul Vixie <paul@redbarn.org>, Paul Ebersman <list-dnsop@dragon.net>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a974260573e8e017"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8NNCzDAKYJC4L8kjVBTQK7WpTrQ>
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 02:35:25 -0000

I agree.   We should write down the advice that we think users and
implementors of DoH need.  :)

On Mon, Aug 20, 2018 at 10:31 PM, Tom Pusateri <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> 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> wrote:
>
>>
>>
>> > On Aug 20, 2018, at 10:21 PM, Paul Vixie <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
>>
>
>
>

v2.28.0 | Report a Bug | By Email | System Status