Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

Mukund Sivaraman <muks@mukund.org> Thu, 14 June 2018 04:22 UTC

Return-Path: <muks@mukund.org>
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 3DBB5131063 for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 21:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 keWDNSNp0rDH for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 21:22:28 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0213105D for <doh@ietf.org>; Wed, 13 Jun 2018 21:22:27 -0700 (PDT)
Received: from jurassic (unknown [49.203.216.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7D6D132C09D5; Thu, 14 Jun 2018 04:22:25 +0000 (UTC)
Date: Thu, 14 Jun 2018 09:52:17 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Petr Špaček <petr.spacek@nic.cz>, DoH WG <doh@ietf.org>
Message-ID: <20180614042217.GA25915@jurassic>
References: <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com> <20180613192030.GA2792@jurassic> <CAHbrMsACdaz13v=2jbpZq1RU-_CP36Cgz13iFFWVj8qrjQ0b=g@mail.gmail.com> <20180613205637.GA23215@jurassic> <CAOdDvNr0ob_zhMw1BT_h8n77ecx5vht8WJ7OiwwDPrj0Wxf8SA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOdDvNr0ob_zhMw1BT_h8n77ecx5vht8WJ7OiwwDPrj0Wxf8SA@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/sMQtV1ztqY6gRw3g9zOnYJOlm0M>
Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 14 Jun 2018 04:22:31 -0000

Hi Patrick

On Wed, Jun 13, 2018 at 02:59:01PM -0700, Patrick McManus wrote:
> > DoH is not even an RFC yet and there has been an announcement from
> > Mozilla that by default all its DNS queries will be sent to Cloudflare
> > via DoH, and this is the default behavior that's all within the Firefox
> > application. Is anybody else concerned about the Firefox DoH
> > announcement?
> >
> >
> You are overstating the announcement greatly. We're running some fairly
> small experiments to see how this works. It has gotten a bit more publicity
> than something at this scale normally does because its important to let
> impacted users know how their data flow is changing - that's all. I hope it
> makes for a better protocol.
> 
> This is part of the process of data driven decision making. sometimes known
> as running  code - and it makes for successful protocols when the IETF does
> it right. I'm happy to say that open standards are an important part of our
> mission and we're confident that we won't accidentally create defacto
> standards from Internet Drafts - that's something we think carefully about
> and have done well managing with HTTP and TLS over the last few years (of
> which we have shipped dozes on draft versions to much bigger populations in
> service of creating the final consensus product) and I'm confident we'll be
> fine aligning with the final DoH as well.
> 
> on the other hand, as I've told the HTTP WG on many occasions: this forum
> is for open standards, its not the room I make product specific decisions
> in (nor would I expect other participants to negotiate their product
> decisions with me).

The questions aren't about Firefox explaining its decision or its usage
of protocol. The questions are about DoH enabling this, what its purpose
is. Until this announcement, I used to view DoH as a way to make DNS
service available where existing secure stub->resolver protocols such as
DNS over TLS and dnscrypt don't work. It seems DoH may be used as the
means to bypass traditional DNS completely, where answers are not
obtained via the system configuration of stub. It may be justified (and
surely this is possible using traditional DNS as well), but let's see
some descriptions of how DoH is expected to be used. On re-reading the
charter, it appears someone had thought about all this which isn't
apparent on a naive reading.

It would help participation, get to more consensus if the usage patterns
are better understood.

		Mukund