From nobody Sat Jun 1 05:36:29 2019 Return-Path: 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 5F8851202CE for ; Sat, 1 Jun 2019 05:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=appliedprivacy.net header.b=O4LmgajC; dkim=pass (2048-bit key) header.d=appliedprivacy.net header.b=PoMjASXZ 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 rm4yiMQbYcF4 for ; Sat, 1 Jun 2019 05:36:26 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [IPv6:2001:67c:2050:104:0:1:25:1]) (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 3D74912007C for ; Sat, 1 Jun 2019 05:36:24 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 01F734F22C for ; Sat, 1 Jun 2019 14:36:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= appliedprivacy.net; h=content-transfer-encoding:content-language :content-type:content-type:mime-version:date:date:message-id :subject:subject:from:from:received; s=v20171117; t=1559392570; bh=tfEkuTbeCyyDWxJ77bc4lodWEvPsctyQY/gfmx1NHRY=; b=O4LmgajCuczA q1cYB5TWNoTLk7nMK5DIdwRyTHU6dC+Ombr7mwxBwmcRKN1PEuR3Y9D6ZMm56Yc0 Ov8D9B98eVSquXkVZH9oj9CudFQrEH7r+rDKAal6Q4lsxC9Ce7r95wryA5ujTKXS PqzQWZ5QqXGieaLhhdBxzMC2LiOpcURQeW0Zn+9NxTKih2sUSQDjWxCggSN2F70h 12IvzdF1WLYRemCS01YdPCdTXxm1VI4QcZ0dXziM9uEIyP16EpLAF6nHvGGs8hYY MOn3D+043I7bvyhPMhmMg6SoglavhX9Cs35lSnUClqfnrTfF6PuQ8l9JAEyBUjtp vKQpZ56jcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appliedprivacy.net; s=v20171117; t=1559392581; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=tfEkuTbeCyyDWxJ77bc4lodWEvPsctyQY/gfmx1NHRY=; b=PoMjASXZskIC7VCBFb7p6ysbse9Ul0yH77ZCEzUz9wZEpzCLNMIlDDt6N6Z6vFWv/1SnE0 MuNNJMMX3KQT858KK9W3uKM2h8KIWSy1fd+Ix3R+eV2SIw9bDm9ah+U4gxhW75xSw5XOsy kNFbOjT4wRVC3cwiJrcGpZPr8QltzpsgWtvKR55iUP5srVpUj65ZQ6SvXlhlSDgeREZIwo BfHJdOSovWgp2iIIS44r2e3pUGYLdzPPU6+zJf8XfN8RzG0m+QUcIzYmWuzHH1AQ+U581t duAkD0JmgtAKPHKPR+ZTscuJwBti/bqDzol3l4WtEBfpyHhGMyUHI0M9NFdyRw== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id y4tnMIrFpHYe for ; Sat, 1 Jun 2019 14:36:10 +0200 (CEST) To: doh@ietf.org From: Christoph Message-ID: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> Date: Sat, 01 Jun 2019 12:36:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 12:36:28 -0000 Hello, we run a public DoH service and while running and comparing different DoH server implementations in practice we noticed that some have a higher error rate than others. The error rate was measured by looking at the fraction of each HTTP response code. It turned out that those server implementations with a higher error rate just do stricter HTTP parameter checking. Not necessarily the content of the parameter but the list of parameters contained in the request. The result is that some DoH clients are not compatible with some DoH servers. The error condition is caused by DoH clients that have additional HTTP parameters in the request that is not specified in section 4.1 of RFC8484 in combination with DoH server implementations that enforce the absence of any additional parameters. To increase interoperability we reached out to (some) affected DoH client and server vendors but we would also like to hear opinions from this WG. Should DoH servers reject requests with a '400 Bad Request' response when the request contains HTTP parameters not defined in RFC8484 or should DoH servers be less strict and simply ignore additional HTTP parameters and proceed with processing the relevant HTTP parameters required to provide an answer? thanks, Christoph From nobody Sat Jun 1 07:42:47 2019 Return-Path: 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 D29A112019B for ; Sat, 1 Jun 2019 07:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wPo1priZYlHT for ; Sat, 1 Jun 2019 07:42:44 -0700 (PDT) Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F895120047 for ; Sat, 1 Jun 2019 07:42:44 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 1 Jun 2019 07:42:42 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.004; Sat, 1 Jun 2019 07:42:42 -0700 From: Paul Hoffman To: Christoph CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] DoH client-server interoperability vs. strict HTTP parameter checking Thread-Index: AQHVGHalwiv+XCio50OJdXTSCJ8MKaaHVPOA Date: Sat, 1 Jun 2019 14:42:41 +0000 Message-ID: References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> In-Reply-To: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <5612FD9C05CD174E9C219CD5941CE067@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 14:42:46 -0000 On Jun 1, 2019, at 5:36 AM, Christoph wrote: > Should DoH servers reject requests with a '400 Bad Request' > response when the request contains HTTP parameters not defined in RFC8484 No. > or > should DoH servers be less strict and simply ignore additional HTTP > parameters and proceed with processing the relevant HTTP parameters > required to provide an answer? Yes. RFC 8484 makes it clear that a "DoH server" is just an HTTP server that und= erstands the DoH semantics. Trying to limit it beyond that is just wrong (o= r maybe just lazy). --Paul Hoffman= From nobody Sat Jun 1 09:08:35 2019 Return-Path: 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 6878B1201FA for ; Sat, 1 Jun 2019 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 kMrgDTUbikRr for ; Sat, 1 Jun 2019 09:08:32 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3E1200B4 for ; Sat, 1 Jun 2019 09:08:32 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id C23363B05B; Sun, 2 Jun 2019 02:08:30 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1559405310; bh=cvs6HapMJR9CLvX6+rnYfpgu2a8=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=bbSQkBaY+bX3wTcmVAFUq0BNS3Bw0GV8FL8cppev8DWvTpXA7xr/HvJRRdb6b97+U 7zt9leMSQNMYwJNMD92/qck6KuvgUC2RECc7yzPMoOQOaSHc8IW1y3iDyFrOXX5PA6 tTPHDVUhsJLS/etbYFsIpnVSmNg6xv84w6G9YKi0=9YKi0= Comments: QMDA 0.3a Received: (qmail 10634 invoked by uid 1001); 1 Jun 2019 16:08:30 -0000 Date: 1 Jun 2019 16:08:30 +0000 Message-ID: <20190601160830.10633.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 16:08:35 -0000 > > should DoH servers be less strict and simply ignore additional HTTP > > parameters and proceed with processing the relevant HTTP parameters > > required to provide an answer? > > Yes. > > 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). (I'm not sure about lazy since an HTTP server probably has to have more code included to make such tests.) As to the original question, the problem for a server that rejects unrecognized HTTP parameters is, how does it differentiate between a non-standard parameter and a parameter which was standardized in a future version of RFC8484 written after the server was deployed? 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. Clearly a client is taking a small but non-zero risk that its non-standard parameters may collide with the future as well, but the namespace is kinda large so the risk is low. Out of curiousity, what are these extraneous parameters and why is the client sending them? Are they relevant to the DoH query? Mark. From nobody Sat Jun 1 09:39:45 2019 Return-Path: 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 D4C4F120110 for ; Sat, 1 Jun 2019 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=appliedprivacy.net header.b=fYO5/tXe; dkim=pass (2048-bit key) header.d=appliedprivacy.net header.b=lYEbMNHt 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 0SxxuMzEUX4O for ; Sat, 1 Jun 2019 09:39:41 -0700 (PDT) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 213AE120099 for ; Sat, 1 Jun 2019 09:39:40 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 490BBA0121 for ; Sat, 1 Jun 2019 18:39:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= appliedprivacy.net; h=content-transfer-encoding:content-language :content-type:content-type:in-reply-to:mime-version:date:date :message-id:from:from:references:subject:subject:received; s= v20171117; t=1559407175; bh=DoVkuJ2tdy7yx/bz2aF8xAAQpbLalIa7axGN q1zmcow=; b=fYO5/tXerPfDa7nWJrpUe4w7AavlcHKwKkYjT+eI/B66OUrGmrDf AuGD6tp0slhBzlm8qASANbVbFEi/jzywHFURPZIXFAntcwXVBW7Mm5X6M527Rjf1 MfCRLu5S7kkKv0t5b+RwuaR4jyJeFUO+lp+wMl0gLU3hUESDzzBeoZqyt+H1361e itvXaRECwXBy7iULPQbe4UeObQv1comcrn6Es6lbTnheOj4PIhuDZVPPpsocXQ4h +LugjwHlm2Hoe7hMqQlvpyrAM9/7akElTpmvGThY85lzdETNyhjKz8RT7ceMRIRE VjEZFcZlvUKbN37cW0Rc/f7Kf4bLeJb7iA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appliedprivacy.net; s=v20171117; t=1559407178; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DoVkuJ2tdy7yx/bz2aF8xAAQpbLalIa7axGNq1zmcow=; b=lYEbMNHt4b/7nT3fKx/Q7X5HD8h8NE865O9opl8/PyTyqh5Bg3xxNS2GmHi95Tz58NfyOc K2yurDs7k4E0Esi/EX45H6aZOv2MtC6v0cgZhv2jvVOaWVsPox1JR7juOSadtMYie9NYCH O1hEx4rHqhk7iY2bFgbfmo5Lfp4+m2yrrIBprSwJ5gJE5B3qPS75hTihKsm5ZBd8T0WUUg bUV6qj4d6rvGSomBXKeIxETJz8hbzM1j8pnrESiRS0SffDMZta3qx8KGfWJmFp1AyxBmPT f8XHimxaEjhXsEmrlGRFila+pT0Fc/axmtDWYxnnAtgYYEvTXblcq5IgsQIJKg== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id hcDGr-FG2q0z for ; Sat, 1 Jun 2019 18:39:35 +0200 (CEST) To: doh@ietf.org References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> From: Christoph Message-ID: <5f49f8d7-0f05-e7ba-79d4-d0cf9384692c@appliedprivacy.net> Date: Sat, 01 Jun 2019 16:39:00 +0000 MIME-Version: 1.0 In-Reply-To: <20190601160830.10633.qmail@f3-external.bushwire.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 16:39:44 -0000 >>> should DoH servers be less strict and simply ignore additional HTTP >>> parameters and proceed with processing the relevant HTTP parameters >>> required to provide an answer? >> >> Yes. Thanks for the clear reply I hope this is heard. > Out of curiousity, what are these extraneous parameters and why is the > client sending them? Are they relevant to the DoH query? Before version 05, the draft had additional parameter (ct) which some (old) clients apparently still send. From nobody Sat Jun 1 14:22:34 2019 Return-Path: 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 07BDC120118 for ; Sat, 1 Jun 2019 14:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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=AmaEUmYn; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=tZetCP17 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 IC9Bq8tVMMNl for ; Sat, 1 Jun 2019 14:22:30 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 405B81200B1 for ; Sat, 1 Jun 2019 14:22:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559424146; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=WEARzqC/ZHUkjfIHKeEYOcg3B2gq/ulCJoYG6W94r7ggqi19WEgi/8OVkbHVyHQDiO0dW7eLngB3V xrye1y/5mmahbwpujR4QCVMCntvwE8Beoan2kR8jvWHKrMB8BtzG3k4h4RxcMp3QlQQXqoQxkY54Sc p7oFyaIIytt148+Kd/QagSpqUIxrrdH2DdJqs0Sf3fIPO6EDlGatf0UaAwWa2I/IjS05nMq578qznA euCpSTTzQ2mTHN1jJbceMNNbR9CyyvWfjVToRU5sGPUMlwO8Zv03ZoILTip2Ewhhn2XhQZgvkzwDMN ZG3Xx4HdQCZ6lpplBIFY47rbS+LTKBw== 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=bFM3UAJZvAlQA5y64/StpmvsZ5/K6cjoKvCelcZiRzE=; b=GVn51HgGVjAc7p2JOI5nO/W5//W7ngoTrWShAGSnvcdHSOCZ0liATn0VW8EiXIv9a9YJk6kF8nliI 97vKMK3RYa67q0wJ7kTxnJpwFFJoEys4Drb7kK4U2uDOtNqyfsk8XDZ46wfVAFe38pgaDQxjm6YSXy ZN/KPegE/94A6NSG7aMIotc+6Y0ckAr5v8AolfojHTfeXihcP4eqcgKkV2Qkd33uA684g+hMArsCRm BvFxufo7I9SjmtwgUJ6gHWDvoR0VzLoOZjZxS8EqKKN7CzIp2yA3bNqllm+egR8ELtdKxP8EdMCoM5 WxT0SekE4e38imFWmBk4PpdYUSbYEwA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.173; 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=bFM3UAJZvAlQA5y64/StpmvsZ5/K6cjoKvCelcZiRzE=; b=AmaEUmYnq0LFywJGOn3s7SILTTWhPcTiOEnCWBSZmcMgy7mfxjuTIOC6/FldaoFKK3dyK21Z8A9Cx 8Q0rlLiP5/6cRo0+UPxvxE8q+AEmtwNvt1B3TfLusbJqZzzO0eV46sV9XPCWc9zDiwptHT1e6ZXAtl Po6kdy+t2YXxDxIo= 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=bFM3UAJZvAlQA5y64/StpmvsZ5/K6cjoKvCelcZiRzE=; b=tZetCP17n1rX7qdHWwJmczFTI/CnEwwpqmFhhwIQ9gUQ5ib3SlYKlH+XO3npAyOeZy+liT3UMCLur oMDF+c5unjv/G7HJSzVUZ0TCTfDq93ZGdH0hRt/ByHp/fMoTHnnPH9mSIAskqB8SWZT2WY6AiGNsHK JUYKBHQ6Y/6ZPHo74RfbeRn8H7rO5x57HBmhQSWo3mBTX3xsx032hMu0j4n4oFusYpOHDrwyt3LP/f UMfzwAiPekylWEqumcwzaMtJMW7C3phxlmm5Y6dyYtZZd2S7piZknT7vNi23PXP6aLhRgKN1jxApjQ 96KqqtiZVKD+Mc7g1J00ybqBK7F7lNw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 5976a55c-84b3-11e9-990f-673a89bc4518 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.173 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f173.google.com (unknown [209.85.167.173]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 5976a55c-84b3-11e9-990f-673a89bc4518; Sat, 01 Jun 2019 21:22:25 +0000 (UTC) Received: by mail-oi1-f173.google.com with SMTP id b20so6717183oie.12 for ; Sat, 01 Jun 2019 14:22:24 -0700 (PDT) X-Gm-Message-State: APjAAAVeTfEpUris78QdvqnxNfgTBjcq0mHVqDO+nulWm7EY2QhmGDQO k6b9uxk/G6qXdFNbZLRdyEWQDKZpJNNDLLQZhM4= X-Google-Smtp-Source: APXvYqwhHtg0BdxOr5Gs2MS0IN89tWr3P8h3ADHtx4/m/1BX+6mDYcCXsdgQ/gZYBRpkIV4v1cMksgEKZFNN5LnG5qo= X-Received: by 2002:aca:5c54:: with SMTP id q81mr3072794oib.91.1559424144403; Sat, 01 Jun 2019 14:22:24 -0700 (PDT) MIME-Version: 1.0 References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> In-Reply-To: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> From: Patrick McManus Date: Sat, 1 Jun 2019 17:22:13 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christoph Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000002e75c6058a49ba0c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 21:22:33 -0000 --0000000000002e75c6058a49ba0c Content-Type: text/plain; charset="UTF-8" Hi. 8484 servers specify their set of doh uris via uri templates.. which certainly could involve params not in 8484. Such a service would require those params. As for whether a server should be liberal in receiving a uri that does not match it's configured template ... That's a specific instance of a question perhaps more hotly debated than doh itself.. https://tools.ietf.org/html/draft-iab-protocol-maintenance-03 8484 does not, and really cannot, proscribe the error handling for whether the rest of the http server fixes the issue On Sat, Jun 1, 2019, 8:36 AM Christoph wrote: > Hello, > > we run a public DoH service and while running and comparing > different DoH server implementations in practice we noticed that > some have a higher error rate than others. > The error rate was measured by looking at the fraction of each HTTP > response code. > > It turned out that those server implementations with a higher error rate > just do stricter HTTP parameter checking. Not necessarily the content of > the parameter but the list of parameters contained in the request. > > The result is that some DoH clients are not compatible with some DoH > servers. > > The error condition is caused by DoH clients that have additional HTTP > parameters in the request that is not specified in section 4.1 of > RFC8484 in combination with DoH server implementations that enforce the > absence of any additional parameters. > > To increase interoperability we reached out to (some) affected DoH > client and server vendors but we would also like to hear opinions from > this WG. > > Should DoH servers reject requests with a '400 Bad Request' > response when the request contains HTTP parameters not defined in RFC8484 > or > should DoH servers be less strict and simply ignore additional HTTP > parameters and proceed with processing the relevant HTTP parameters > required to provide an answer? > > > thanks, > Christoph > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000002e75c6058a49ba0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.

8484 ser= vers specify their set of doh uris via uri templates.. which certainly coul= d involve params not in 8484. Such a service would require those params.

As for whether a server sh= ould be liberal in receiving a uri that does not match it's configured = template ... That's a specific instance of a question perhaps more hotl= y debated than doh itself..=C2=A0


8484 does not, and r= eally cannot, proscribe the error handling for whether the rest of the http= server fixes=C2=A0the issue

On Sat, Jun 1, 2019, 8:36 AM Christoph &l= t;cm@appliedprivacy.net> wrote:
Hello,

we run a public DoH service and while running and comparing
different DoH server implementations in practice we noticed that
some have a higher error rate than others.
The error rate was measured by looking at the fraction of each HTTP
response code.

It turned out that those server implementations with a higher error rate just do stricter HTTP parameter checking. Not necessarily the content of the parameter but the list of parameters contained in the request.

The result is that some DoH clients are not compatible with some DoH
servers.

The error condition is caused by DoH clients that have additional HTTP
parameters in the request that is not specified in section 4.1 of
RFC8484 in combination with DoH server implementations that enforce the
absence of any additional parameters.

To increase interoperability we reached out to (some) affected DoH
client and server vendors but we would also like to hear opinions from
this WG.

Should DoH servers reject requests with a '400 Bad Request'
response when the request contains HTTP parameters not defined in RFC8484 or
should DoH servers be less strict and simply ignore additional HTTP
parameters and proceed with processing the relevant HTTP parameters
required to provide an answer?


thanks,
Christoph

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo= /doh

--0000000000002e75c6058a49ba0c-- From nobody Sun Jun 2 01:50:04 2019 Return-Path: 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 D399F1200B9 for ; Sun, 2 Jun 2019 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, 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 TQA198ztBczF for ; Sun, 2 Jun 2019 01:50:01 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138EC120025 for ; Sun, 2 Jun 2019 01:50:00 -0700 (PDT) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 1E1E7A2E33; Sun, 2 Jun 2019 08:49:56 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 84724AD243D; Sun, 2 Jun 2019 10:49:56 +0200 (CEST) Date: Sun, 2 Jun 2019 10:49:56 +0200 From: bert hubert To: Mark Delany Cc: doh@ietf.org Message-ID: <20190602084956.GA26997@server.ds9a.nl> References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190601160830.10633.qmail@f3-external.bushwire.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 08:50:03 -0000 On Sat, Jun 01, 2019 at 04:08:30PM +0000, 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. And in the DNS world we've often let clients know we don't get their newfangled speak (FORMERR). Silently ignoring unexpected parameters is a great way to proliferate half-working configurations. "Did parentalcontrol=0&malwarefilter=1 get accepted or not? I have no idea". Secondly, the accepting nature of most HTTP services has created reams of tracking possibilities, viz utm_source and fbclid which now get tacked on at random and track you even if you copy paste the URL to someone. So in short, I would not go out and recommend that servers simply ignore unknown parameters. They might accidentally do it but it fosters bad things like silent errors & even more tracking than cookies, TLS resumption tickets and HTTPS agent headers already bring. Bert From nobody Sun Jun 2 02:44:42 2019 Return-Path: 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 7541C12008F for ; Sun, 2 Jun 2019 02:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=o2.pl 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 bHI4koJLlxva for ; Sun, 2 Jun 2019 02:44:38 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 BB9CC120025 for ; Sun, 2 Jun 2019 02:44:37 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 20152 invoked from network); 2 Jun 2019 11:44:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o2.pl; s=1024a; t=1559468674; bh=W31E0YJ30twuFpZPJuaChrqmMoL5FrRLBkMbtxT7270=; h=From:Subject:To; b=chiz7fUeD7eqbPLTqJg2YIXAHnDLkw8QrzZjZ1VVkM/fmZcipXB0ef7UVa9sv0Uu0 UhwFW2053r4PFlSg45+EUYEsuVVr7a3FPceWLwKAoNoBhBkLrOQdshgDVVnbGvWmws Gy2zcznUPMKv0yGfw37YyaO0MzSAhwase26XKl5k= Received: from aclk15.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.112.15]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 2 Jun 2019 11:44:34 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: Date: Sun, 2 Jun 2019 11:44:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1qaF0aRMHAYucF3RoRU1IFyYROOLjt3Ec" X-WP-MailID: 52f7863bff9f8f97ea2172b89e2b79a2 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000001 [AUIU] Archived-At: Subject: [Doh] Proposal: DNS configuration string X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 09:44:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1qaF0aRMHAYucF3RoRU1IFyYROOLjt3Ec Content-Type: multipart/mixed; boundary="rtnKW1auQfc6S44IbRtsTTghAjTvQ1Yav"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: Subject: Proposal: DNS configuration string --rtnKW1auQfc6S44IbRtsTTghAjTvQ1Yav Content-Type: multipart/alternative; boundary="------------A50BF57C305A12095553134A" Content-Language: en-US This is a multi-part message in MIME format. --------------A50BF57C305A12095553134A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Currently, there are multiple ways of resolving DNS queries: * old port-53 DNS, * DNS over TLS,/ * DNS over HTTPS. Some of these accept additional parameters, such as server certificate information (which may be necessary when using local DoH / DoT servers). = These parameters are server-specific --- when configuring multiple servers, eac= h of them may need different certificate information. I would argue that it would be beneficial to embed all such parameters in= to a single server specification string. The user would be able to copy-paste = them, for example from the website of their chosen DNS resolver, a file provide= d by their sysadmin or from their router configuration GUI. A DHCP server coul= d advertise the string in a single field. Additionally, an application coul= d pass the whole string to a DNS-handling library. That way the application woul= d not have to implement support for all DNS configuration parameters on its own= (with complex GUIs) and new parameters (or even new DNS resolver types) could b= e supported by the program after a library upgrade. This would also simplif= y configuration file structure (allowing for a single server per line). Some examples [3]: * *doh://dnsserver.example.net/dns-query{?dns};***ip=3D1.2.3.4*;root-**= *cert=3D***zdYsea0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo* * *dns://1.2.3.4;valid-for=3D_nodot,.some-company* I would like to propose to use a semicolon ';' as the separator between a= resolver address (or an URI template) and resolver parameters. Theoretica= lly, a DoH URI Template could contain a semicolon, but that should be very rare = [1]. In such cases, the semicolon would be percent-encoded as "%3B". Parameter explanation: * *ip* - IP of the DoH resolver, used for bootstrapping, * *root-cert* - fingerprint of the root certificate of the DoH server (specified in a similar way as in HTTP certificate pinning), * *valid-for *- which domain names should be resolved by this server: i= n this example all names that do not contain a dot ("*_nodot*") [4] as well = as all domains that end with "*.some-company*". What do You think? Greetings, Mateusz [1] A URI segment that begins with a semicolon is called a *path paramete= r*. An example (taken from [2]) would be: =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 *http://www.mysite.com/admin/Update= UserServlet;jsessionid=3DOI24B9ASD7BSSD* The URI template specification (RFC6570) supports expansion of path param= eters with a syntax like: =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 *http://example.com/**{;who}* [2] https://doriantaylor.com/policy/http-url-path-parameter-syntax [3] The DoH specification requires that: =C2=A0=C2=A0=C2=A0 "This protocol MUST be used with the https scheme URI = [RFC7230]." but I assume that using "doh://" does not break this as the statement is = really concerned with using encryption and not the "https://" string. [4] The first character is intentionally "_" because it cannot exist in v= alid domain names. --------------A50BF57C305A12095553134A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello,

