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

Patrick McManus <mcmanus@ducksong.com> Thu, 06 June 2019 19:09 UTC

Return-Path: <mcmanus@ducksong.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 55F67120241 for <doh@ietfa.amsl.com>; Thu, 6 Jun 2019 12:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=FUti6EDH; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=kRDCUg7Z
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 6nag0RPszVkU for <doh@ietfa.amsl.com>; Thu, 6 Jun 2019 12:09:39 -0700 (PDT)
Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 CDD41120227 for <doh@ietf.org>; Thu, 6 Jun 2019 12:09:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1559848178; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=uN11XNzpeUAmU7X73LEwvhLrwvOjOQNTiVV/TYpTGn9+qP1YicwBFr0Wc+zPm7fp2EHnhjjYOWLGE D2KUE1aXfQw75L1+nuivxq5rSTgLQ6hAUByeGcLRpnSPvsHyoX2l/A2KPo95/9L3edZ0hxp2ROne4w 8wdx/V+F7917gIazyYPptvpDTyVn43V1Nq/8NsXoviKAIuMKqf/CQFUCYwEvlBQf2n7DnE76mmHFeb nt7QiCsCJXeUyg1uU1DYEdhGXKYfm3DHBzeT+xHMeXuUDAxA2aYEw8+wcW5ksYEJ6DxhwuBPcMIbYO E/MeVv2sr5X1RdC4gSWeXhgzcL9nj1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=z1OJbHj3B/tP0Ew4QSzfr83bZpFR2lqXHu+TpmF3SBI=; b=BHzdYbiltlguI9GoND35CV+KpYQIeHs8+d7bQHcR84rX3ASXttw2BhWuF8HCtMkEl0CYYEmf3ABFT QuaCVgtTCKWnJ1e7AGcTmVuwlcp4Z2fm1EDO5vte1oahCMJe9cpNOcM+M95A51+N0HUEpW8yvVZH02 xQaMRuHG4lMnAdiUa71C5PeKb6lzaZXObqH4DTBsLP4bZYdoCOsfbux7vB1gmAFeYXCgBx0OILJrLq 2SqmfD9VP5BByM9Zg7hEhlopGGKzOcTDWVQT+1S+OEMguabNaTgpeq85IbpKLA/TavWVWCssZT9mrc MPFeuf2XGEUOLp3HmCRGi+KkTAJNVdg==
ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.50; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=z1OJbHj3B/tP0Ew4QSzfr83bZpFR2lqXHu+TpmF3SBI=; b=FUti6EDHinP6AE+V/57XixWhER9UtmK2o/WwVwtXZvpl7X2XcS1DSfmKOtBDBNIbD11jgT/6y4lbK hDU9/d2oTEG7wwpOkLeaTebIVS1VgxvIUqrntuUm1gnio7aXBmi3HavFEVdC+rWU2Ff25d/ISHXnpn ZaZMMI8lp0CXSYW4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=z1OJbHj3B/tP0Ew4QSzfr83bZpFR2lqXHu+TpmF3SBI=; b=kRDCUg7Z8zrV74UroyD5tjudUgd0p0F4zO7DpDaAjIYcGTYxZNDZqxyBbU47XKEDCmp8KFg3CBj/4 AeQSCeQ2sbHEuZyqfs+JlzZSYD2odjngWnJgDNBZ5nbnXjKoWetbDwp9OXsLCfHKjK2XaHM6ttMrZT l7r+jlRLjZjKldAP2jvzrDmYhRAzhFK4iRFVfCQ1wnVpAgdILn33CDOh0NVJoD99WAfhgjpXCclXOo 4wSs1I7SN1sC2mMkEBB1+OtaGkPTLeTYWYh/4NG/+CGm+6e0ZLoFi/dg8qI8uBp1bRXWNGdcZl8hKA mhTZLCIdpzp60/KhaU54kAmUxb2ILog==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: a039b5c4-888e-11e9-b39a-9d2c53d3dedb
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.210.50
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-ot1-f50.google.com (unknown [209.85.210.50]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id a039b5c4-888e-11e9-b39a-9d2c53d3dedb; Thu, 06 Jun 2019 19:09:37 +0000 (UTC)
Received: by mail-ot1-f50.google.com with SMTP id l15so3003249otn.9 for <doh@ietf.org>; Thu, 06 Jun 2019 12:09:36 -0700 (PDT)
X-Gm-Message-State: APjAAAWe1xHG3f+Y59MpeY8OcRPOe13ctxfTaNXkiN0f9zbfOPWQL6Gf tAndG4pFCrJeWpvWnReFMrMWk1ao/2qkhBhftlI=
X-Google-Smtp-Source: APXvYqxVj4IRKfjaW/0bkY95VLnXc+ECSfES5fSbghrU3lDzYX7eK2EJCcxIYsb252vOhorXn6rA5cvnmby7KQ8ifbY=
X-Received: by 2002:a9d:62d4:: with SMTP id z20mr16003466otk.340.1559848176475; Thu, 06 Jun 2019 12:09:36 -0700 (PDT)
MIME-Version: 1.0
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org> <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz>
In-Reply-To: <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Thu, 6 Jun 2019 15:09:25 -0400
X-Gmail-Original-Message-ID: <CAOdDvNppBt5aoYexpb22s9i1bqCWmCL9tBAhyLscbZxdd+frNQ@mail.gmail.com>
Message-ID: <CAOdDvNppBt5aoYexpb22s9i1bqCWmCL9tBAhyLscbZxdd+frNQ@mail.gmail.com>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Cc: "doh@ietf.org" <doh@ietf.org>, 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>
Content-Type: multipart/alternative; boundary="000000000000766729058aac743a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Xw9v-Q11G3Fi0EEVe-tYvDrLCI4>
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 19:09:41 -0000

On Thu, Jun 6, 2019 at 1:14 PM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>;
wrote:

>
> 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.
>

The DoH service is scoped by the URI template.. things that match that
template are defined by 8484, but HTTP servers certainly can implement
other services (such as the hypothetical doh fixup gateway) on other URIs
and 8484 cannot define them. This independence is an important part of
HTTP. So this particular boundary is a really hard place to put a hard
error requirement on.