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

Marek Vavruša <mvavrusa@cloudflare.com> Sun, 19 August 2018 00:53 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 AA0ED130F6A for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 17:53:12 -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 XxvVMS1J5PDj for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 17:53:10 -0700 (PDT)
Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 A51CB130F32 for <dnsop@ietf.org>; Sat, 18 Aug 2018 17:53:10 -0700 (PDT)
Received: by mail-yw1-xc35.google.com with SMTP id w76-v6so5713771ywg.4 for <dnsop@ietf.org>; Sat, 18 Aug 2018 17:53:10 -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=dkhGs4py9h64DXTjSXthrVPDuW3HDDu4wZWVv7ArKOk=; b=sfZzF/f3L8DJ5GzpbVlt4RSd/nFBeOIIFTcl7Y903Osa+luzS5P9YWGUhoBFiyAbK2 E2LFFIyC3Uqm4KiGes1zSRo2MFDU3JLJCh0T2t6FJ08XEJRugzpcWBgsOyghbhDOvpGN QRRzshk6FgZkZ+eaoiTJaMo81lQ454cCiiCs8=
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=dkhGs4py9h64DXTjSXthrVPDuW3HDDu4wZWVv7ArKOk=; b=qztO5lQGe9o6bNOwB0kPhvzGbtDXKjZXOlgsxW4dv18RN1RM1cl2Y3oqDZlbnbfGU6 Aoz5i4+1JSrnzaYGIy5zc+RN+Y3s0+ZuCMIrugNN2TyV+nwzYE1W5n+cHTjIdNNh/UF0 t1AsjFyPawTCiKQBM24qVDeCBgalacaXDMc8pUM1iSDMhiFyB4rJijFm07HwRyi4G6hk 8zSS6tmwOvps7wbA3mxQOpL8fxwHGZgNmEABbxA626GWVO1KyH72xAvoTUJdqKALKJBy wkcxLQHPb8JU0PyWPg8N+hhwQN1z4gebGOfgocvi7ZpiNA5kO3Q9b4tl02k9IWIoEU6O kW2g==
X-Gm-Message-State: AOUpUlFPqD0CZHzZleLVWLKmByOn0lgsvFTrxgrKAS9jYpnkSd7TiJmn SB2Y33J+d45mEq2X9eqdp0AYL9CP+uPmFPjajWG6dg==
X-Google-Smtp-Source: AA+uWPxVickMPkp2kEvktNDMy7mt7sALX1MF3QuQxxnWvlA5Oh3QjTqFsTPqXsmfNChaHcuLt55Y7ItV047jQ9scUlQ=
X-Received: by 2002:a81:5009:: with SMTP id e9-v6mr23051703ywb.128.1534639989934; Sat, 18 Aug 2018 17:53:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:53:09 -0700 (PDT)
In-Reply-To: <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com>
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>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Sat, 18 Aug 2018 17:53:09 -0700
Message-ID: <CAC=TB10Nfp0r=-vWx1cr9Fo22LAGHev9Fqi5ZMSCOpOw-56Zcw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
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/UgkahdIU-pa9JGOVV0H16crMoSU>
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 00:53:13 -0000

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <mellon@fugue.com> wrote:
> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <mvavrusa@cloudflare.com>
> wrote:
>>
>> > You say that your proposal does not impact DoT's ability to address the
>> > threat model or use case that is the reason it is being used.   But this
>> > is
>> > doesn't make sense to me.   The trust model for DoT and DoH right now is
>> > that they are configured by the user for the user's reasons, or by the
>> > service provider for the service provider's reasons.   You are proposing
>>
>> This is the issue that the draft is trying to solve. The service
>> provider doesn't have a way
>> to configure DoT on the stub resolver. This problem is described in
>> https://tools.ietf.org/html/rfc8310#section-6.7
>> What I'm trying to address more specifically is
>> https://tools.ietf.org/html/rfc8310#section-7.3
>
>
>  The document explicitly says that it doesn't have a trust model for DHCP.
>>
>>
>> The "DHCP authentication" does exist, I believe you're referring the
>> deployment status.
>
>
> No, I'm referring to it doesn't exist.   There is no deployable DHCP
> authentication.   The DHC working group tried to come up with one, and
> ultimately concluded that it was not worth it, because the only thing that
> should ever be trusted from a DHCP server is information about the local
> network.   DoH and DoT are out of scope for DHCP according to this
> reasoning.   Bear in mind that we were more optimistic about authentication
> when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
> RFC3315, is not as optimistic, and only provides for authentication using
> IPsec between server and relay, and authentication for the purpose of doing
> Reconfigure; this authentication is not sufficient to provide assurances of
> trustworthiness.   It's about as secure as a TCP sequence number.
>
>>
>> I'm happy if we say the draft must depend on RFC3315, or discuss the
>> trustworthiness of the responses,
>> but surely there must be a way forward if we want to keep the
>> recursive DNS (last mile) decentralized and free from tampering.
>
>
> There is a way forward: seriously figure out the threat model.   Tom
> Pusateri and another author already did a DHCP document; the reason we
> didn't advance it is that we weren't able to come up with a threat model
> where configuring DoT or DoH made sense.   Until someone does that, there is
> no point in doing further work on a DHCP option.   If we do do further work
> on a DHCP option, Tom's document is more complete than yours.

Can you share the link for the draft for a reference?

Marek