Currently, there are multiple ways of resolving DNS queries:

  • old port-53 DNS,
  • DNS over TLS,/
  • DNS over HTTPS.

Some of these accept additional parameters, such as server certificate information (which may be necessary when using local DoH / DoT servers). These parameters are server-specific --- when configuring multiple servers, each of them may need different certificate information.

I would argue that it would be beneficial to embed all such parameters into a single server specification string. The user would be able to copy-paste them, for example from the website of their chosen DNS resolver, a file provided by their sysadmin or from their router configuration GUI. A DHCP server could advertise the string in a single field. Additionally, an application could pass the whole string to a DNS-handling library. That way the application would not have to implement support for all DNS configuration parameters on its own (with complex GUIs) and new parameters (or even new DNS resolver types) could be supported by the program after a library upgrade. This would also simplify configuration file structure (allowing for a single server per line).

Some examples [3]:

  • doh://dnsserver.example.net/dns-query{?dns};ip=3D1= =2E2.3.4;root-cert=3DzdYsea0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQ= Wo
  • dns://1.2.3.4;valid-for=3D_nodot,.some-company

I would like to propose to use a semicolon ';' as the separator between a resolver address (or an URI template) and resolver parameters. Theoretically, a DoH URI Template could contain a semicolon, but that should be very rare [1]. In such cases, the semicolon would be percent-encoded as "%3B".

