Re: [Doh] DoH client-server interoperability vs. strict HTTP parameter checking

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Thu, 06 June 2019 17:14 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 08D4312007A for <doh@ietfa.amsl.com>; Thu, 6 Jun 2019 10:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.018
X-Spam-Level:
X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 eFpabUkVu2Qz for <doh@ietfa.amsl.com>; Thu, 6 Jun 2019 10:14:24 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A812F12000F for <doh@ietf.org>; Thu, 6 Jun 2019 10:14:23 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b756:9493:6736:2f05] (unknown [IPv6:2001:1488:fffe:6:b756:9493:6736:2f05]) by mail.nic.cz (Postfix) with ESMTPSA id 5F53C651E0; Thu, 6 Jun 2019 19:14:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1559841261; bh=F2IzNQzRHuTRv5dYPzJXHGJWvd2HhGdzgtzEqTk3uog=; h=From:To:Date; b=amb6ybEm6qPVxEQffWXjyAb5fJBbeqjuuf8KnqiopXMtBMzCFvKiX3q/PNwTzLXW4 5uPcHn0Ap/ZuKrNT4gceA5Ng/Y0jDM0A4TGqEUpAZ1NNymYFACv9skBZpK+97IDXJ/ NoI/Dkodo/WKw8ECQuKJxqw6UvXS/1cIwvWYc4iI=
Cc: Paul Hoffman <paul.hoffman@icann.org>, Christoph <cm@appliedprivacy.net>, Patrick McManus <mcmanus@ducksong.com>, Mark Delany <d5e@xray.emu.st>, Joe Abley <jabley@hopcount.ca>
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtDBWbGFkaW3DrXIg xIx1bsOhdCAod29yaykgPHZsYWRpbWlyLmN1bmF0QG5pYy5jej6JAlQEEwEIAD4CGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w 3gAKCRDnR98flXWjqmD6D/96U4cDZBrHQ5LhqybocZr/N2IS5Wr2SLLB4k2F5/W/wbL05gq6 Ha9/2TMqXoxRkhug+EAHFHxylPR43yN9rz0pjBXHrra87FAPHMqq/qqrOEUdhkytEqa6WIho aoEkdhaMhUyctjVjL2WZ0+MWeRjqedLQX+VCrOVPcVbLreRRhA9N3KPgNwbp9zCg6hEPi4l2 zZKedHkTNjKIAwJ0xZoMwFa1Y+vL8Em8Or+IBZuGBMP/ZMtasPOIQaT/Gvsyx1DDorwsoCdX 6zaTZy5DOWP3FIrMzus/YDbzwAYxSpWk/jF44ySbnJzdjU67EfG3UrsK+RRGw8aJqs3/4qHK ZMZZnNL+4wJpEdnZyFic/MXcw6FBszQEwrIOaM1WEfwzn2ExUYk2pM5zaBwq76OgrmGMzMEi cfMDyqLodwEQqR70PvRbkrh+R02LphwQ9c5AFXcrLjKMmeQlbQVarTUsrELcTK6rElC1ojS7 M37j0XzFE+kgNWn2fyBRgtnGDWEa7r+oDaueXJnEf0/4Ww28IwxakNc7r0N41GIBekwSxKdk epKFZgtVGGSDlFei5hb5LLWFljA1OS7CRVJKpbHafQjdPdb1vNqZAj4y2SJXvVVpI1KO5kq+ dFdYipORv0N2Iho6MNYbQUT1EBeU46G5N0viCoLS15/PxLhIAo+PzKpW97kCDQRYA5J2ARAA yHww3huLEtsdyqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zx x85WcuaO1OVqung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPp DkGodS0De9osA+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOo jGMiLoZvELY86Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxM t5LB/MSrmECB5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoR bh7i4fT0lWvMXTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJ V7xVLTtS1EamVqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p 02oSecDl5yVXplJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGX M71OpmONQJGF24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0 Q2zochS64Mcg0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYB gAAKCRDnR98flXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw 9SLUt7OGuUnIpKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrie b6iPjvAARXJCPTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTj xZzmGgvNSi6JDlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJi ba7iFPcGwcClCSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhw QYXm4/pDmNT8UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvL woHib0jEvohPMJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTN r+qHh+7Ltrkbu/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2Kg T1AcZ51E+xG+cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGo UREr0rkMnFVsWeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA==
To: "doh@ietf.org" <doh@ietf.org>
Message-ID: <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz>
Date: Thu, 6 Jun 2019 19:14:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org>
Content-Type: multipart/alternative; boundary="------------1B4FC121A9B96A32BBA13E06"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/IUMXN9hlaaUZ8WB6s37JVSFgFAs>
Subject: Re: [Doh] DoH client-server interoperability vs. strict HTTP parameter checking
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Jun 2019 17:14:27 -0000

On 6/1/19 4:42 PM, Paul Hoffman wrote:
> RFC 8484 makes it clear that a "DoH server" is just an HTTP server that understands the DoH semantics. Trying to limit it beyond that is just wrong (or maybe just lazy).

OK, I'm certainly not familiar with all HTTP customs, I'm afraid, so
this expectation wasn't clear to me just from reading RFC 8484.


On 6/1/19 11:22 PM, Patrick McManus wrote:
> 8484 does not, and really cannot, proscribe the error handling for
> whether the rest of the http server fixes the issue

I fail to see reasons why an RFC can't (or shouldn't) specify behavior
around unknown parts in the URL.  In this case I suspect that a clear
decision will be better than leaving it unspecified, *regardless* of
which way it will be decided.  I believe the robustness principle is
about handling messages that do *not* conform to such a specification.


On 6/1/19 6:08 PM, Mark Delany wrote:
> Surely a server has to expect that it will eventually be talking to a
> client from the future which will, by definition, be adding unknowable
> parameters.

I wouldn't really expect extensibility on *this* layer.  For DNS itself
there's the whole DNS message in the request and answer (we have EDNS
there).  The HTTP layer would be covered by HTTP headers, I thought.

In particular both these extension "layers" communicate in *both*
directions, which seems very useful for interoperability (first Bert's
paragraph, essentially).  I'm not aware of the HTTP parameters being
usable in both directions, but I'm certainly not a good judge in the
HTTP parts.  I'd generally hope for DoH trying to avoid transmitting
additional information that's not in the embedded DNS messages.


On 6/2/19 5:54 PM, Joe Abley wrote:
>  - I want an answer to the question PIR.ORG/IN/SOA
> <http://PIR.ORG/IN/SOA> with RD=1
>  - I want query minimisation and secure transport for recursive queries
>  - I want you to confirm explicitly that you understand the request
> for query minimisation

DoH is sending binary DNS messages, i.e. they include the RD flag inside
and you actually have to set it the way you want it.  You can also put
EDNS inside and receive it back - that's the probable target of your
second and third example, as I see nothing specific to DoH in there, but
so far there aren't any standardized extensions usable for these (I
believe).


P.S.:
In Knot Resolver case it actually is a bit easier to be strict in this
respect, but that's not important for the protocol discussion ;-)

--Vladimir