Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2)

Patrick McManus <pmcmanus@mozilla.com> Tue, 29 May 2018 01:30 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD812E86E for <doh@ietfa.amsl.com>; Mon, 28 May 2018 18:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 3lipBRSY6Pe5 for <doh@ietfa.amsl.com>; Mon, 28 May 2018 18:30:45 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE612E88F for <doh@ietf.org>; Mon, 28 May 2018 18:30:45 -0700 (PDT)
Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 681FE3A024 for <doh@ietf.org>; Mon, 28 May 2018 21:30:42 -0400 (EDT)
Received: by mail-ot0-f176.google.com with SMTP id g7-v6so15180989otj.11 for <doh@ietf.org>; Mon, 28 May 2018 18:30:42 -0700 (PDT)
X-Gm-Message-State: ALKqPwebfQvQwK3r1dNxoybV9ImLPv4rSDq4d5Mn3pPWw9QQTaQt10g0 DLLYZGVSj8swsweW1MQ0O+6inspJkmtRpXg0Iec=
X-Google-Smtp-Source: ADUXVKJEIfy9KmR35yhguaVr5DdVcO3LSCICjnD5mwb/kn2AITBhhGy9ERAhqZ9EYCfAlB4MbWbK1K18pFU/RhYImkM=
X-Received: by 2002:a9d:5014:: with SMTP id a20-v6mr9320223oth.205.1527557442138; Mon, 28 May 2018 18:30:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Mon, 28 May 2018 18:30:41 -0700 (PDT)
In-Reply-To: <CABkgnnV3kKFCzKLfPf_0WZh95jr2vEt652Rb4EozfqROCVsJdA@mail.gmail.com>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <CAOdDvNrpLwF5jpn1YA4-HXsfGxVkdds+xHVd6Bxy0Ux+3nrcrA@mail.gmail.com> <CA9BEE64-9F16-4CCC-A1E0-4C7FD45C455C@icann.org> <20180528161043.GB12038@mx4.yitter.info> <CABkgnnV3kKFCzKLfPf_0WZh95jr2vEt652Rb4EozfqROCVsJdA@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 28 May 2018 21:30:41 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrPU9WM3WgcX1AVF39D3bGdxCKgPAF_afhfv2Qt0pZR5g@mail.gmail.com>
Message-ID: <CAOdDvNrPU9WM3WgcX1AVF39D3bGdxCKgPAF_afhfv2Qt0pZR5g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: DoH WG <doh@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="000000000000b67580056d4e2e48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/WtYmxdOPwRyds9HKb1ufgVJNmvg>
Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 01:30:48 -0000

>
>
> If we change the text, I think that we could avoid the MUST and say that
> this document assumes that DNS API clients configure a single DNS API
> server and do not send queries to, or accept answers from, other servers.
>

 I don't think 'single' is the operative part there - and I don't think the
document assumes that beyond a single request needing a single URI. But,
yes, its the "others" that it is looking to exclude.

I also think you're right to imply that we have a tension here between what
we want to exclude now (stumbling across websites offering to be
recursives) and what we want to enable exploring later (stumbling across
websites offering to be recursives :)) in a more comprehensive manor. I'll
offer up some text inspired by 7540's handling of client certs which has a
somewhat similar profile.

This might not be hard to solve - the section is really just using
configuration and trust synonymously and a bit redundanty, but people are
reading more into trust. So perhaps we can just use one term. wdyt of:

"A DNS API client uses configuration to select the URI, and thus the DNS
API server, used for resolution. [RFC2818] defines how HTTPS verifies the
server's identity.

A client MUST NOT use a different URI simply because it was discovered
outside of configuration. Specifically, this specification does not extend
DNS resolution privileges to URIs that are not recognized by the DNS API
client as configured URIs. A future specification may support this case."