Parameter explanation:

  • ip - IP of the DoH resolver, used for bootstrapping,
  • root-cert - fingerprint of the root certificate of the DoH server (specified in a similar way as in HTTP certificate pinning),
  • valid-for - which domain names should be resolved by this server: in this example all names that do not contain a dot ("_nodot") [4] as well as all domains that end with ".s= ome-company".
What do You think?

Greetings,

Mateusz



[1] A URI segment that begins with a semicolon is called a path= parameter. An example (taken from [2]) would be:

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 http://www.mysite.com/admin/UpdateUs= erServlet;jsessionid=3DOI24B9ASD7BSSD

The URI template specification (RFC6570) supports expansion of path parameters with a syntax like:

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 http://example.com/{;who}

[2] https://doriantaylor.com/policy/http-url-path-parameter-syntax=

[3] The DoH specification requires that:

=C2=A0=C2=A0=C2=A0 "This protocol MUST be used with the https sche= me URI [RFC7230]."

but I assume that using "doh://" does not break this as the statement is really concerned with using encryption and not the "https://" string.

[4] The first character is intentionally "_" because it cannot exist in valid domain names.

--------------A50BF57C305A12095553134A-- --rtnKW1auQfc6S44IbRtsTTghAjTvQ1Yav-- --1qaF0aRMHAYucF3RoRU1IFyYROOLjt3Ec Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIcBAEBCAAGBQJc85qBAAoJEPvWWrhhCv7GpV4QALXDZbFiXbuM5ZwwjuDxEYJs jaiW5K8Yi23VjZd+Qw76ulW1Sd8T8pc+qorFSkgzNEpMd/oMA7bSgXsYO3fxVeBc 9qq8RFmG1thmJpmjeiFq51+0wexiTzEOoi8dgXUqTO5uJoKfLVJO/GUPiu/WP7jF b2fT9/2OjYyGscjOUSwKlxQtA0v5IIWY+vBtVDF0gyyzvscNyn2u3MV79u6qoMk8 LQN0i21/axZkGtrQE0ldPSEEmvIzUXWJXmE0SrlZvfwQnAjgtRdp1r1jFhutJWqV 0BR39nwuA2RdWzwP6kT8LfApCSVxnYbnfBHNpCm/8TcQv/86Z1tZ+Dg1kSd6j4g2 /F6U2YxufAAPtKjAvE3MkLt/JPhXx6gITQMQY+0g+AI4tUwK8EneSF8AWu5MPf4i LSxEF+puHuWFSxapLlGc9Zanbsjf7BSN5eL4ImNZxfpLfwYcGomN1uzjLoCdyR48 IYaoe9PM2yhG8+Imx4TgiDhyJvJEeop83qaFNeRFf41ls6A1gh2uMQJIgKZu8v8u rIytUBHz3uy+nUt2VyZ36Fg9I+92A/P2PjPk+3Smoifqevj/Q0CUhKP9WWf/M3F4 nPTUETD9GE3fk0mFbUypLED1Nr4x78V2nBxWFXyFf56ZYnl64H8cWGALSRxXagYB /b8PIXvhk0UsNLQSuLhr =Sd6v -----END PGP SIGNATURE----- --1qaF0aRMHAYucF3RoRU1IFyYROOLjt3Ec-- From nobody Sun Jun 2 05:17:59 2019 Return-Path: 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 0F0EF120100 for ; Sun, 2 Jun 2019 05:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 53IzeuET6n51 for ; Sun, 2 Jun 2019 05:17:57 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFCD91200B6 for ; Sun, 2 Jun 2019 05:17:56 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 410C03B05C; Sun, 2 Jun 2019 22:17:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1559477874; bh=HApH4SVNa+F238bZvo6am9ImRPM=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=BaZQQTWAXZgH1u0eo4eF1Mj7KKp62hMUvHEBPgkFE9Z7sCCDWH2Y5UsKmnqgWPbH7 hcF5cuAPi8aAr5CSSF/xKYBriEiZk/KiK22ftSAiyvjXfPE6yj2LmvFbaMi0hY0Nyy +wUjIV1e2HI3HsRMB5jpjlFUb8psDPtuol70ZgaE=0ZgaE= Comments: QMDA 0.3a Received: (qmail 15406 invoked by uid 1001); 2 Jun 2019 12:17:54 -0000 Date: 2 Jun 2019 12:17:54 +0000 Message-ID: <20190602121754.15405.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190602084956.GA26997@server.ds9a.nl> Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 12:17:58 -0000 > And in the DNS world we've often let clients know we don't get their > newfangled speak (FORMERR). Silently ignoring unexpected parameters is a > great way to proliferate half-working configurations. "Did > parentalcontrol=0&malwarefilter=1 get accepted or not? I have no idea". There are certainly pros and cons to this as well as many counter-examples. Haven't we just spent the last decade trying to encourage things like caches, forwarders and firewalls to accept and pass thru DNS RR types they don't recognize? After all, how would we ever extend DNS if every component rejected every RR type and OPT sub-type it didn't understand? I'm not sure I see the distinction between disallowing unexpected HTTP parameters - as you recommend - and disallowing unexpected DNS parameters - which I presume you don't recommend. > So in short, I would not go out and recommend that servers simply ignore > unknown parameters. They might accidentally do it but it fosters bad things > like silent errors & even more tracking than cookies, TLS resumption tickets > and HTTPS agent headers already bring. I sympathize with the problem and like many here I too have been on the receiving end of protocol implementations which were far too lax in what they sent/accepted. But you're effectively recommending that DoH shouldn't use the extension mechanisms built into HTTP. At that point you have to ask whether it's even HTTP any more. A related problem is that most DoH implementors probably rely on pre-existing HTTP componentry rather than rolling their own from scratch. Said componetry is notorious for adding headers without necessarily giving the application much control over it. After all, it's worked fine for the last 20+ years, why stop now? So at least on that front I think the horse has well and truly bolted. I suppose one could go down the path of a DoH HTTP profile or version but most internet protocols seem to shy away from the strictures of profiling and versioning - perhaps because upgrades tend to turn into monumental events. I don't think there's ever been a good solution to this dilemma: accepting unknown parameters is a protocol risk yet accepting unknown parameters is also the preferred mechanism for version interop. Mark. From nobody Sun Jun 2 08:54:27 2019 Return-Path: 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 528281200E6 for ; Sun, 2 Jun 2019 08:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 tP-5MiBBfL3j for ; Sun, 2 Jun 2019 08:54:23 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B468D120026 for ; Sun, 2 Jun 2019 08:54:23 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id a186so23610181itg.0 for ; Sun, 02 Jun 2019 08:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cWMPAVZ3FnrVrqKljNOCqj4v2uqzIQBU2L5h5zOdoHk=; b=J3FdB5+Y06nYmfKS8OdMDYrJHoFbAe2nzRyUGQgVtPa/rbAxmjynYcftkUPZ4DU8ZX fE7uFlY8bKP+5Go0SFcN4SeoWk/6uLl0gbEM/75HrI4TL/oikJ7aXlj+s/EM/1LaXr7n kn5qEeByBIuuXehW6/JzSafY5tpP9KMZwE3Ho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cWMPAVZ3FnrVrqKljNOCqj4v2uqzIQBU2L5h5zOdoHk=; b=UhwrvNKo0gJKtlKj/j9Afi3uB5EuLOuDeXAnhr8jcIrTtaX6iXxLoGri79qK/J3OrV NYL4aJg9+yjaeOVO8IX0k37Nkb1y28xQDPzG/L1ehti5om3tBU9S+ju5cZd/Ybs9uhBe YkDdYB+Ry/o1gc3Qyq8o8de1VciolNkCwmwqR18oe56sxOolVzptqAwES2AiYytxMVXg +IzhVF1jkkVQEfdLfVN4LpBgjHBw6UfhkMA0Ss9M0Grx/j9wXfTauPOg3OF4T8D+74Zf 19Wmn/N/zEUMDw2JAf7so4m/fhZ05L5uqTQvnn4G50dxSzJrJOKsDr8RWtBhi3327AgT TyrA== X-Gm-Message-State: APjAAAVHckhwTep7t2WKVKSfPkzYkyvLENN8VuiVYwXTpacrXLQzUZy0 D/Ccvp5B+u1NyGI8uVJ0XovVczWMH3X3TZAk X-Google-Smtp-Source: APXvYqxDP7QAIHZphbIkPAtdJ9oMwLYrhKMahSMwV4lW0ZeNZxXlY4CXQPUxkvqR13wVIw4ZalG9Sw== X-Received: by 2002:a05:660c:a59:: with SMTP id j25mr14005357itl.111.1559490862919; Sun, 02 Jun 2019 08:54:22 -0700 (PDT) Received: from [192.168.1.50] (198-84-196-112.cpe.teksavvy.com. [198.84.196.112]) by smtp.gmail.com with ESMTPSA id t22sm2294987ioc.75.2019.06.02.08.54.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jun 2019 08:54:21 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C408DF3A-FB08-404E-BE8E-C888A50900FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 2 Jun 2019 11:54:20 -0400 In-Reply-To: <20190602121754.15405.qmail@f3-external.bushwire.net> Cc: doh@ietf.org To: Mark Delany References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> <20190602121754.15405.qmail@f3-external.bushwire.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Doh] [Ext] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 15:54:25 -0000 --Apple-Mail=_C408DF3A-FB08-404E-BE8E-C888A50900FA Content-Type: multipart/alternative; boundary="Apple-Mail=_FCCF942A-45E7-4074-A593-C28E173105D9" --Apple-Mail=_FCCF942A-45E7-4074-A593-C28E173105D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mark, On 2 Jun 2019, at 08:17, Mark Delany > wrote: >> And in the DNS world we've often let clients know we don't get their >> newfangled speak (FORMERR). Silently ignoring unexpected parameters = is a >> great way to proliferate half-working configurations. "Did >> parentalcontrol=3D0&malwarefilter=3D1 get accepted or not? I have no = idea". >=20 > There are certainly pros and cons to this as well as many = counter-examples. >=20 > Haven't we just spent the last decade trying to encourage things like = caches, > forwarders and firewalls to accept and pass thru DNS RR types they = don't > recognize? I'm not sure that's actually a particularly good example. New RRTYPEs = are not new parameters or new protocol elements; they're existing ones = with different code-points. The distinction is important. To the kinds = of intermediate actors you mention, wire-format RRSets ought to be = passed through as opaque structures. > After all, how would we ever extend DNS if every component rejected > every RR type and OPT sub-type it didn't understand? EDNS is a better example, since RFC 6891 makes it clear that unknown = options MUST be ignored. In the very general sense (ignoring protocol specifics relating to the = DNS and HTTP) it feels like it might be handy to be able to specify a = capabilities requirement with a query. Something like - I want an answer to the question PIR.ORG/IN/SOA = with RD=3D1 - I want query minimisation and secure transport for recursive queries - I want you to confirm explicitly that you understand the request for = query minimisation A receiving server could ignore the request for secure transport if it = didn't understand it, but would refuse to process the query if it didn't = understand query minimisation (and hence would otherwise silently = discard the request). Joe --Apple-Mail=_FCCF942A-45E7-4074-A593-C28E173105D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Mark,

