Re: [Add] Foundational questions on draft-box-add-requirements

Eric Orth <ericorth@google.com> Tue, 08 September 2020 18:27 UTC

Return-Path: <ericorth@google.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6A3A0C37 for <add@ietfa.amsl.com>; Tue, 8 Sep 2020 11:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r2do4aYeL_FF for <add@ietfa.amsl.com>; Tue, 8 Sep 2020 11:27:17 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4AD473A0C34 for <add@ietf.org>; Tue, 8 Sep 2020 11:27:17 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id b79so305111wmb.4 for <add@ietf.org>; Tue, 08 Sep 2020 11:27:17 -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=7Hcx6kH/MPntdvwiMHA8J2MNTCmerJ53WvNxsfl8nfY=; b=mGX+FVQE5ri32o3VykXvsop/Ms3K3xBBTRZeCFyAYRm2TTBWp7sU9yNDWVKQa0ot6w jpbfCzSI9+Wjd2iC+ep2WZs66qn0qgb6xzXXUfuxwZ84/Tamw7dGg0OnPtJmlGKfKJVN 7/J+fDkQLnnXcnAxn5+v4pTXUhpD25cjejqFxsyFBid8Y0VMTQRQtnvdtbNpHbz3YLMn AOlT89mGWk2rnBWTHOmEfxF8s2hGBsk2VG3f5bMi0xg57d1DbxuakX+IJzG2pPCtn3od Zv80fBCI6MJlP67VDxwRdwDEtfhhcFk6rTzXaM/aQV46SNBMLKGSROMKi6q99ySsKlX/ Usxw==
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=7Hcx6kH/MPntdvwiMHA8J2MNTCmerJ53WvNxsfl8nfY=; b=gxI78TTrp7Wosndh7q47P61j5IXVF5y/9hXtxFYgLMaUbLY2ceK/AS4DdEzeL+STr+ bkDWupIb9e5T6BrlRbuCHmLjI2B3mGfhoUDGghlEY4ecF2WBIcikPdXtBJjPcLA/irjN F82g1QoM/8LYdXQVW8s2HQqkMKb+GXdqh546c/VUDX62nTjRKXVTLR8UH1WfH59sWeqK 0PaedaLdzwC/91pKUunU2SCQCNunT/2r2xMQVCIY0rFrcYb7uozFbmK+w44ej/UVkMv9 ioAMiRDl8RCpw/+ywFKaHRQ62Fs2p+xKWwLc8y38IirpUDQBNVf/hkugQTav84RVhiW3 v7kA==
X-Gm-Message-State: AOAM533aBgKRJuMEFUMOXpzi9Bzt+LMt90obID20QlfgETsfsZnYDigg 5t+Q+1ZZxGthSTlXYZ/5XWm5tEY5WwJEMX8KlmTo9Y/ndayUug==
X-Google-Smtp-Source: ABdhPJyt86ske1R+VyZ8OTDAK044VSn0frFfA10bEQTPFuiQr1BYC0iM+B8u5fLbsnonpm+HA8PneUAPg0U3QglmEss=
X-Received: by 2002:a1c:f003:: with SMTP id a3mr403893wmb.170.1599589635500; Tue, 08 Sep 2020 11:27:15 -0700 (PDT)
MIME-Version: 1.0
References: <DA10F3E4-7186-47E1-8B75-DCCAE107F880@icann.org> <CAMOjQcFd-yHDCB7K1ksCtUc1ufuk5M+05SHOL_Dr+s=A=Ka4+A@mail.gmail.com> <CABcZeBNFMxQ5AWV+FfAdmfnsJ1=fzx9BBtm6TVVw77MsoVKe3Q@mail.gmail.com>
In-Reply-To: <CABcZeBNFMxQ5AWV+FfAdmfnsJ1=fzx9BBtm6TVVw77MsoVKe3Q@mail.gmail.com>
From: Eric Orth <ericorth@google.com>
Date: Tue, 08 Sep 2020 14:27:04 -0400
Message-ID: <CAMOjQcFhcXxkqEWo-QMGnCx++6nfJoaTv2MK2p4njLgJMreQAA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003119205aed17ca7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/_EQGJmz8OLVWmlTlt-ixWU9hBrk>
Subject: Re: [Add] Foundational questions on draft-box-add-requirements
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 18:27:19 -0000

On Tue, Sep 8, 2020 at 2:04 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Tue, Sep 8, 2020 at 11:00 AM Eric Orth <ericorth=
> 40google.com@dmarc.ietf.org> wrote:
>
>>
>> On Tue, Sep 8, 2020 at 1:22 PM Paul Hoffman <paul.hoffman@icann.org>
>> wrote:
>>
>>> 2) Why must the associated resolver be operated by the same entity? If
>>> an ISP offers only unencrypted resolvers, but is happy to point its
>>> customers to resolvers operated by someone else (such as a public resolver)
>>> for when they want encryption, why should this document prohibit that?
>>>
>>
>> I think many clients are mostly interested in a "same-provider" upgrade,
>> but I think you make a good point that maybe the draft shouldn't be
>> mandating anything around that.  It's encroaching into policy.
>>
>> Maybe we just need a flag to specify whether or not a listed resolver is
>> run by the same entity and let clients make decisions about it.  Would that
>> be useful without a mechanism to enforce truthfulness of the flag? Maybe
>> fine since you're already placing plenty of trust in the initial resolver.
>>
>
> I would say technically you're placing trust in the mechanism that told
> you about that resolver. Consider the case where I have configured my
> resolver (via resolv.conf or whatever) to be 1.1.1.1. With a mechanism such
> as the one that MSFT (and I believe Chrome) uses, I would automatically be
> upgraded to Do[HT] regardless of the configuration of my local network.
>

Correct for Chrome.  If 1.1.1.1 is configured, DoH will be attempted to
https://chrome.cloudflare-dns.com/dns-query.


> However, if I were to ask the resolver who operated it over Do53 that
> would require me to trust the local network, no?
>

Maybe you could ask the target DoH server if it has the same operator as
the original Do53 address.  Has the advantage that the DoH server is at
least an authenticated connection.  But that's not giving much protection
if you didn't have a mechanism to prevent a network attacker from just
sending you to an attacker-controlled DoH server to start with.