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

Patrick McManus <pmcmanus@mozilla.com> Tue, 12 June 2018 01:06 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 ED8B6130EAB for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 18:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 X8c1HUC0c1OP for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 18:06:28 -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 2E8DF130DC3 for <doh@ietf.org>; Mon, 11 Jun 2018 18:06:28 -0700 (PDT)
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id A47DE3A03B for <doh@ietf.org>; Mon, 11 Jun 2018 21:06:27 -0400 (EDT)
Received: by mail-oi0-f52.google.com with SMTP id f79-v6so19599146oib.7 for <doh@ietf.org>; Mon, 11 Jun 2018 18:06:27 -0700 (PDT)
X-Gm-Message-State: APt69E3F4C/bH14ZMzvzn5OX5rOYl0iHIJX0f7zE04nVSlyjsNLnC1uv qDq7VoLDbTVOj+hVIvm3v8OMfdOrq7sk4BzTCus=
X-Google-Smtp-Source: ADUXVKKWzm25acj3Dz2bRZtig/otrwqKBbxoJ4OvQwWQ/1upwbzxAMnrhTibYisbpFAomTeqvVEPXNVhRwLHNiKCDcs=
X-Received: by 2002:aca:41d6:: with SMTP id o205-v6mr847202oia.38.1528765587384; Mon, 11 Jun 2018 18:06:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 18:06:26 -0700 (PDT)
In-Reply-To: <23326.61211.72657.945633@gro.dd.org>
References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 11 Jun 2018 18:06:26 -0700
X-Gmail-Original-Message-ID: <CAOdDvNq51daJive2OHaWTXQP619gf3xfitXzsFDGYONW9+So3g@mail.gmail.com>
Message-ID: <CAOdDvNq51daJive2OHaWTXQP619gf3xfitXzsFDGYONW9+So3g@mail.gmail.com>
To: Dave Lawrence <tale@dd.org>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7f273056e67799f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/zi6mkSsyE9QiZAIuAaIVl1lqVAc>
Subject: Re: [Doh] 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: Tue, 12 Jun 2018 01:06:30 -0000

On Mon, Jun 11, 2018 at 2:52 PM, Dave Lawrence <tale@dd.org>; wrote:

>
>
> If there were even one solid example of how this impacts the rest of
> the DNS, I'd certainly be willing to reconsider my position.


This is my position as well. I'm willing to make minor accommodations here
based on the use of a 2 byte message framing length when using wireformat
over TCP. I've concluded that is evidence that the wireformat is expected
to have no single message be more than 16 bits in length (TCP routinely
uses more than one message, and could have chosen a 32bit framing after
all). One of the things DoH does is define a media type for the classic
wireformat so it should be consistent with the classic definition of that..
unfortunately sometimes these things have to be reverse engineered and
ambiguity leads to disagreement.

However, the scope of that evidence is limited to a single wireformat
message. Its not limited to particularly query types, or alternative media
types, or multipart-schemes, etc..

And I
> can certainly see that consensus of the open source DNS community
> carries a lot of weight.  I just want it to be clear, for the list now
> and for the posterity of the archives, that if that's the way it goes
> then it was not a technical decision that drove it and it comes with
> its own set of consequences.
>
>
If it is not a technical decision, then it is not consensus. RFC 7282 is
pretty helpful in this regard. Obviously, there is still a generous dollop
of "technical is in the eye of the beholder".

But I'm hopeful we can come to a technical resolution - you're right imo to
keep pushing through the general concerns to get to specifics. That makes
it easier for everyone.

-Patrick