On = 2 Jun 2019, at 08:17, Mark Delany <d5e@xray.emu.st> wrote:

And in the DNS world we've often let clients know we don't = get their
newfangled speak (FORMERR).  Silently = ignoring unexpected parameters is a
great way to = proliferate half-working configurations.  "Did
parentalcontrol=3D0&malwarefilter=3D1 get accepted or = not?  I have no idea".

There are certainly pros and cons to this as well as many = counter-examples.

Haven't we just spent the = last decade trying to encourage things like caches,
forwarders and firewalls to accept and pass thru DNS RR types = they don't
recognize?

I'm not sure that's actually a particularly good = example. New RRTYPEs are not new parameters or new protocol elements; = they're existing ones with different code-points. The distinction is = important. To the kinds of intermediate actors you mention, wire-format = RRSets ought to be passed through as opaque structures.

After all, how would we ever extend DNS if every component = rejected
every RR type and OPT sub-type it didn't = understand?

EDNS is a better example, since RFC 6891 makes it = clear that unknown options MUST be ignored.

In the very general sense (ignoring protocol = specifics relating to the DNS and HTTP) it feels like it might be handy = to be able to specify a capabilities requirement with a query. Something = like

 - I want an answer to the = question PIR.ORG/IN/SOA with RD=3D1
 - I want = query minimisation and secure transport for recursive = queries
 - I want you to confirm explicitly that you = understand the request for query minimisation

A receiving server could ignore the request for = secure transport if it didn't understand it, but would refuse to process = the query if it didn't understand query minimisation (and hence would = otherwise silently discard the request).


Joe

= --Apple-Mail=_FCCF942A-45E7-4074-A593-C28E173105D9-- --Apple-Mail=_C408DF3A-FB08-404E-BE8E-C888A50900FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXPPxLAAKCRA0jwy9hlI6 LPvgAKCDX4QLXk5uMsMBz8yEK2Jorlc7wACeO1tL6zC4FBhyZsEXiqqFuSG8EfY= =JOfj -----END PGP SIGNATURE----- --Apple-Mail=_C408DF3A-FB08-404E-BE8E-C888A50900FA-- From nobody Sun Jun 2 09:22:15 2019 Return-Path: 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 485981200DB for ; Sun, 2 Jun 2019 09:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 JwzA6NNh71x3 for ; Sun, 2 Jun 2019 09:22:12 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7771120094 for ; Sun, 2 Jun 2019 09:22:11 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 2DDD324205E6; Sun, 2 Jun 2019 16:21:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Sun, 2 Jun 2019 17:21:52 +0100 Cc: Mark Delany , doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> <20190602121754.15405.qmail@f3-external.bushwire.net> To: Joe Abley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Doh] signalling client expectations and server capabilities X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 16:22:13 -0000 > On 2 Jun 2019, at 16:54, Joe Abley wrote: >=20 > In the very general sense (ignoring protocol specifics relating to the = DNS and HTTP) it feels like it might be handy to be able to specify a = capabilities requirement with a query. Something like >=20 > - I want an answer to the question PIR.ORG/IN/SOA with RD=3D1 > - I want query minimisation and secure transport for recursive = queries > - I want you to confirm explicitly that you understand the request = for query minimisation Hmmm. The add list might be a more appropriate place to discuss this. Or = maybe dnsop. It=E2=80=99s not clear if these sorts of capabilities = could/should be signalled in DoH or vanilla DNS. From nobody Sun Jun 2 13:57:42 2019 Return-Path: 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 B6B491200F5 for ; Sun, 2 Jun 2019 13:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 wdmOjoFS5dp6 for ; Sun, 2 Jun 2019 13:57:39 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9012004E for ; Sun, 2 Jun 2019 13:57:38 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id CD4933B05C; Mon, 3 Jun 2019 06:57:35 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1559509055; bh=2hDS0esy/D1gSwvjc+2tyG3tJLM=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=M94hGQhNSzLZe/j5KXAOWRzWdo2GMa/R6Mxglrna5RK583l2OJfd2mfYflly5o7RX K/kSLK3DXfrEJq5qXyPWd+No6txt0SU22ya+vDOnvIl1+mc9bsNqUh18cW+RKixZxE eF+gmsIvw5PQfddDnU400XKU/JPAF5NtYWmo07Xo=o07Xo= Comments: QMDA 0.3a Received: (qmail 17700 invoked by uid 1001); 2 Jun 2019 20:57:35 -0000 Date: 2 Jun 2019 20:57:35 +0000 Message-ID: <20190602205735.17699.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> <20190602121754.15405.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] signalling client expectations and server capabilities X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 20:57:41 -0000 On 02Jun19, Jim Reid allegedly wrote: > > > > On 2 Jun 2019, at 16:54, Joe Abley wrote: > > > > In the very general sense (ignoring protocol specifics relating to the DNS and HTTP) it feels like it might be handy to be able to specify a capabilities requirement with a query. Something like > > > > - I want an answer to the question 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 Yes, I had thought about mentioning capabilities but I doubted anyone would have read below the fold of my email :-) One thing I wondered about is how well capabilities work in a multi-hop and multi-transport system that has DoH in the path. In the very general sense should a stub resolver asking for capabilities have said query punch all the way through to an auth server? There is already a smattering of adhoc capability signals in DNS such as TC=1 and maximum response size which probably should have received some attention in 8484 so if nothing else maybe formalization will at least raise the question for future protocol designers: "how do we deal with capabilities?". > Hmmm. The add list might be a more appropriate place to discuss this. Or maybe dnsop. It???s not clear if these sorts of capabilities could/should be signalled in DoH or vanilla DNS. It's certainly a big topic and probably risks the second-system syndrome. Mark. From nobody Sun Jun 2 15:53:14 2019 Return-Path: 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 598B9120127 for ; Sun, 2 Jun 2019 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZiU9b3+f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ECnvRSV3 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 o427j7IOd6Mo for ; Sun, 2 Jun 2019 15:53:09 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4703D1200F1 for ; Sun, 2 Jun 2019 15:53:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D71321540; Sun, 2 Jun 2019 18:53:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 02 Jun 2019 18:53:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=/ JnQJ19Qd96dTvRqYB6Lys/w4/QdSYChraAbs74dY5Y=; b=ZiU9b3+f16qOmUBUL 7jmtEWm4JyUpGKS8ZZfCXfg4Wheqhbi5+uDPy4yL27ILCuJ/onJ9hoXNrqvqUUiX UijLqJodl0eEDeCBTjIU6kShCL6IQSGsAPh6bkrXzSxmWi+mqKNdeHUd8sVs39dB zWKPJE+fSDbQod+2/H2hoU9gbfIPtVSRMBNptZ86X5LrX15t0jJImU+hyD0Ji/GI XpYQFaRJyBoA8Y6wXH7qp5Cpx14cF5Dr2zDYGvi9hwfFqae6x/edc81OD8p57yC+ zehQgFlgGoE4ui0cb23UWG7x5EPmcsZb7Hdc3XqOXg3Nw9fCxJ6lUfsUY6SPrlyK s1bMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=/JnQJ19Qd96dTvRqYB6Lys/w4/QdSYChraAbs74dY 5Y=; b=ECnvRSV3YejrNlbx2l2ilKUOMOWzzNkL9CueEs9+Y/A6n3xEM6ns39rx1 MHPD+d5r0ChHAx7RVHMbQQN4q3Z2dgs0isWCN5JCrd2i8PU55sM6rqADHpH/ZDjX Ixv9hG741BmRsCnvZDcxcohdc4emhuqxVrhUEBqc63X7Q8qg4CMnchjEDOHjyhhN 1jHZBf8BAg9xzVCG7gVNgHOZxXfPIRwELQx03n5TEMJpdZ3C0HImG04dFpv1ZUyS GUU1VZNcrg3U4iXYWy41KPCmZg702TpdgFXLLPtY8ChnzZV50+/FSmHztKzcdEoT ZgymfH1EXbeD92url6UfLdyoSNDtQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefiedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhihshhithgvrdgtohhmpdgvgigrmhhplhgvrdhnvghtpdhmnhhothdrnhgvthdpvgig rghmphhlvgdrtghomhdpughorhhirghnthgrhihlohhrrdgtohhmnecukfhppedurddufe eirdduieejrdduuddunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohht rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [172.20.10.3] (unknown [1.136.167.111]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C0EE38008E; Sun, 2 Jun 2019 18:53:05 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: Date: Mon, 3 Jun 2019 08:53:00 +1000 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net> References: To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Doh] Proposal: DNS configuration string X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 22:53:13 -0000 Why not just convey this separately -- why does it have to be in the = URL? > On 2 Jun 2019, at 7:44 pm, Mateusz Jo=C5=84czyk = wrote: >=20 > Signed PGP part > Hello, >=20 > Currently, there are multiple ways of resolving DNS queries: >=20 > =E2=80=A2 old port-53 DNS, > =E2=80=A2 DNS over TLS,/ > =E2=80=A2 DNS over HTTPS. > Some of these accept additional parameters, such as server certificate = information (which may be necessary when using local DoH / DoT servers). = These parameters are server-specific --- when configuring multiple = servers, each of them may need different certificate information. >=20 > I would argue that it would be beneficial to embed all such parameters = into a single server specification string. The user would be able to = copy-paste them, for example from the website of their chosen DNS = resolver, a file provided by their sysadmin or from their router = configuration GUI. A DHCP server could advertise the string in a single = field. Additionally, an application could pass the whole string to a = DNS-handling library. That way the application would not have to = implement support for all DNS configuration parameters on its own (with = complex GUIs) and new parameters (or even new DNS resolver types) could = be supported by the program after a library upgrade. This would also = simplify configuration file structure (allowing for a single server per = line). >=20 > Some examples [3]: >=20 > =E2=80=A2 = doh://dnsserver.example.net/dns-query{?dns};ip=3D1.2.3.4;root-cert=3DzdYse= a0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo > =E2=80=A2 dns://1.2.3.4;valid-for=3D_nodot,.some-company > I would like to propose to use a semicolon ';' as the separator = between a resolver address (or an URI template) and resolver parameters. = Theoretically, a DoH URI Template could contain a semicolon, but that = should be very rare [1]. In such cases, the semicolon would be = percent-encoded as "%3B". >=20 > Parameter explanation: >=20 > =E2=80=A2 ip - IP of the DoH resolver, used for bootstrapping, > =E2=80=A2 root-cert - fingerprint of the root certificate of the = DoH server (specified in a similar way as in HTTP certificate pinning), > =E2=80=A2 valid-for - which domain names should be resolved by = this server: in this example all names that do not contain a dot = ("_nodot") [4] as well as all domains that end with ".some-company". > What do You think? > Greetings, >=20 > Mateusz >=20 >=20 >=20 >=20 >=20 > [1] A URI segment that begins with a semicolon is called a path = parameter. An example (taken from [2]) would be: >=20 > = http://www.mysite.com/admin/UpdateUserServlet;jsessionid=3DOI24B9ASD7BSSD >=20 > The URI template specification (RFC6570) supports expansion of path = parameters with a syntax like: >=20 > http://example.com/{;who} >=20 > [2] https://doriantaylor.com/policy/http-url-path-parameter-syntax >=20 > [3] The DoH specification requires that: >=20 > "This protocol MUST be used with the https scheme URI [RFC7230]." >=20 > but I assume that using "doh://" does not break this as the statement = is really concerned with using encryption and not the "https://" string.=20= >=20 > [4] The first character is intentionally "_" because it cannot exist = in valid domain names. >=20 >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 3 08:47:57 2019 Return-Path: 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 5E11D1202FF for ; Mon, 3 Jun 2019 08:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=o2.pl 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 p_i656FnVVp4 for ; Mon, 3 Jun 2019 08:47:52 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 46F8112037D for ; Mon, 3 Jun 2019 08:47:36 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 31243 invoked from network); 3 Jun 2019 17:47:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o2.pl; s=1024a; t=1559576852; bh=bRBCc8U3SjVcrFPi7ePvfzZJjsMnnUN3vpH73g2YC8s=; h=From:Subject:To:Cc; b=JfYZuogsaJNwghgn/NeXHPrK4Gw6SpfjOAslK4oODZKtfkJzl2sSOywW4VVdK6/xo BJ/U7jVUaehhuGf9Hq9q8Zo13MY48jkZDB1VDn5/X/LyefEGyaMZq8GutKg2PnoazU T/SM8kc4vTUVsaI7hHRv5PK/uwtlo4xQTNJ5e51I= Received: from acpo60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.220.60]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 3 Jun 2019 17:47:32 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Mark Nottingham Cc: DoH WG References: <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net> Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: <9b0b1ad8-2be3-5b47-5e2b-b1de1052d1b9@o2.pl> Date: Mon, 3 Jun 2019 17:47:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net> Content-Type: multipart/alternative; boundary="------------0D6862A0076D5B2E04FD2B9A" Content-Language: pl-PL X-WP-MailID: b6c7490a865cb377f162728d947b6183 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [ocNE] Archived-At: Subject: [Doh] Proposal: DNS configuration string X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 15:47:55 -0000 This is a multi-part message in MIME format. --------------0D6862A0076D5B2E04FD2B9A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit There are many configuration parameters involved in DoH. After encapsulating them in a single string, it is easier for the user to set a custom DoH resolver, among other benefits (which I elaborated on in the original e-mail). W dniu 03.06.2019 o 00:53, Mark Nottingham pisze: > Why not just convey this separately -- why does it have to be in the URL? > >> On 2 Jun 2019, at 7:44 pm, Mateusz Jończyk wrote: >> >> Signed PGP part >> Hello, >> >> Currently, there are multiple ways of resolving DNS queries: >> >> • old port-53 DNS, >> • DNS over TLS,/ >> • DNS over HTTPS. >> Some of these accept additional parameters, such as server certificate information >> (which may be necessary when using local DoH / DoT servers). These parameters are >> server-specific --- when configuring multiple servers, each of them may need >> different certificate information. >> >> I would argue that it would be beneficial to embed all such parameters into a >> single server specification string. The user would be able to copy-paste them, >> for example from the website of their chosen DNS resolver, a file provided by >> their sysadmin or from their router configuration GUI. A DHCP server could advertise >> the string in a single field. Additionally, an application could pass the whole >> string to a DNS-handling library. That way the application would not have to >> implement support for all DNS configuration parameters on its own (with complex >> GUIs) and new parameters (or even new DNS resolver types) could be supported by >> the program after a library upgrade. This would also simplify configuration file >> structure (allowing for a single server per line). >> >> Some examples [3]: >> >> • doh://dnsserver.example.net/dns-query{?dns};ip=1.2.3.4;root-cert=zdYsea0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo >> • dns://1.2.3.4;valid-for=_nodot,.some-company >> >> I would like to propose to use a semicolon ';' as the separator between >> a resolver address (or an URI template) and resolver parameters. Theoretically, >> a DoH URI Template could contain a semicolon, but that should be very rare [1]. In such cases, the semicolon would be percent-encoded as "%3B". >> >> Parameter explanation: >> >> • ip - IP of the DoH resolver, used for bootstrapping, >> • root-cert - fingerprint of the root certificate of the >> DoH server (specified in a similar way as in HTTP certificate pinning), >> • valid-for - which domain names should be resolved by this >> server: in this example all names that do not contain a dot ("_nodot") [4] as well as all domains that end with ".some-company". >> >> What do You think? >> >> Greetings, >> >> Mateusz >> >> >> >> >> >> [1] A URI segment that begins with a semicolon is called a path parameter. An example (taken from [2]) would be: >> >> http://www.mysite.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD >> >> The URI template specification (RFC6570) supports expansion of path parameters with a syntax like: >> >> http://example.com/{;who} >> >> [2] https://doriantaylor.com/policy/http-url-path-parameter-syntax >> >> [3] The DoH specification requires that: >> >> "This protocol MUST be used with the https scheme URI [RFC7230]." >> >> but I assume that using "doh://" does not break this as the statement is really >> concerned with using encryption and not the "https://" string. >> >> [4] The first character is intentionally "_" because it cannot exist in valid domain names. >> >> >> >> > -- > Mark Nottingham https://www.mnot.net/ > > --------------0D6862A0076D5B2E04FD2B9A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

