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

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 17:08 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 B60D1130E4D for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 10:08:21 -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 dbu5xlgwAgN3 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 10:08:19 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 BA6AD130E4A for <dnsop@ietf.org>; Sun, 19 Aug 2018 10:08:18 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id n18-v6so10748685ioa.9 for <dnsop@ietf.org>; Sun, 19 Aug 2018 10:08:18 -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=/elsQfmJO8x1yJHCAm2st0+AX+AZ7x+mAxylkLctmqQ=; b=oq0eFq+ksdBNBWixavFJXkYmgGTVLlsGJdTV0Fc97bzuKcFjGxjZTCN3du6MsMbHai 1f0QUH3/6ul1sJZP33jsnXjaGORawVNyuj6ESDv+IdzTsI8Pw6sUg3SBUA3SmKudBdPj 6iUk78gm5YsDDWe07FuJGn9fRG8w0ey7eHZBXnazmDE9ROBUjKjFnz/Rt0qUTEzVDtDR qMeBOTYEkNVYR4WAHV1y1L9DbI1qwGrPcFXMr8Q9OPnBKIDNb15jvTV5J9fC6DUM0p67 Li1mRkbZy1RtsWXPgqpvysSL++2aKKwwEe+6ffkHmEQkaoz/MmWkgBgsB7aZUe7F7QoG BXzg==
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=/elsQfmJO8x1yJHCAm2st0+AX+AZ7x+mAxylkLctmqQ=; b=mdYRMLpwSFzQhiGMp/PFE9d52o5uWIEMN015uMNToEbufoq0ebvbnqBOh2UohZbE9U lfloEh2dpKYjrnq76DHbrUpwGgsdhLkVC26114X9KCmjNNpgvGYyo5w54Wqa8HGF18Gv 1N+GXHUCmuCMgFQMY69/1Pi/0iZnVapNBulQd1zI9w2/Nlw4ee8CnjSYbIdR/kDcI2tB EmtqxIMFQqAG5ExXzIHKYBlUSfhQu4y0lDAGQ7FlcxKFLJ0AFvwJHP43xQycoUk+xtPA 1yPd7ID9ySsNTgcAkBR+0BoTQNc513je1UsTWzr+bHzCFd0/VDm0KKK9LbFIicduLZ4R uxsA==
X-Gm-Message-State: AOUpUlG4otk62xeFboORwGFmjjj8aNptJlNTX7720DxxqW+oAv8Hr/ZM CIwZGxvlaNAhUnRdRRFbYzJXWbDD6X9G+vTLevu7QSt8
X-Google-Smtp-Source: AA+uWPzqqxg4mOKanig9P/brKFM3iREGIOMdvzlUvq+IvOITXxEXi7dgAzllPZZ93O6BgrC9hYKFYaM7wkobr4M8fyo=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr35669889ioc.45.1534698497921; Sun, 19 Aug 2018 10:08:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:07:37 -0700 (PDT)
In-Reply-To: <53074d98-a8ef-9127-edc7-d3e3188c2453@dougbarton.us>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <CAPt1N1nEH86yPvtoNqJ+xM-OFunEqr2x8s2LV_yFU1fkVt9WUQ@mail.gmail.com> <53074d98-a8ef-9127-edc7-d3e3188c2453@dougbarton.us>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 19 Aug 2018 13:07:37 -0400
Message-ID: <CAPt1N1muo07jvDmyM+oL96Ow1RXGcsgVKX51S86CUcedirzvew@mail.gmail.com>
To: Doug Barton <dougb@dougbarton.us>
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce73950573ccd6c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ubaA_DcJCyHjGvzHZW1kSZKjvEM>
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: Sun, 19 Aug 2018 17:08:22 -0000

I went over this in some detail a while back, but to recap, the point of
something like DoH or DoT is to protect the client from eavesdropping.
 There are three senses in which this can be useful.

   - First, that there is a trust relationship between the client and the
   server, which is validated using PKI.   This trust relationship prevents
   anyone other than the trusted server from seeing the client's queries.
   - Second, that the client just wants protection from eavesdropping on
   the local wire, and doesn't actually trust the network operator, but uses
   the provided DoT or DoH information because it protects from third party
   eavesdroppers.
   - Third, the client has a trust relationship with the provider because
   the provider of the client software configured it that way.

What's important about this is that the first and second types of trust
relationships are mutually exclusive.   If you have the first, that
precludes the second.   You have to pick which one you want.   The third is
essentially a special case of the first, but I mention it because people
tend to describe them as if they are different.

So if you are relying on the first kind of trust relationship, then you
can't use DHCP, because you have no trust relationship with DHCP.  If you
are relying on the second trust relationship, you are assuming that the
network operator is competent; otherwise a third party can still eavesdrop
on your traffic by providing DHCP service on the local wire.   Paul and
Bert have talked about why the third kind of trust relationship is
problematic.

So you have trust relationship one, which has the problems Paul talks
about.   You have trust relationship two, which has a different set of
problems, and is incompatible with trust relationship one.   And you have
trust relationship three, which is a special case of trust relationship one.

The DHCP solution is compatible only with trust relationship two.   So if
the IETF were to recommend this way of configuring DoH and DoT, we would
essentially be throwing away the privacy benefits of DoH and DoT (assuming
that such benefits exist).   Paul states this as if it's just obvious that
when you are connected to a particular network, you have to follow the
rules of that network, but this is kind of a special-case argument: Paul
runs his network that way, and he gave some examples of other networks that
are run that way, but there are also lots of networks that aren't run that
way, and as an end user who owns his device and does not live in a country
that censors the Internet, I am not willing to have the internet censorship
case be the default case.   If a device were to treat that as the default
case, I would not want to use that device.

I will freely admit that this is not clear-cut, but that's really my
point.   I believe that it is wrong to advance a DHCP-based solution
without consensus that we prefer the second trust model, and I don't think
such a consensus is attainable.   Pursuing a DHCP-based solution without
that consensus is simply a way of bypassing the consensus process, in the
sense of deciding that there is no need to get consensus on which trust
model we prefer before choosing a trust model.

On Sun, Aug 19, 2018 at 12:43 PM, Doug Barton <dougb@dougbarton.us> wrote:

> On 08/18/2018 06:08 PM, Ted Lemon wrote:
>
>> The thing is that most devices don't connect to just one network.   So
>> while your devices on your network can certainly trust port 853 on your
>> network, when they roam to other networks, they have no reason to trust
>> it.   If you have devices that never roam to other networks, that's fine,
>> but we have to design for the more general case.   There's no way with DHCP
>> for the device to tell that it's connected to a particular network, other
>> than matching IP addresses, which isn't a great idea.
>>
>
> Ted,
>
> I'd like to turn your question back to you. What threat model are you
> protecting the user from by not allowing a DHCP option to use a DOH or DOT
> server?
>
> It seems to me that in the overwhelming majority of cases (near 100%) the
> user is going to get their local resolver from the DHCP server, whether
> they are on a trusted network (like work or home), or roaming at Eve's
> Coffee Shop.
>
> So either you have a sophisticated user who has preconfigured their own
> resolver and ignores the DHCP setting, or you have the typical user who
> doesn't understand how any of this stuff works, and therefore has implicit
> "trust" regarding the local network and the settings from the DHCP server.
>
> Given that (and feel free to tell me if I've missed something), what harm
> can come to the user if the resolver that they are already trusting can
> also be accessed over DOH or DOT?
>
> Doug
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>