[Doh] DNS Camel thoughts: TC and message size

Patrick McManus <pmcmanus@mozilla.com> Fri, 08 June 2018 12:41 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 63381124D68 for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 05:41:36 -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 zaGFd0EjDlEc for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 05:41:34 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2512872C for <doh@ietf.org>; Fri, 8 Jun 2018 05:41:34 -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 6113C3A08D for <doh@ietf.org>; Fri, 8 Jun 2018 08:41:33 -0400 (EDT)
Received: by mail-ot0-f176.google.com with SMTP id q17-v6so15512432otg.2 for <doh@ietf.org>; Fri, 08 Jun 2018 05:41:33 -0700 (PDT)
X-Gm-Message-State: APt69E2aUtTI0PUIARAUn02iT37TWtiifTDF76tTnRa7NpZXcwoNyWEf kecM1FxqOGAaSfZjazY7E0fvGNf2EVpyfhQP57Y=
X-Google-Smtp-Source: ADUXVKIJScu9S+me1QTexs11WBoVErPBLMTChxqFbiWF4cxdHoIwDKfpJgbKEqTBNQAdIptX8GFM4jbZtCml/nntly8=
X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr3325860otb.214.1528461693038; Fri, 08 Jun 2018 05:41:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 05:41:32 -0700 (PDT)
In-Reply-To: <c0b0ca9b-4d55-27e3-fa52-754e96b3e70f@o2.pl>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <CAOdDvNq9g3ghbg9fkfhP+ZA4-6E5oDNFCGo6NN9bydqUX76cLA@mail.gmail.com> <20180607093647.GB32326@server.ds9a.nl> <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org> <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com> <20180607215851.GA32738@server.ds9a.nl> <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com> <20180608101102.GA12334@jurassic> <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> <c0b0ca9b-4d55-27e3-fa52-754e96b3e70f@o2.pl>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 8 Jun 2018 14:41:32 +0200
X-Gmail-Original-Message-ID: <CAOdDvNrLX5eyLPQ13QbXaxSY0=jL04yNPF4Ba3U6EPTDxi9neQ@mail.gmail.com>
Message-ID: <CAOdDvNrLX5eyLPQ13QbXaxSY0=jL04yNPF4Ba3U6EPTDxi9neQ@mail.gmail.com>
To: Mukund Sivaraman <muks@mukund.org>
Cc: Patrick McManus <pmcmanus@mozilla.com>, bert hubert <bert.hubert@powerdns.com>, DoH WG <doh@ietf.org>, Dave Lawrence <tale@dd.org>
Content-Type: multipart/alternative; boundary="00000000000044389e056e20b862"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/RzkRt8DzAjzGrsj_qE9_qqHLmkQ>
Subject: [Doh] 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: Fri, 08 Jun 2018 12:41:37 -0000

On Friday, June 8, 2018, Mukund Sivaraman <muks@mukund.org>; wrote:

> On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote:
> > I'm not on board with limiting a 2018 protocol to 64KB variants because
> > some parser of some some format might have a bug.
>
> It's not "some parser".. for a long time implementations have assumed
> 64kB for message formats and these are implicit assumptions.


Perhaps you feel I was being dismissive - I'm genuinely sorry about that. I
was really trying to ask for specificity. If we understand the scope of the
issue we can then deal with it on a corresponding scope.

I mostly hear general appeals that concern how different implementations
might (without citation) struggle with >64KB wireformat messages because
they were unanticipated and a subsequent request to ban them from all media
types as a result.  I also hear some disagreement that >64KB wireformat is
even a problem. I'm pushing back because the size of the hammer needs more
justification from particular instances of the problem.

I don't deny the possible existence of a legacy problem - I'm asking for
details about it and then we can analyze how those messages will get into
the hands of those implementations.. that will drive next steps

There are a few options here.. sorted roughly on a spectrum from a] do
nothing, b] non-normative there be dragons here text, c] wireformat
specific text that clarifies it already has a 64KB limit, d] restrict all
DoH content-type variants (even non wireformat ones) to 64KB.

If the problem were laid out in specifics, we could more meaningfully
figure out where to be on that spectrum instead of just staking out either
end.

As for justifying longer representations there are two angles to consider..
one is specific use cases, the other is the general architectural
consideration that arbitrary limits come back to bite you later on
(rejecting 640KB is enough for anybody as Bert put it.). Its ok if DoH
enables some use cases that will only be used natively - it is not a mere
tunnel.

wrt use cases, I've spoken about JSON at the last-call level, and other
JSON formats in the works. I also think key management could become an
issue - lots of things are interested in storing public keys in DNS
(including but not limited to dnssec) - post quantum those keys necessarily
explode in size. And of course zone transfers are related large objects too.

Cheerfully,
Patrick