There are many configuration parameters involved in DoH.
After encapsulating them in a single string, it is easier for the user
to set a custom DoH resolver, among other benefits (which I
elaborated on in the original e-mail).

W dniu 03.06.2019 o 00:53, Mark Nottingham pisze:

Why not just convey this separately -- why does it have to be in the URL?


On 2 Jun 2019, at 7:44 pm, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:

Signed PGP part
Hello,

Currently, there are multiple ways of resolving DNS queries:

	• old port-53 DNS,
	• DNS over TLS,/
	• DNS over HTTPS.
Some of these accept additional parameters, such as server certificate information 
(which may be necessary when using local DoH / DoT servers). These parameters are 
server-specific --- when configuring multiple servers, each of them may need 
different certificate information.

I would argue that it would be beneficial to embed all such parameters into a 
single server specification string. The user would be able to copy-paste them, 
for example from the website of their chosen DNS resolver, a file provided by 
their sysadmin or from their router configuration GUI. A DHCP server could advertise 
the string in a single field. Additionally, an application could pass the whole 
string to a DNS-handling library. That way the application would not have to 
implement support for all DNS configuration parameters on its own (with complex 
GUIs) and new parameters (or even new DNS resolver types) could be supported by 
the program after a library upgrade. This would also simplify configuration file 
structure (allowing for a single server per line).

Some examples [3]:

	• doh://dnsserver.example.net/dns-query{?dns};ip=1.2.3.4;root-cert=zdYsea0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo
	• dns://1.2.3.4;valid-for=_nodot,.some-company

I would like to propose to use a semicolon ';' as the separator between 
a resolver address (or an URI template) and resolver parameters. Theoretically, 
a DoH URI Template could contain a semicolon, but that should be very rare [1]. In such cases, the semicolon would be percent-encoded as "%3B".

Parameter explanation:

	• ip - IP of the DoH resolver, used for bootstrapping,
	• root-cert - fingerprint of the root certificate of the 
DoH server (specified in a similar way as in HTTP certificate pinning),
	• valid-for - which domain names should be resolved by this 
server: in this example all names that do not contain a dot ("_nodot") [4] as well as all domains that end with ".some-company".

What do You think?

Greetings,

Mateusz





[1] A URI segment that begins with a semicolon is called a path parameter. An example (taken from [2]) would be:

        http://www.mysite.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD

The URI template specification (RFC6570) supports expansion of path parameters with a syntax like:

        http://example.com/{;who}

[2] https://doriantaylor.com/policy/http-url-path-parameter-syntax

[3] The DoH specification requires that:

    "This protocol MUST be used with the https scheme URI [RFC7230]."

but I assume that using "doh://" does not break this as the statement is really 
concerned with using encryption and not the "https://" string. 

[4] The first character is intentionally "_" because it cannot exist in valid domain names.





--
Mark Nottingham   https://www.mnot.net/
--------------0D6862A0076D5B2E04FD2B9A-- From nobody Mon Jun 3 15:17:54 2019 Return-Path: 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 EFD7E120120 for ; Mon, 3 Jun 2019 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=KSwTOyhU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t4ykPiEd 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 WAniqJ2r_KoW for ; Mon, 3 Jun 2019 15:17:50 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B50120862 for ; Mon, 3 Jun 2019 15:17:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0D24222289; Mon, 3 Jun 2019 18:17:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 03 Jun 2019 18:17:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=v ckVMd2oo22ScvLx49ZyAvQ129G38YLl9BzOU2d10Fo=; b=KSwTOyhUdGcZpAacs 4efyD/pLVl21hsECyZ6C0ZPJyL01EJ1GL95eHiA0Z2BhNvcLm0ekq+PWYEnwCCOs W9Ihv148HkMF2hjWJFfxDvO5GIrG2ZdbvuSqVNOOTGuCOELCH0bnsyjP9sONag12 MXcHjBzgUR9wCp8sdVrgBHvl0JikLtl1E5LogA3UbR0FyQNNf006G/p/FChj5t/U xYccgYx6aokeEJcm5DSW7eDeEyJxabuqk+LYSJq2wXYvqErEWZmYi23I3mtvxAbb XZPUaVG8rvs+0CBGHc3pZWnMKa+gKVsojNcfMDf0AeDfekl1hFL6sTE7/nGvII6H jAKgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vckVMd2oo22ScvLx49ZyAvQ129G38YLl9BzOU2d10 Fo=; b=t4ykPiEdXb9uK7eUjst5nZ+9KhKXd0p+9sgfjJj+fToxXAsgd/AqRdC+w iIPo827lvzKdsyex+PSdBLYvNM5z8Nw8djb3KEE64+ilbiYKxjXQTrCylgQjRELe YsVF7D17RiV8sCF+zzJ5yL1z2l5NB3C4IUqxefcVRel/RT/CrCXlExvrC1ylmyDy yj7Y7gAPQlyeFxarBlKJQez0DTJUe9whAXb1YNLtZJAk6CuDeUKSIhL7djOK+71c S2FOJTpzuLhX1K+TU8DKCpo+6rPXKYG7mMI7HYLHfFs/Jv9zoSvt53OUxGZrSOnZ LklQidHlfi5uop2GVYl8KWjhm5IpA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefkedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhihshhithgvrdgtohhmpdgvgigrmhhplhgvrdhnvghtpdhivghtfhdrohhrghdpmhhn ohhtrdhnvghtpdgvgigrmhhplhgvrdgtohhmpdguohhrihgrnhhtrgihlhhorhdrtghomh enucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhm pehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id A81E580059; Mon, 3 Jun 2019 18:17:47 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: <9b0b1ad8-2be3-5b47-5e2b-b1de1052d1b9@o2.pl> Date: Tue, 4 Jun 2019 08:17:43 +1000 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <41206ECE-4CD8-41A5-AE4B-2EFE0EC00A6A@mnot.net> <9b0b1ad8-2be3-5b47-5e2b-b1de1052d1b9@o2.pl> To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Doh] Proposal: DNS configuration string X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 22:17:54 -0000 On 4 Jun 2019, at 1:47 am, Mateusz Jo=C5=84czyk = wrote: >=20 > There are many configuration parameters involved in DoH.=20 > After encapsulating them in a single string, it is easier for the user=20= > to set a custom DoH resolver, among other benefits (which I=20 > elaborated on in the original e-mail). I understand that -- my question was why that configuration needs to be = conveyed as part of the URL template's syntax, rather than in a = structure (perhaps a string) that contains the URL template. Structuring = a URL like that violates BCP190. For example, instead of: dns://1.2.3.4;valid-for=3D_nodot,.some-company You could use: dns://1.2.3.4 valid-for=3D_nodot,.some-company Because a space isn't valid in a URL (or template), it's not making the = assumption that the structure you're usurping is "very rare" -- such = assumptions don't hold at Internet scale. (If you don't like space, there are a lot of other characters that are = invalid in URLs that could be used as a delimiter, or you could embed = the URL template in another structured format, e.g., JSON or XML). Cheers, >=20 > W dniu 03.06.2019 o 00:53, Mark Nottingham pisze: >=20 >> Why not just convey this separately -- why does it have to be in the = URL? >>=20 >>=20 >>> On 2 Jun 2019, at 7:44 pm, Mateusz Jo=C5=84czyk >>> wrote: >>>=20 >>> Signed PGP part >>> Hello, >>>=20 >>> Currently, there are multiple ways of resolving DNS queries: >>>=20 >>> =E2=80=A2 old port-53 DNS, >>> =E2=80=A2 DNS over TLS,/ >>> =E2=80=A2 DNS over HTTPS. >>> Some of these accept additional parameters, such as server = certificate information=20 >>> (which may be necessary when using local DoH / DoT servers). These = parameters are=20 >>> server-specific --- when configuring multiple servers, each of them = may need=20 >>> different certificate information. >>>=20 >>> I would argue that it would be beneficial to embed all such = parameters into a=20 >>> single server specification string. The user would be able to = copy-paste them,=20 >>> for example from the website of their chosen DNS resolver, a file = provided by=20 >>> their sysadmin or from their router configuration GUI. A DHCP server = could advertise=20 >>> the string in a single field. Additionally, an application could = pass the whole=20 >>> string to a DNS-handling library. That way the application would not = have to=20 >>> implement support for all DNS configuration parameters on its own = (with complex=20 >>> GUIs) and new parameters (or even new DNS resolver types) could be = supported by=20 >>> the program after a library upgrade. This would also simplify = configuration file=20 >>> structure (allowing for a single server per line). >>>=20 >>> Some examples [3]: >>>=20 >>> =E2=80=A2 = doh://dnsserver.example.net/dns-query{?dns};ip=3D1.2.3.4;root-cert=3DzdYse= a0CQufOmBpLdLfu/q3tOOdxbBCuZNhAa+YuQWo >>> =E2=80=A2 dns://1.2.3.4;valid-for=3D_nodot,.some-company >>>=20 >>> I would like to propose to use a semicolon ';' as the separator = between=20 >>> a resolver address (or an URI template) and resolver parameters. = Theoretically,=20 >>> a DoH URI Template could contain a semicolon, but that should be = very rare [1]. In such cases, the semicolon would be percent-encoded as = "%3B". >>>=20 >>> Parameter explanation: >>>=20 >>> =E2=80=A2 ip - IP of the DoH resolver, used for bootstrapping, >>> =E2=80=A2 root-cert - fingerprint of the root certificate of the=20= >>> DoH server (specified in a similar way as in HTTP certificate = pinning), >>> =E2=80=A2 valid-for - which domain names should be resolved by = this=20 >>> server: in this example all names that do not contain a dot = ("_nodot") [4] as well as all domains that end with ".some-company". >>>=20 >>> What do You think? >>>=20 >>> Greetings, >>>=20 >>> Mateusz >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> [1] A URI segment that begins with a semicolon is called a path = parameter. An example (taken from [2]) would be: >>>=20 >>> =20 >>> = http://www.mysite.com/admin/UpdateUserServlet;jsessionid=3DOI24B9ASD7BSSD >>>=20 >>>=20 >>> The URI template specification (RFC6570) supports expansion of path = parameters with a syntax like: >>>=20 >>> =20 >>> http://example.com/ >>> {;who} >>>=20 >>> [2]=20 >>> https://doriantaylor.com/policy/http-url-path-parameter-syntax >>>=20 >>>=20 >>> [3] The DoH specification requires that: >>>=20 >>> "This protocol MUST be used with the https scheme URI = [RFC7230]." >>>=20 >>> but I assume that using "doh://" does not break this as the = statement is really=20 >>> concerned with using encryption and not the "https://" string.=20 >>>=20 >>> [4] The first character is intentionally "_" because it cannot exist = in valid domain names. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >> -- >> Mark Nottingham =20 >> https://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 6 10:14:30 2019 Return-Path: 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 ; 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 ; 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 ; 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 , Christoph , Patrick McManus , Mark Delany , Joe Abley References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= 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" 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:14:27 -0000 This is a multi-part message in MIME format. --------------1B4FC121A9B96A32BBA13E06 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 >  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 --------------1B4FC121A9B96A32BBA13E06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 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

--------------1B4FC121A9B96A32BBA13E06-- From nobody Thu Jun 6 10:26:24 2019 Return-Path: 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 4C205120092 for ; Thu, 6 Jun 2019 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 xBZF5qh07x62 for ; Thu, 6 Jun 2019 10:26:21 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574A912000F for ; Thu, 6 Jun 2019 10:26:21 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id a186so1258433itg.0 for ; Thu, 06 Jun 2019 10:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1+KMEU9nLAyfnLONDvqLidSgbB0PVccjbPauknrIQtM=; b=Cpd6+baZ6EHQi9hUp2jVIUUGZByQauAXprpcwwmASwbC6CiqTlHpPxjJopBc2bygCU KdDDvZrutQS+t8m3Wp3CbW1lN/AYVrdHB7mi2IPtWA2LhaYxZJLOHd9pEhg1rd02ccS7 g4+rK22ABlb2YRP/gxKp3pXruLxWM2pS64QDo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1+KMEU9nLAyfnLONDvqLidSgbB0PVccjbPauknrIQtM=; b=RbPr9jNCHvQMM+bG8jP1Yy8aDEwuUBf4B+p1Ff65i/7mvYTrK9hvbeLFEp9GujdDst tfq/ACLKfrf5zZdAuZqHqgsdWAoE+RuRQgNr99sCEpCs6RQPNYTJwk2dcGUu/dHsHPBQ HiRqI4OsU0EKwXjXae8uMATOvFP3gkQx0OUUaz7+CgLy/oXN3u6p3bEEjFd43HJMGRWX wUxw4Zsk45wIheYu5mRTV5J9kSRm+S4qi7uO/3bAgq9Ij6MMeNG9Um2km5cVrSCQXTwG dd31m+H1wr2/nopnaUeDU0ljYd6RdvUafB/diGZomx58OGnjIKg+ftMm6oqHVMqve/V1 KWtw== X-Gm-Message-State: APjAAAW2kay7tuP1YdRckdVG3U2+XcOT3pbkEd8p1ZLbFUaf3i8wMu3n gd1RR+Ot1SMllUos5SiTE2ndcw== X-Google-Smtp-Source: APXvYqwyVChGwgV22ltg9+oMJq5x/NnI4qHyA2Xi+7OP2XVAyNI5EHaNd47b2LOjclSzaZl+BekcSw== X-Received: by 2002:a24:5285:: with SMTP id d127mr935837itb.72.1559841980383; Thu, 06 Jun 2019 10:26:20 -0700 (PDT) Received: from [192.168.1.50] (198-84-196-112.cpe.teksavvy.com. [198.84.196.112]) by smtp.gmail.com with ESMTPSA id y134sm1300356ity.40.2019.06.06.10.26.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2019 10:26:19 -0700 (PDT) From: Joe Abley Message-Id: <25D432C1-80C8-4ECD-B80F-F2021363BDFF@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_257C9E8E-C68F-4452-8938-D960681C4658"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 6 Jun 2019 13:26:16 -0400 In-Reply-To: <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz> Cc: "doh@ietf.org" , Paul Hoffman , Christoph , Patrick McManus , Mark Delany To: =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:26:23 -0000 --Apple-Mail=_257C9E8E-C68F-4452-8938-D960681C4658 Content-Type: multipart/alternative; boundary="Apple-Mail=_4E5426F1-D962-4FF1-BE6D-66CB7F8728CE" --Apple-Mail=_4E5426F1-D962-4FF1-BE6D-66CB7F8728CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 6 Jun 2019, at 13:14, Vladim=C3=ADr =C4=8Cun=C3=A1t = wrote: > On 6/2/19 5:54 PM, Joe Abley wrote: >> - I want an answer to the question PIR.ORG/IN/SOA = with RD=3D1 >> - 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). >=20 I haven't thought about this very hard so this is not really an opinion, = but I agree: it seems sensible that if there is some kind of = request/require capabilities work to be done it shouldn't be = transport-specific. Joe --Apple-Mail=_4E5426F1-D962-4FF1-BE6D-66CB7F8728CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 6 Jun 2019, at 13:14, Vladim=C3=ADr =C4=8Cun=C3=A1t <vladimir.cunat+ietf@nic.cz> wrote:

=20 =20
On 6/2/19 5:54 PM, Joe Abley = wrote:
 - I want an answer to the question PIR.ORG/IN/SOA with RD=3D1
 - 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).

I haven't thought about = this very hard so this is not really an opinion, but I agree: it seems = sensible that if there is some kind of request/require capabilities work = to be done it shouldn't be transport-specific.


Joe

= --Apple-Mail=_4E5426F1-D962-4FF1-BE6D-66CB7F8728CE-- --Apple-Mail=_257C9E8E-C68F-4452-8938-D960681C4658 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXPlMuQAKCRA0jwy9hlI6 LK0bAKCctnRsnGuCq77iT/M49/+J9KAOKQCfYFN0CzWvH9LhH56Iss4E7q/7yhI= =/3GH -----END PGP SIGNATURE----- --Apple-Mail=_257C9E8E-C68F-4452-8938-D960681C4658-- From nobody Thu Jun 6 12:09:42 2019 Return-Path: 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 ; 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 ; 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 ; 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 ; 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> <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz> In-Reply-To: <2309d053-0bd2-25fe-ea56-b3bbb258225a@nic.cz> From: Patrick McManus Date: Thu, 6 Jun 2019 15:09:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Cc: "doh@ietf.org" , Paul Hoffman , Christoph , Patrick McManus , Mark Delany , Joe Abley Content-Type: multipart/alternative; boundary="000000000000766729058aac743a" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 19:09:41 -0000 --000000000000766729058aac743a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 6, 2019 at 1:14 PM Vladim=C3=ADr =C4=8Cun=C3=A1t wrote: > > On 6/1/19 11:22 PM, Patrick McManus wrote: > > 8484 does not, and really cannot, proscribe the error handling for whethe= r > 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 abou= t > 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. --000000000000766729058aac743a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 6, 2019 at 1:14 PM Vladim= =C3=ADr =C4=8Cun=C3=A1t <vladimir.cunat+ietf@nic.cz> wrote:
=20 =20 =20

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=C2=A0t= he issue

I fail to see reasons why an RFC can't (or shouldn't) specif= y behavior around unknown parts in the URL.=C2=A0 In this case I suspec= t that a clear decision will be better than leaving it unspecified, regardless of which way it will be decided.=C2=A0 I believe th= e 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 tha= t template are defined by 8484, but HTTP servers certainly can implement ot= her services (such as the hypothetical doh fixup gateway) on other URIs and= 8484 cannot define them. This independence is an important part of HTTP. S= o this particular boundary is a really hard place to put a hard error requi= rement on.=C2=A0



=C2= =A0
--000000000000766729058aac743a-- From nobody Sun Jun 9 01:37:32 2019 Return-Path: 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 18BD012013F for ; Sun, 9 Jun 2019 01:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 H8b9CF5z7UhD for ; Sun, 9 Jun 2019 01:37:28 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5F87A120058 for ; Sun, 9 Jun 2019 01:37:27 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 636A23AFF7; Sun, 9 Jun 2019 18:37:24 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1560069444; bh=zx/wNJU5ALVblZLN61dDZ++nMUo=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=DMnkyJ+rQOymPKA6UhI2ckmUeNFBSeuU0q987Ho/5Y4pd4gHRCJo3ix6CvJrrrnc9 gKX3O9sS3kZUUOgktswAOt6FMXeFPSmR/4LCyHgPF1vTpRPBmNEsS7gcsFgXHDRx2M FTZvUfkUGUheMbYy9yHn77zGYRypV8x6KjMcNIoQ=cNIoQ= Comments: QMDA 0.3a Received: (qmail 23966 invoked by uid 1001); 9 Jun 2019 08:37:24 -0000 Date: 9 Jun 2019 08:37:24 +0000 Message-ID: <20190609083724.23965.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 08:37:30 -0000 On 19May19, Ben Schwartz allegedly wrote: > In practice, none of this seems to be a problem. DoH servers simply do > their best to fully answer the query I know this is getting close to flogging a dead horse, but I'm still troubled by the silent truncation implied by a DoH Server processing TC=1. Notwithstanding clients which directly connect to DoH servers (such as some browsers) the typical scenario is likely to be existing stub clients using UDP to talk to a DoH proxy/client which in turn talks to a DoH server, i.e.: stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> resolver stub (UDP) <- DoH proxy (HTTPS) <- DoH server (UDP) <- resolver (Sorry, you'll need to render this in a fixed-width font). As I understand Ben's response, if the resolver returns TC=1 then a typical DoH server (or its resolver library) will retry with TCP which makes the flow for a large response actually look like: stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> resolver DoH server (UDP) <- (TC=1) resolver DoH server (TCP) -> resolver stub (UDP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- (TC=0) resolver Which certainly meets the "do their best to fully answer the query" as the stub never has to worry about TC=1 and simply gets the "full result". However... It makes me wonder how a large TCP response the DoH Server sends back via HTTPS can possibly fit into the response the DoH proxy sends back via UDP to the stub. Let's say the DoH proxy receives a 5K response over HTTPS, does it blindly try and transmit this 5K response over UDP back to the stub and just hope for the best? Or should it know this is likely to fail and act accordingly? If so, how should it act? I can't think of what a DoH proxy can sensibly do in such circumstances apart from arbitrarily truncate the response down to the UDP size indicated by the stub and *not* mark the response with TC=1. Thus the stub loses some of the answer and more importantly loses knowledge of the truncation. That seems bad to me. As we've discussed previously, it's pointless returning TC=1 to the stub as it will simply re-issue an identical query as far as the DoH server is concerned. Note that I said "identical query as far as the DoH server is concerned". The same is not the case for the DoH proxy as the query re-issued from the stub *can* be disambiguated since the stub connects to the proxy via TCP. Which offers a possible solution. Since a proxy knows whether the inbound query has come via UDP or TCP it can annotate the HTTPS request accordingly (let's invent a "Use-TCP" header). The DoH server acts on this header thus the flow becomes: stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> resolver stub (UDP) <- (TC=1) DoH proxy (HTTPS) <- DoH server (UDP) <- (TC=1) resolver stub (TCP) -> DoH proxy (HTTPS - Use-TCP) -> DoH server (TCP) -> resolver stub (TCP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- (TC=0) resolver IOWs TC=1 is sent all the way back to the stub for it to deal with. If the stub re-queries with TCP, the proxy forwards the query with the "Use-TCP" annotation to the DoH server which in turn instructs its resolver library to use TCP. Not only does this alleviate a DoH server from trying their best to "fully answer the query" in the blind, it also avoids the impossibility of transmitting a large response back to the stub over UDP. Most importantly truncation is no longer silently performed - rather it is communicated back to the stub which lets it decide what to do as has traditionally been the case. I think all stubs should work in this "Use-TCP" scenario whereas clearly they cannot in the "DoH server transparently handles TC=1" scenario. The one down-side is that a TC=1 response incurs higher latency due to the flow going all the way back to the stub for a retry, however given these TC=1 responses are uncommon, that seems like a minor price to pay for a consistent outcome. Mark. From nobody Sun Jun 9 10:04:41 2019 Return-Path: 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 80F281200D7 for ; Sun, 9 Jun 2019 10:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 NhS6hDVtlWyt for ; Sun, 9 Jun 2019 10:04:36 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D081200B7 for ; Sun, 9 Jun 2019 10:04:35 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id v69so1246325vke.0 for ; Sun, 09 Jun 2019 10:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=XMWjs7oDN5btOcaJ48/z5GxdUbN3LHZaQsdM8TUsqQdMwSnfE9YKrpX2oAM6Cc08jo NdmS6w4Jz+lTkte1qFUhyF5y3+i24KFaUfFkxnJd+FOOgeADVlxKa48M81sETwV7Q8ev CtbJht3zrBoy3s3uZqdEFgOxcx02JAVWeSnZmHO5f6FwnLcieHuWc49eUbT1+iEef37h bQsCdt5u5+idY2wTCqMfpIWs/RUQ4rPmSPhz3A15TOaZV5iM8UhaxETHpVaBDzCKVyVK WzA+6Kc6WwPTDIUFVY0rdZw848J2z16o2+AMFo4jQl7YhH+66utT/PH4gkcyzZMrz97L oYTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=kBcYCHoIO/SiI96L0v3VUlhBIyzh4Plt+QxXGB5kYLUXeFTAqaS5saPIPrm9GBpMQh 5e7HYEprjKBeBR+HXQizyo5J++bIbC/5ROcyJG8nIQ7BTas+lTCn3EM+IVUASbJ59uPz OlcamO/OwgSL7Zhg8rJuxz3Gjab/FvlzlRdoBIpRtgtNVdYK6pVra/vzVixkLAoCq2zS VC7dHLl2zHtNDsaTohqajr23LiSxl5wZ1BHmKmJnxp5g1ciTuzTrQoyrsQW70bVKtm9M ec8GXUPZUjARQkLZ+tKAOjofvoVf21wg3DD+/LxQUG2chhE2T1MMHmpXW0jjbnXWgxJH xPtg== X-Gm-Message-State: APjAAAXI741sZSkpNTiIvIEfN+ISHCqYgQWknIsgxgyGnX7veCsbhwMX BEsLSDoBeifYFLvyezmqqkhxwtgEBX7Qp/UzWPlsM0nD0G8= X-Google-Smtp-Source: APXvYqyUVJTOal0Olu8tO2Wfh3PoAG6HOXLI3VleZCb4KS/bWo/aGDh8UU0mu+ZZe7pCPRhkRT06f7zbZZMS+3XnQwM= X-Received: by 2002:a1f:ccc4:: with SMTP id c187mr23679234vkg.56.1560099874222; Sun, 09 Jun 2019 10:04:34 -0700 (PDT) MIME-Version: 1.0 References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> <20190609083724.23965.qmail@f3-external.bushwire.net> In-Reply-To: <20190609083724.23965.qmail@f3-external.bushwire.net> From: Ben Schwartz Date: Sun, 9 Jun 2019 13:04:22 -0400 Message-ID: To: Mark Delany Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d9b63e058ae70eac" Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 17:04:40 -0000 --000000000000d9b63e058ae70eac Content-Type: multipart/alternative; boundary="000000000000d1966f058ae70e90" --000000000000d1966f058ae70e90 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 9, 2019, 4:37 AM Mark Delany wrote: > On 19May19, Ben Schwartz allegedly wrote: > > > In practice, none of this seems to be a problem. DoH servers simply do > > their best to fully answer the query > > I know this is getting close to flogging a dead horse, but I'm still > troubled by > the silent truncation implied by a DoH Server processing TC=1. > > Notwithstanding clients which directly connect to DoH servers (such as some > browsers) the typical scenario is likely to be existing stub clients using > UDP > to talk to a DoH proxy/client which in turn talks to a DoH server, i.e.: > > stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> resolver > stub (UDP) <- DoH proxy (HTTPS) <- DoH server (UDP) <- resolver > > (Sorry, you'll need to render this in a fixed-width font). > > As I understand Ben's response, if the resolver returns TC=1 then a > typical DoH > server (or its resolver library) will retry with TCP which makes the flow > for a > large response actually look like: > > stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> resolver > DoH server (UDP) <- (TC=1) > resolver > DoH server (TCP) -> resolver > stub (UDP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- (TC=0) > resolver > > Which certainly meets the "do their best to fully answer the query" as the > stub > never has to worry about TC=1 and simply gets the "full result". > > However... It makes me wonder how a large TCP response the DoH Server > sends back > via HTTPS can possibly fit into the response the DoH proxy sends back via > UDP to > the stub. > > Let's say the DoH proxy receives a 5K response over HTTPS, does it blindly > try > and transmit this 5K response over UDP back to the stub and just hope for > the > best? Or should it know this is likely to fail and act accordingly? If so, > how > should it act? > > I can't think of what a DoH proxy can sensibly do in such circumstances > apart > from arbitrarily truncate the response down to the UDP size indicated by > the > stub and *not* mark the response with TC=1. I don't understand your logic. From my perspective, the obvious thing for this proxy to do is to truncate the response, and set TC=1 if truncation occurred. Truncating without setting TC=1 seems like a violation of the DNS protocol. Thus the stub loses some of the > answer and more importantly loses knowledge of the truncation. That seems > bad to > me. > > As we've discussed previously, it's pointless returning TC=1 to the stub > as it > will simply re-issue an identical query as far as the DoH server is > concerned. > > Note that I said "identical query as far as the DoH server is concerned". > The > same is not the case for the DoH proxy as the query re-issued from the stub > *can* be disambiguated since the stub connects to the proxy via TCP. > Indeed. It seems obvious to me that the proxy will not truncate the response to a query that arrived over TCP, since truncation is not required for DNS-over-TCP, and therefore the full query will succeed from the stub's perspective. To summarize, a proxy that does the simplest thing to comply with DNS and DoH RFCs will correctly deliver full responses to the stub without requiring any changes to either protocol. Which offers a possible solution. > > Since a proxy knows whether the inbound query has come via UDP or TCP it > can > annotate the HTTPS request accordingly (let's invent a "Use-TCP" > header). The DoH server acts on this header thus the flow becomes: > > stub (UDP) -> DoH proxy (HTTPS) -> DoH server (UDP) -> > resolver > stub (UDP) <- (TC=1) DoH proxy (HTTPS) <- DoH server (UDP) <- > (TC=1) resolver > stub (TCP) -> DoH proxy (HTTPS - Use-TCP) -> DoH server (TCP) -> > resolver > stub (TCP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- > (TC=0) resolver > > IOWs TC=1 is sent all the way back to the stub for it to deal with. If the > stub > re-queries with TCP, the proxy forwards the query with the "Use-TCP" > annotation > to the DoH server which in turn instructs its resolver library to use TCP. > > Not only does this alleviate a DoH server from trying their best to "fully > answer the query" in the blind, it also avoids the impossibility of > transmitting > a large response back to the stub over UDP. Most importantly truncation is > no > longer silently performed - rather it is communicated back to the stub > which > lets it decide what to do as has traditionally been the case. > > I think all stubs should work in this "Use-TCP" scenario whereas clearly > they > cannot in the "DoH server transparently handles TC=1" scenario. > > The one down-side is that a TC=1 response incurs higher latency due to the > flow > going all the way back to the stub for a retry, however given these TC=1 > responses are uncommon, that seems like a minor price to pay for a > consistent > outcome. > > > Mark. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000d1966f058ae70e90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 9, 2019, 4:37 AM Mark Del= any <d5e@xray.emu.s= t> wrote:
On 19May19, Ben Sc= hwartz allegedly wrote:

> In practice, none of this seems to be a problem.=C2=A0 DoH servers sim= ply do
> their best to fully answer the query

I know this is getting close to flogging a dead horse, but I'm still tr= oubled by
the silent truncation implied by a DoH Server processing TC=3D1.

Notwithstanding clients which directly connect to DoH servers (such as some=
browsers) the typical scenario is likely to be existing stub clients using = UDP
to talk to a DoH proxy/client which in turn talks to a DoH server, i.e.:
=C2=A0stub (UDP) ->=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoH proxy (HTTPS) -> D= oH server (UDP) -> resolver
=C2=A0stub (UDP) <-=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoH proxy (HTTPS) <- D= oH server (UDP) <- resolver

(Sorry, you'll need to render this in a fixed-width font).

As I understand Ben's response, if the resolver returns TC=3D1 then a t= ypical DoH
server (or its resolver library) will retry with TCP which makes the flow f= or a
large response actually look like:

=C2=A0stub (UDP) ->=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoH proxy (HTTPS) -> D= oH server (UDP) -> resolver
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0DoH server (UDP) <- (TC=3D1) resolver
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0DoH server (TCP) -> resolver
=C2=A0stub (UDP) <- (TC=3D0) DoH proxy (HTTPS) <- DoH server (TCP) &l= t;- (TC=3D0) resolver

Which certainly meets the "do their best to fully answer the query&quo= t; as the stub
never has to worry about TC=3D1 and simply gets the "full result"= .

However... It makes me wonder how a large TCP response the DoH Server sends= back
via HTTPS can possibly fit into the response the DoH proxy sends back via U= DP to
the stub.

Let's say the DoH proxy receives a 5K response over HTTPS, does it blin= dly try
and transmit this 5K response over UDP back to the stub and just hope for t= he
best? Or should it know this is likely to fail and act accordingly? If so, = how
should it act?

I can't think of what a DoH proxy can sensibly do in such circumstances= apart
from arbitrarily truncate the response down to the UDP size indicated by th= e
stub and *not* mark the response with TC=3D1.

I don't understand your logic.= =C2=A0 From my perspective, the obvious thing for this proxy to do is to tr= uncate the response, and set TC=3D1 if truncation occurred.=C2=A0 Truncatin= g without setting TC=3D1 seems like a violation of the DNS protocol.
<= div dir=3D"auto">
Thus the stub loses some of the
answer and more importantly loses knowledge of the truncation. That seems b= ad to
me.

As we've discussed previously, it's pointless returning TC=3D1 to t= he stub as it
will simply re-issue an identical query as far as the DoH server is concern= ed.

Note that I said "identical query as far as the DoH server is concerne= d". The
same is not the case for the DoH proxy as the query re-issued from the stub=
*can* be disambiguated since the stub connects to the proxy via TCP.

Indeed.=C2=A0 It seems obvious to me that the= proxy will not truncate the response to a query that arrived over TCP, sin= ce truncation is not required for DNS-over-TCP, and therefore the full quer= y will succeed from the stub's perspective.=C2=A0 To summarize, a proxy= that does the simplest thing to comply with DNS and DoH RFCs will correctl= y deliver full responses to the stub without requiring any changes to eithe= r protocol.

Which offers a possible solution.

Since a proxy knows whether the inbound query has come via UDP or TCP it ca= n
annotate the HTTPS request accordingly (let's invent a "Use-TCP&qu= ot;
header). The DoH server acts on this header thus the flow becomes:

=C2=A0stub (UDP) ->=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoH proxy (HTTPS)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> DoH server (UDP) -> resolver
=C2=A0stub (UDP) <- (TC=3D1) DoH proxy (HTTPS)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<- DoH server (UDP) <- (TC=3D1) resolver
=C2=A0stub (TCP) ->=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoH proxy (HTTPS - Use-TC= P) -> DoH server (TCP) -> resolver
=C2=A0stub (TCP) <- (TC=3D0) DoH proxy (HTTPS)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<- DoH server (TCP) <- (TC=3D0) resolver

IOWs TC=3D1 is sent all the way back to the stub for it to deal with. If th= e stub
re-queries with TCP, the proxy forwards the query with the "Use-TCP&qu= ot; annotation
to the DoH server which in turn instructs its resolver library to use TCP.<= br>
Not only does this alleviate a DoH server from trying their best to "f= ully
answer the query" in the blind, it also avoids the impossibility of tr= ansmitting
a large response back to the stub over UDP. Most importantly truncation is = no
longer silently performed - rather it is communicated back to the stub whic= h
lets it decide what to do as has traditionally been the case.

I think all stubs should work in this "Use-TCP" scenario whereas = clearly they
cannot in the "DoH server transparently handles TC=3D1" scenario.=

The one down-side is that a TC=3D1 response incurs higher latency due to th= e flow
going all the way back to the stub for a retry, however given these TC=3D1<= br> responses are uncommon, that seems like a minor price to pay for a consiste= nt
outcome.


Mark.

_______________________________________________
Doh mailing list
Doh@ie= tf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000d1966f058ae70e90-- --000000000000d9b63e058ae70eac Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBRM1DG5BKGY4jT2pW80NOy f1GPUAa/48fjCIOLP188nDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA2MDkxNzA0MzRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAHJxUUDUAD0BEa3IBBD33qms8Oja3FOIGVD9t7P1W 2cPEgUmvpVrJdNaiIQb3mLscKuFgHybb7G+f/ip3PJg+I797wyn17WMu83F/hehhleCQu/IXHig0 uiNceyld/aKlwCMB2er/GA0yqtzxS8Huuz3uHgT1SB6lp+tXe3p84xJeel3/RL3slCjIL1+ULN5o Ga5j6MYBS+oWQ8iF3KL7iKV1pLYCYFFxycCP0htQwyckbgkDgnWdvjOkFOkLoN4UTmlo+u2VNtzU us9JdFqnKtapXKrh9PnImTTYNMimjR9Lg1DzzoYYb+Oamnujdzt2I01BWHTgOo2NRHs57ZLCzg== --000000000000d9b63e058ae70eac-- From nobody Sun Jun 9 13:08:28 2019 Return-Path: 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 9C1E8120121 for ; Sun, 9 Jun 2019 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 Nhgy7uTCAced for ; Sun, 9 Jun 2019 13:08:25 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3110A120108 for ; Sun, 9 Jun 2019 13:08:25 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id F11563AFF8; Mon, 10 Jun 2019 06:08:20 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1560110900; bh=6iHSa1YsYANedi2II72xcH9sAso=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=NfJRLl4k1dmdx+ECo7y6kq5r1KQsZc6nHzt4FZijs9+oKez9DQXB8TZGjXmLQKVir f5QRx+CUV0HuTEdGbW5G39Cmzz2qChMaKHavEsbQ0ES6uDTv0WQxcOllHOU64/8GOE Ka+UC3MA7O1lvC/xwESU63v41lLENZ2flvD/DG18=/DG18= Comments: QMDA 0.3a Received: (qmail 26161 invoked by uid 1001); 9 Jun 2019 20:08:20 -0000 Date: 9 Jun 2019 20:08:20 +0000 Message-ID: <20190609200820.26160.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> <20190609083724.23965.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 20:08:27 -0000 > I don't understand your logic. Bah humbug. Nor do I now that I have a bit more of a think about it. Just shows that coming back fresh isn't all it's cracked up to be... For some reason I was thinking the stub would retry with UDP which of course it won't. It's just an observation but if a DoH server "fully answers" it means that when a proxy does have to locally truncate a response to fit into UDP it means that the DoH server will ultimately issue the query four times. Stub UDP -> Proxy HTTPS -> DoH Server -> UDP resolver Query 1 <- TC=1 UDP -> TCP Query 2 UDP TC=1 <- (proxy truncates <- TCP to fit into UDP) (Stub retries with TCP due to TC=1 from proxy) Stub TCP -> Proxy HTTPS -> DoH Server -> UDP resolver Query 3 <- TC=1 UDP -> TCP Query 4 UDP TC=0 <- (proxy doesn't need to <- TCP truncate for TCP) No big deal I suppose since over-sized responses are meant to be a uncommon and of course the proxy could cache locally truncated responses for a couple of seconds if it wanted to bother. Mark. From nobody Wed Jun 19 09:05:09 2019 Return-Path: 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 22D4B12017C for ; Wed, 19 Jun 2019 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=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 Ih1JZjuJsU3R for ; Wed, 19 Jun 2019 09:05:05 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 3F358120140 for ; Wed, 19 Jun 2019 09:05:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:37796) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hdd54-001H3A-ct (Exim 4.92) (return-path ); Wed, 19 Jun 2019 17:05:02 +0100 Date: Wed, 19 Jun 2019 17:05:01 +0100 From: Tony Finch To: Mark Delany cc: doh@ietf.org In-Reply-To: <20190609083724.23965.qmail@f3-external.bushwire.net> Message-ID: References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> <20190609083724.23965.qmail@f3-external.bushwire.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 16:05:07 -0000 Mark Delany wrote: > > As we've discussed previously, it's pointless returning TC=1 to the stub as it > will simply re-issue an identical query as far as the DoH server is concerned. TC=1 implies that the client should retry using a different transport that can handle larger messages. If your transport is not UDP, there aren't any alternatives that can handle larger messages :-) You *can* get TC=1 on TCP etc, because it is possible to create an RRset that is larger than 65536 octets. Tony. -- f.anthony.n.finch http://dotat.at/ the widest possible distribution of wealth From nobody Thu Jun 27 06:40:27 2019 Return-Path: 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 0034C12013C for ; Thu, 27 Jun 2019 06:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.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 diCAHMm-cnGi for ; Thu, 27 Jun 2019 06:40:25 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D682312012C for ; Thu, 27 Jun 2019 06:40:24 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id 190so1628981vsf.9 for ; Thu, 27 Jun 2019 06:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=imOA2L/rHT6J/4vsNSY1uHOjdKPSVegpaOBb1Oy0/ik=; b=e9PNPu6jFAzCpdX0E11Jf8XVbblvY9/GZ7Z6rmnZZt2N34qFFjvbeztlDMBrnDLTDy R3AaX/xbahnErsC7FJCWFo7ka98VQA4KhHp9h7R6OA+SGAT4iwxrfIpmmlsn4nVwkxCQ fGR/4tYpedvMOvZmHx6NjcUzJLCQp0BMbHVG4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=imOA2L/rHT6J/4vsNSY1uHOjdKPSVegpaOBb1Oy0/ik=; b=hVCmPdY+XbSeqbptCVmheNSgNQjvp/lp1k/UC/7akNgcUE8P9XIKFYex6D/5onenGb wlmZ1zxEjvkpCqhRRyjYoPsoFsfH3COZanIxJbfYhso5vJH4NDE5T7B7mxYeZIIyFdfT V7g2brNLCNXqzJTgFatavI1h9qSyWXNzstgbnE/UvZEzK8QC1UdaPLLX8fHOF4QW4AqI DWX03k/Ck3+ba2ooQ/18tC8QedZzgF6cFadF77FYVaj9VzORzKnvdI8FR1NUtOFuRSfN nrAeE1De0FqjR73N16IxSSb5gwzFo8EDvTXkH9Or1++xDZR5yZ7aJnI2Iz5H4qm3paTl 4M0g== X-Gm-Message-State: APjAAAUR0MH/zAGSHC8ovvhX1lwCnlcxqckfFxTVLI8qtDXId4u1Treh l5uhta3Dl9kNG4r+Gise1bK6/F33byA8WMEudiRBZ95yPL5ysw== X-Google-Smtp-Source: APXvYqz01iHpTcgNNiWNhCiteLITDsGNBvTI0rVbiWzg4jK7DkO3O5fZZanj9hh+75YAfHBPBiqDww7VZCgVNA5CNW4= X-Received: by 2002:a67:e8c5:: with SMTP id y5mr2578179vsn.127.1561642823390; Thu, 27 Jun 2019 06:40:23 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Thu, 27 Jun 2019 15:40:12 +0200 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Doh] Call for Presentations: 31st DNS-OARC Workshop, Austin, Texas, Oct 31 - Nov 01 2019 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 13:40:27 -0000 The 31st DNS-OARC Workshop will take place at the JW Marriott Austin in Austin, Texas, USA on October 31st and November 1st 2019. It is co-located with and will take place right after NANOG 77 (Oct 27th to Oct 30th 2019). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. There will be an OARC Business and AGM session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 25 Jun 2019 - Submissions open via Indico 16 Aug 2019 - Deadline for submission (midnight CDT) 28 Aug 2019 - Initial Contribution list published 28 Sep 2019 - Full agenda published 18 Oct 2019 - Deadline for slideset submission 31 Oct 2019 - Workshop Details for presentation submission are published here: The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Jan V=C4=8Del=C3=A1k, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From nobody Thu Jun 27 22:53:48 2019 Return-Path: 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 24991120124 for ; Thu, 27 Jun 2019 22:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=emu.st 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 dQld0TH8Sk5E for ; Thu, 27 Jun 2019 22:53:44 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5083712001B for ; Thu, 27 Jun 2019 22:53:43 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id E2C943B0C2; Fri, 28 Jun 2019 15:53:40 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1561701220; bh=0/kE0ExcBdJxE4h2Rnx4tLdEMkc=; h=Comments:Received:Date:Message-ID:From:To:Subject:MIME-Version: Content-Type:Content-Disposition; b=cyKmJQVrDPRfUDuUfFCjs6K6DU03UiPXj+R2xw7LBNW6IJh1tc/m5M2HwZTwrfGfY jhBYCPTAvkUzZD1DjIdCHouGUP3YMZOj4HLDjS2loL8dCKUCWoGesH1Su/3gKEA7YL c5pdc2lSbOKznEcR49QnomALALV1cmq0BY0gx/uU=gx/uU= Comments: QMDA 0.3a Received: (qmail 46147 invoked by uid 1001); 28 Jun 2019 05:53:40 -0000 Date: 28 Jun 2019 05:53:40 +0000 Message-ID: <20190628055340.46146.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Archived-At: Subject: [Doh] trustydns - another DoH implementation to add to the mix X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 05:53:46 -0000 Some time ago on 18Apr2019, I wrote: > I'm working on a proxy/server DoH implementation designed to install on CPE > and a private DoH server respectively. trustydns has been working on my networks for a while so time to let others find some bugs. https://github.com/markdingo/trustydns I've incorporated pretty much all the feedback and advice that others on this list have provided so hopefully it's a well-behaved addition to the family. Mark.