From nobody Mon Apr 2 18:44:14 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DDB126CBF; Mon, 2 Apr 2018 18:44:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152271985261.14004.9961915464941726907@ietfa.amsl.com> Date: Mon, 02 Apr 2018 18:44:12 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-05.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 01:44:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-05.txt Pages : 17 Date : 2018-04-02 Abstract: This document describes how to run DNS service over HTTP using https:// URIs. [[ There is a repository for this draft at https://github.com/dohwg/ draft-ietf-doh-dns-over-https [1] ]]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 2 23:41:29 2018 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 B4DF812E040 for ; Mon, 2 Apr 2018 23:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 nGAKY4shEssX for ; Mon, 2 Apr 2018 23:41:27 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010101.outbound.protection.outlook.com [40.92.10.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DEE12E03C for ; Mon, 2 Apr 2018 23:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cUZTOO0LC2aE0yzQ+9hV0MhG4/DVTeRUYjIKGbL778E=; b=mHVxEyBSzSOoJvxoqSUAm651Coptva8K9L5OsroeCQJoIBuRqwVnMZyobJ7CHSpY3XYSDZchvBpL6GT3pzlny6uHnmpd6ZIkkRqOC7bsBbd7nS1KILOqZf3EIkLsF5EgC1s1QneZnxL0GEumnHYOALED2i+Vfn4k074D1G6HXiwobrYPK2TZrYil68ik77QEaed30bnrl9O2b1sqexKfulih8uhYCOyFA42IRFMF8Hm1l20tPFYnZGhYPAxupXo+JLaMJ4WxhZmFTHFxKX7ZDFYb5asp0e5TxsYfSYuBketDVpr28tDCIj560dxB9a6kOFJ8ORv9/wf5Q0PuTm0rdg== Received: from CO1NAM04FT035.eop-NAM04.prod.protection.outlook.com (10.152.90.52) by CO1NAM04HT043.eop-NAM04.prod.protection.outlook.com (10.152.90.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.631.7; Tue, 3 Apr 2018 06:41:26 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.90.53) by CO1NAM04FT035.mail.protection.outlook.com (10.152.90.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8 via Frontend Transport; Tue, 3 Apr 2018 06:41:26 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::49ab:17a3:df4c:17d9]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::49ab:17a3:df4c:17d9%13]) with mapi id 15.20.0631.013; Tue, 3 Apr 2018 06:41:26 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: Minor issues on word usage in draft-05 Thread-Index: AQHTyxXXXlpoyg1H/UiJP+89bx+YTQ== Date: Tue, 3 Apr 2018 06:41:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:E88A8452CE2D8FAAB333AA12DFAD477FC23D4E129674E461A1C8A06735FEA05B; UpperCasedChecksum:BCEA0354C1E0BDE86B792CDD1A4C17F8215B0E61D07734C325B3D6E447B818B3; SizeAsReceived:6932; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [1oxmGm43xlGscxZxEECJMeZOuviHLhAmRvsAJ3dheYr7l2pCr8BOiA==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT043; 7:ytNxPuBFruk0HiymgL51s+JgkEoX1O8ju2jIL1qo8W5uRGqx+kiepgeNLMxzWzCVTuBmTpN+Oub9AmP6TJFgGnuI/OsF/rLnAHw/q0xSFoH4QwEiAwjCZRrWfsq1hMeC4925ZbqKc2myfo3rtbqXudZnmmMZVu8JX/I6O2Y+Tr1tKH8UyRIT9VjkNPXHKIvrzoPaUhy/9jMSr+iKK1OcddHAZgiD4DcubZTcbTUIA7lrMt1jml4Y56MTTjnKLE2Z x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:CO1NAM04HT043; x-ms-traffictypediagnostic: CO1NAM04HT043: x-ms-office365-filtering-correlation-id: 2774e40f-91f6-472b-bc71-08d5992dec9a x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM04HT043; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT043; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT043; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: wzbmGZ2msQVxCFJagMBmdIRC3YZSHeT/QfqxyDXNjPS+xQZ10bwt0HUyVD2udamvPFfNShmtTHV5o34hyfkei3dWLhOeAR5GhjmbB1vefxiw828SMGyp/AM43ER7nIpHBEu22haa2oNkJmyjqwLs1DV2CA0fINXIxQpe1ehsu/5UxfiycUm8V9jPWgBXB9Cs spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2774e40f-91f6-472b-bc71-08d5992dec9a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 06:41:26.4310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT043 Archived-At: Subject: [Doh] Minor issues on word usage in draft-05 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 06:41:29 -0000 Hello DOHWG, In the latest draft-05, I found several minor issues on word usage. In Section 4, > The URI template defined in this document is processed without any > variables for requests using POST, and with the single variable "dns" > for requests using GET. The value of the dns parameter is the > content of the request (as described in Section 4.1), encoded with > base64url [RFC4648]. Issue 1: I found the phrase "URI template" is spelled with a lower "t", whe= re all other occurrences of this phrase is spelled with an upper "T". Is th= is a typo? Issue 2: I suggest we change the word "and" in Line 2 to "or", for the reas= on that an HTTP request could not be both GET and POST. Thanks. --=20 Star Brilliant m13253@hotmail.com= From nobody Tue Apr 3 00:33:36 2018 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 00DA012E042; Tue, 3 Apr 2018 00:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=gmail.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 Pkz81NU1LPXh; Tue, 3 Apr 2018 00:33:29 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 D7E0C124205; Tue, 3 Apr 2018 00:33:28 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x9-v6so15095239oig.7; Tue, 03 Apr 2018 00:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xizg3Emz8ih22rVpbemB4uE2/LzTo9M0oPHpAJchoO8=; b=i2z+PzQa/1N5cbMiu2rk9V/SbKrUMeuwAJTeVfPhCeHIFVG6OFrn0Ytw6D6ftRnWlb msb3QXOuSjQyZeVmxLGHCOal3ZawhKg8KnJxfLlNljjN5u7qVMF1hJ+iTNRGiDFgQQuC frvIDPlefnpE5iV7i0mLQXEyMpptv7A57H/DG+YHU9RFvFCnZdYzrkm5yUQAhP2xPNw/ cWIpWnSJj5XRO3gLGsZiazkDye4cSCUTw3ByblvPLFB1rnyDny2JZ6EKZURO5ztTdFZB mIjYPodM+w/N4r+XtFYcZdCgqq26QUR79z3LgehIyT+jt7hJ8IGou5ct1fH3jJa7uZY5 Ov6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xizg3Emz8ih22rVpbemB4uE2/LzTo9M0oPHpAJchoO8=; b=U0UMcNf8YVARt8tKFW9u9y8Ow6EmEEkaAFd6pqiZxzDxdHWbVL3I6pmbMpmZ6/IqYW HDpwiv18B63Hd/pBmCYsYHOYkRWaWIGtulNx+8MnUlWV3SkcDQJf6+iFqSdy+Y5PnIQK TpQxTYRJP31lqprswH8RPDwAydsuS3+us6dyiVnCuJe4RfPCla9TMszjf2ZG5qnSPvle CO9bo8Ce5G/uZHfHT7h0Ww52nHo+HjGIgWbUu0c7YvjUXpRjj1tYYfiEa55gs/F5z9Oo u8IiBnmbbpdjMVNRVNz6aATnVMNQ++2VSvlopJ3+YpE0+154DQ6OQX6atkV2VmoQApjs 8SeA== X-Gm-Message-State: ALQs6tDOxCM7Z0G5f8B4HrLqzJeHdg1N/8v6K8820zz/hW+weeBoh/0b Pqu3XWC6xfZh4LuhuRL5SRmyKXz7yYm9huHkqKr00AAw X-Google-Smtp-Source: AIpwx4/bIrnvfEx+62xjKRXbzBGySw48c4darYLh5k0n3gXfxi1c5Iv7WyEWLEbvaVQM9VGUX1dbJ8sY9BNTXipsoTY= X-Received: by 2002:aca:ab44:: with SMTP id u65-v6mr7132701oie.272.1522740808208; Tue, 03 Apr 2018 00:33:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 00:33:27 -0700 (PDT) In-Reply-To: <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> From: Martin Thomson Date: Tue, 3 Apr 2018 17:33:27 +1000 Message-ID: To: Paul Hoffman Cc: DoH WG , dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:33:31 -0000 This is intended to do what? Indicate where the response came from? Why does the client care? I assume that it doesn't apply to requests, or that would get into draft-bellis-dnsop-xpf territory. BTW, you really need to drop UDP from the media type name now. application/dns-udpwireformat;original_transport=3Dtcp is a bit of a contradiction. On Mon, Mar 26, 2018 at 4:48 PM, Paul Hoffman wrot= e: > Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a ne= w media type seems like overkill, particularly given that it will be transp= orting *the exact same* data as an existing media type. Instead, an optiona= l parameter could be added to the application/dns-udpwireformat registratio= n in the DOH document. > > Proposal: > > =3D=3D=3D=3D=3D > > In the media type definition, change "Optional parameters" to: > > Optional parameters: original_transport > original_transport has two defined values, "udp" and "tcp". > This is only expected to be used by servers. > > Also in the the DOH document, under Operational Considerations, we would = add: > > This protocol does not define any use for the original_transport optional > parameter of the application/dns-udpwireformat media type. > > =3D=3D=3D=3D=3D > > Then draft-ietf-dnsop-dns-wireformat-http could define the use of that op= tional parameter as it sees fit. > > --Paul Hoffman > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Tue Apr 3 02:45:04 2018 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 78C9712E856; Tue, 3 Apr 2018 02:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=gmail.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 cfID5rpzKX-N; Tue, 3 Apr 2018 02:44:57 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 78F35124B18; Tue, 3 Apr 2018 02:44:57 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id q198so9833759vke.3; Tue, 03 Apr 2018 02:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vUNsCJHoZ9i1ZpQAuR5m/D2z2b7LOO3s/oNskisWyI=; b=S4nNHp5uykXyFWacWVVaRQY2Y4O/etUvPUsJgLeRmNXuVJS/3VII6fvjM8FFXPQBgn mUmt7wZsD50uc8TL36K3gLiFQSmpn+oa5bf0+mBvyw29hWGz02PMl3fpxlvuPLLyJDWC 1tYtAl42t3JXrWStSyWZ9ZQ2uaQekxneUUnSZ8O1m39GHdulM/NPaRUNguIEQ4U/fAY6 MwRAihwFyce3oYOlUfbF3fg9F3D3bBTi/392avzghSsrtf9aR1v85Kny0PU6u7vd4SbJ sdRvUQWYB+av6UkVOEenJFDIKS+YbgIutMIZchVrm9Rt8ci1BLTWZm9HirMuXbmtHL83 Coug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vUNsCJHoZ9i1ZpQAuR5m/D2z2b7LOO3s/oNskisWyI=; b=lmQ+vaWL6PnW/rzJ01YKnTjryaYiM9F5NDk+p9pEBTZTRooSNjtp+RIF1ql6mdd7XV rJLE+mv/1bHoD7Do72Gy4cF/HzUrUVRqz6UgXbjZuFP2yJML6r845OcjE0+Uiw7dZwlg fkvJHBNmpq42+PrfteBe64cGM23gH2wRd+DEMJK8hEy7Scd9YZzmvSsTeM46h64495S5 U+nkuF/tKxytJUj85vWhiRtC7w5H7P7sqNyYY8+ba7YIijUEqAXEWAWnC5gp7YZrl0rU D8aoJJp1cbj6qoek0x8KUL76+zKTOHFXec4WWPUoVvGcVkUiGj7hYBfXOgmV1bwKVGFw 1V4A== X-Gm-Message-State: ALQs6tCNUsi7l7NksKoHCUxzJJ2+DfLbfb3nhOX5rN6GjwgnlYDvDhM5 mYwJ9TuzOsSewC5J4CSKxhfzz3Ho3qO1mQvYlOAtig== X-Google-Smtp-Source: AIpwx49RwBxQwvEK4I8PmVGBD0qlTwj+Nr0I66d9GFc8V3wJp/hIHl+ubgEUT7/Chut9llgYPyY06IYTybTKNhDG8hc= X-Received: by 10.31.107.153 with SMTP id k25mr7141429vki.156.1522748696519; Tue, 03 Apr 2018 02:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Tue, 3 Apr 2018 02:44:55 -0700 (PDT) In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> From: Davey Song Date: Tue, 3 Apr 2018 17:44:55 +0800 Message-ID: To: Martin Thomson Cc: Paul Hoffman , dnsop , DoH WG Content-Type: multipart/alternative; boundary="001a114790a22368d40568ee8f53" Archived-At: Subject: Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 09:44:59 -0000 --001a114790a22368d40568ee8f53 Content-Type: text/plain; charset="UTF-8" On 3 April 2018 at 15:33, Martin Thomson wrote: > This is intended to do what? Indicate where the response came from? > Why does the client care? To keep the proxy (API client and server) transparent and bypass the middlebox along the path. Without the indicate, the API server has no clue what transport the client use (or would like to use. because there maybe cases that client would like to test TCP capablity of the far end resolver, I don't know). If no such indicate, It is either always using UDP or TCP by default (or by local configuration). It can be done as an choice for software implementation, but for protocol design IMHO, a indicate should be introduced to provide that information. > I assume that it doesn't apply to requests, > or that would get into draft-bellis-dnsop-xpf territory. > That's is the quesion whether the indicate should be carried in HTTP layer or DNS layer. If we use HTTP as a tranparent tunnel without any modification on upper layer message, I would prefer to use a HTTP indicate. > BTW, you really need to drop UDP from the media type name now. > application/dns-udpwireformat;original_transport=tcp is a bit of a > contradiction. I agree. I find no harm defining a media type "application/dns-wireformat" for DOH. Davey --001a114790a22368d40568ee8f53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 April 2018 at 15:33, Martin Thomson <martin.thomson@gmail= .com> wrote:
This is intend= ed to do what?=C2=A0 Indicate where the response came from?
Why does the client care?=C2=A0
To keep the proxy (API cli= ent and server) transparent and bypass the middlebox along the path. Withou= t the indicate, the API server has no clue what transport the client use (o= r would like to use. because there maybe cases that client would like to te= st TCP capablity of the far end resolver, I don't know). If no such ind= icate, It is either always using UDP or TCP=20 by default=C2=A0(or by local configuration= ). It can be done as an choice for software implementation, but for protoco= l design IMHO, a indicate should be introduced to provide that information.= =C2=A0 =C2=A0
=C2=A0
I assum= e that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.
That's is the quesion whether the indicate should be carried in HTTP= layer or DNS layer. If we use HTTP as a tranparent tunnel without any modi= fication on upper layer message, I would prefer to use a HTTP indicate.
=C2=A0
BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original_transport=3Dtcp is a bit of a contradiction.

I agree.=C2=A0 I find no har= m defining a media type "application/dns-wireformat" for DOH.

Davey

--001a114790a22368d40568ee8f53-- From nobody Tue Apr 3 02:58:51 2018 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 C510012E87F; Tue, 3 Apr 2018 02:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GFz5hNbbBK1u; Tue, 3 Apr 2018 02:58:48 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 EED57120726; Tue, 3 Apr 2018 02:58:47 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id m7-v6so18746388otd.1; Tue, 03 Apr 2018 02:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IoYOKlpl7a3fKG+i8tkp91ymgyq8USnZaWhkoO/Lvuc=; b=IEY22VYYys4dy5TSN7CIVC75Mk+WT5yYhJQzjwzOkERsybvwfTMixa8uXg0J0B0y8h 7WRTduMYem9guxekAoLMJnhJYY2MPuJTb4impK+KjJ7e8Do3u5/EZNBvUphiasD2Q8Fn qWO9Wldv+fyDZw+7mmWzzfHvg6pWCJ1vACg7U0ggIBpdywuzUan1KHiKsMtT4fOF38Cv N+2cFtqxJ+M8Da74nQTTiqNudq3rcjQ/dYHWkFQHi6b+ZqBxzvkWxsUAwqun9lxi7aN0 qNryfEacU3qXPuYVaylURabV0sIb4suQ/6S3pfhx75a1vzH0Geu5Ah6ubfhwH4qWB4Ck QxfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoYOKlpl7a3fKG+i8tkp91ymgyq8USnZaWhkoO/Lvuc=; b=a+YuaftSGz+ms9xcZCJkB6JNmkzwY1Bc67ZtV1pX04xsF44C7fUSi3AwGHeKhWSLrY LbZcwXdBUAQ+EZucftaicvE5Bh6cDGbaO7U98DGNnIwVBdo6ucu2Eig3sjCeU4PFgRuJ jNyQ9UzDRoDdpwJm1aBmURAdIFlxEcjAAAVY3T7MWemn85KkWPyyCK+4bs2kvgHCGw9a E8HaEVshw9dAqbiGvNJbVZxl6vHh89sgR9ymlpzkwnLJ6Dza+fJY18kcJgBOmjS/D2MS 8HFdCU3nc647gbIReupoo4xRxy8X0qMS8ug1kLQkqr8P53Pk6W73EtqjyG3su02DWSkG Ib1A== X-Gm-Message-State: ALQs6tDd0XiAQitvUuDoMokfsPb38pb/HIculBMAJthgvEB7zrTlJwRP h/cjpN0UQa4HZVpb6/5/HrgzK38jqOWYvPqjjrI= X-Google-Smtp-Source: AIpwx49g6Jp9kkzJn1hE2qViKyyjTrj7yIs0aD1zavgjOTeiPImmayJeU6vr6GdQp2P4qtFQuWqz5V0vEJ5o7FYVCZI= X-Received: by 2002:a9d:4c81:: with SMTP id m1-v6mr2890785otf.396.1522749527188; Tue, 03 Apr 2018 02:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 02:58:46 -0700 (PDT) In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> From: Martin Thomson Date: Tue, 3 Apr 2018 19:58:46 +1000 Message-ID: To: Davey Song Cc: Paul Hoffman , dnsop , DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 09:58:50 -0000 If I understand your response (not sure that I do), that seems pretty academic and not at all persuasive. For instance, if a client cared about testing TCP capabilities, it can always do its own resolution. On Tue, Apr 3, 2018 at 7:44 PM, Davey Song wrote: > > > On 3 April 2018 at 15:33, Martin Thomson wrote: >> >> This is intended to do what? Indicate where the response came from? >> Why does the client care? > > To keep the proxy (API client and server) transparent and bypass the > middlebox along the path. Without the indicate, the API server has no clue > what transport the client use (or would like to use. because there maybe > cases that client would like to test TCP capablity of the far end resolver, > I don't know). If no such indicate, It is either always using UDP or TCP by > default (or by local configuration). It can be done as an choice for > software implementation, but for protocol design IMHO, a indicate should be > introduced to provide that information. > >> >> I assume that it doesn't apply to requests, >> or that would get into draft-bellis-dnsop-xpf territory. > > That's is the quesion whether the indicate should be carried in HTTP layer > or DNS layer. If we use HTTP as a tranparent tunnel without any modification > on upper layer message, I would prefer to use a HTTP indicate. > >> >> BTW, you really need to drop UDP from the media type name now. >> application/dns-udpwireformat;original_transport=tcp is a bit of a >> contradiction. > > > I agree. I find no harm defining a media type "application/dns-wireformat" > for DOH. > > Davey > From nobody Tue Apr 3 06:27:30 2018 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 7E13F12E8E6; Tue, 3 Apr 2018 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nAAfglrDEYSW; Tue, 3 Apr 2018 06:27:22 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 7E66112E8E2; Tue, 3 Apr 2018 06:27:22 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 3 Apr 2018 06:27:20 -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.1178.000; Tue, 3 Apr 2018 06:27:20 -0700 From: Paul Hoffman To: Martin Thomson CC: dnsop , DoH WG Thread-Topic: [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http Thread-Index: AQHTxMYJjiIeoO0puk2SlNzAM+KuJqPvJ+iAgAAkvICAAAPeAIAAOkYA Date: Tue, 3 Apr 2018 13:27:20 +0000 Message-ID: <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> In-Reply-To: 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: <5D2AEE092E955141A1378CF99D5218B8@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 13:27:23 -0000 On Apr 3, 2018, at 2:58 AM, Martin Thomson wrote= : >=20 > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. =20 ...to you. It was persuasive enough for the DNSOP WG to adopt the document = as a WG item. > For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. That's not what draft-ietf-dnsop-dns-wireformat-http is about. Martin: Are you saying that you want DOH to remove the optional parameter f= rom the application/dns-udpwireformat registration? If so, what do you prop= ose for the DNSOP WG? --Paul Hoffman= From nobody Tue Apr 3 10:00:58 2018 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 1FB71126BF6; Tue, 3 Apr 2018 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 b3AOiWCc1Ao3; Tue, 3 Apr 2018 10:00:49 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37034126BFD; Tue, 3 Apr 2018 10:00:44 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E942338DB4; Tue, 3 Apr 2018 13:00:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23235.45882.930371.905689@gro.dd.org> Date: Tue, 3 Apr 2018 13:00:42 -0400 From: Dave Lawrence To: DoH WG , dnsop In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> Archived-At: Subject: Re: [Doh] [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:00:52 -0000 Martin Thomson writes: > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. That testing TCP capabilities part is a distraction from the core motivation. The request makes sense from a dumb transparent proxy point of view, where there's a regular DNS resolver on the one end who just wants to be able to get DNS messages through an HTTPS tunnel. Media type isn't the right way to achieve that, but the key idea is sound. From nobody Tue Apr 3 10:49:03 2018 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 C5A9D126D85 for ; Tue, 3 Apr 2018 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htz12d7qU1zN for ; Tue, 3 Apr 2018 10:48:58 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 1CECB1243F6 for ; Tue, 3 Apr 2018 10:48:58 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id BAABA3A032 for ; Tue, 3 Apr 2018 13:48:56 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id f47-v6so11422040oth.2 for ; Tue, 03 Apr 2018 10:48:56 -0700 (PDT) X-Gm-Message-State: ALQs6tDzBP+0Ka0fy1/5PiV/P91B3dbntc+ghRPsYsKzVUjA1OsUc62e irx+no3XCXDoNZROeMHT040q0iOMyMIj5ssd1WA= X-Google-Smtp-Source: AIpwx49fiNUkkIQy2Vijx1tpb7W4fviR92ZLc6r7KNKdQaCjjuUuJQantd3a7JktBe+95KDGWNxTo0ozBummA5Si/nU= X-Received: by 2002:a9d:4494:: with SMTP id v20-v6mr208799ote.397.1522777736450; Tue, 03 Apr 2018 10:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Tue, 3 Apr 2018 10:48:55 -0700 (PDT) In-Reply-To: <152271985261.14004.9961915464941726907@ietfa.amsl.com> References: <152271985261.14004.9961915464941726907@ietfa.amsl.com> From: Patrick McManus Date: Tue, 3 Apr 2018 13:48:55 -0400 X-Gmail-Original-Message-ID: Message-ID: Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000000d99830568f55259" Archived-At: Subject: Re: [Doh] I-D Action: draft-ietf-doh-dns-over-https-05.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:49:01 -0000 --0000000000000d99830568f55259 Content-Type: text/plain; charset="UTF-8" Hi All, Paul and I have worked through the issues identified face to face in London and on the list and github. Its time to publish a new draft. The most interesting thing to note about it is the configuration primitive has changed slightly from a URI with a particular set of query parameters to a URI Template. The example should illustrate how these things are broadly similar but allow a degree of flexibility for future media formats fitting into DoH. This flexibility came up in London, and in the github discussion both before and after we met so we tried to find the right balance between flexibility and complexity. I think what is in -05 balances those needs while leaning towards simplicity. We seem to have had pretty good review up to this point and are, imo, reaching a state of diminishing returns on the edits. Hopefully those are signs that a WGLC is close. -Patrick On Mon, Apr 2, 2018 at 9:44 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS Over HTTPS WG of the IETF. > > Title : DNS Queries over HTTPS > Authors : Paul Hoffman > Patrick McManus > Filename : draft-ietf-doh-dns-over-https-05.txt > Pages : 17 > Date : 2018-04-02 > > Abstract: > This document describes how to run DNS service over HTTP using > https:// URIs. > > [[ There is a repository for this draft at https://github.com/dohwg/ > draft-ietf-doh-dns-over-https [1] ]]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05 > https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000000d99830568f55259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Paul and I have work= ed through the issues identified face to face in London and on the list and= github. Its time to publish a new draft.

The most= interesting thing to note about it is the configuration primitive has chan= ged slightly from a URI with a particular set of query parameters to a URI = Template. The example should illustrate how these things are broadly simila= r but allow a degree of flexibility for future media formats fitting into D= oH. This flexibility came up in London, and in the github discussion both b= efore and after we met so we tried to find the right balance between flexib= ility and complexity. I think what is in -05 balances those needs while lea= ning towards simplicity.

We seem to have had p= retty good review up to this point and are, imo, reaching a state of dimini= shing returns on the edits. Hopefully those are signs that a WGLC is close.=

-Patrick


<= div>

On Mon, Apr 2, 2018 at 9:44 PM, <internet-drafts@ietf.org&g= t; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DNS Over HTTPS WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= DNS Queries over HTTPS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Hoffman
=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 Patrick McManus
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-doh-dns-over-https-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-04-02

Abstract:
=C2=A0 =C2=A0This document describes how to run DNS service over HTTP using=
=C2=A0 =C2=A0https:// URIs.

=C2=A0 =C2=A0[[ There is a repository for this draft at https://github.com/= dohwg/
=C2=A0 =C2=A0draft-ietf-doh-dns-over-https [1] ]].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-doh-dns-over-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-doh-dns-over-https-05
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-doh-dns-over-https-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-doh-dns-over-https-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--0000000000000d99830568f55259-- From nobody Tue Apr 3 11:53:51 2018 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 139191242EA for ; Tue, 3 Apr 2018 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 0lrMnsh9RfPE for ; Tue, 3 Apr 2018 11:53:47 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 94661120721 for ; Tue, 3 Apr 2018 11:53:47 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e98-v6so24149693itd.4 for ; Tue, 03 Apr 2018 11:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JtKgaxEvI8UGqqb/1Uj4Hyd0AgC+4K0bsKXu5DfgcXs=; b=GVb1V7VySqU9GIW9wkaFo7UkKt2XmrfU3JuYrzT07fKLnxUyrvgmxyXU6hT+RAfnuy qjvuKuC/zjou7ATjt8/XH/uxcr/7eKHYFqg2KIWm1p9k+BnsFjLadV+Qn+UHRbWQA6+n cuz56L81miyTM2GdRXhsVgBl4OccYEHT+bXAeCO7yQVXkGrsICS5mLYdJeZ8vMk26QNq ci08yT4h9dEzQpsiAm3G9zOtIjuiynNJVgzzuUwsp/G9gzJjoFdwggTznJET7zxHndZd 8yHzMElwwuW3WIu4A9nYQJs/j8CD4LzJNsQyJCs9vtOfwafqqoZBQsNU5BzCMckGn/17 Z90Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JtKgaxEvI8UGqqb/1Uj4Hyd0AgC+4K0bsKXu5DfgcXs=; b=TRJKEse24xAYMWJvvVHS6savFXmMTEQZQz/1DTYEZZF0NYaS/hI1LbPS95Zkw+DynA XcfiUQqSmvmJpp0UCdDKiBHzslVy/g9MtKgmXUqBog3vfGtlk3TI9GL9/WCvby1JLbO0 qEgrr8xDqmPQQqBKoya0ht3tEo88sxASbEAad5J7sRi27cC98aRhmrwKEK6Lv2QxKD/0 c/LBoaazTLrc6ITH9al2+JQmhJKwAoS/rhHM4nh13hT7FvCl1kIgVX0QzBo3mmzQgDpQ gmTT/N9TnqyeEVBVmWpHQsus/+INrpmLG2I7SkMTR5M8FZue8H/Of2JCXB6s10iRM9pb 7B8Q== X-Gm-Message-State: ALQs6tAyKD4uvCLB84ZzycvPUMzKIZQgvrc6XppuGzkSnkPav0YsS1ia kF9h7qPLawohpAW+KHghL7aP2Q3B17kmnmE8UlOwDFvwNNA= X-Google-Smtp-Source: AIpwx49zW1yFkia5+lczn3gO7l15dgwv1WPi1Fj3sc4oiSfQO2SJd2JKT1+oUwNAQChK9NuE2AaZaSUFNabpy5yzhgs= X-Received: by 2002:a24:27d7:: with SMTP id g206-v6mr6093812ita.21.1522781625787; Tue, 03 Apr 2018 11:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Tue, 3 Apr 2018 11:53:45 -0700 (PDT) In-Reply-To: <20180326083031.2bco57z33vyty766@nic.fr> References: <20180326083031.2bco57z33vyty766@nic.fr> From: Ben Schwartz Date: Tue, 3 Apr 2018 14:53:45 -0400 Message-ID: To: Stephane Bortzmeyer Cc: Martin Thomson , DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f41c3d0568f639e3" Archived-At: Subject: Re: [Doh] New query formats X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:53:50 -0000 --000000000000f41c3d0568f639e3 Content-Type: multipart/alternative; boundary="000000000000e09dca0568f639c4" --000000000000e09dca0568f639c4 Content-Type: text/plain; charset="UTF-8" This suggestion has now been implemented in draft-05. Do you feel the new text achieves your goal? In particular, I will note the following sentences: The DNS API server defines the URI used by the > request through the use of a URI Template [RFC6570]. Configuration > and discovery of the URI Template is done out of band from this > protocol. and These examples use a DNS API service with a URI Template of > "https://dnsserver.example.net/dns-query{?dns}" Based on this text, it seems to me that if a client is configured out of band with a template of this kind, and the server is later upgraded to support additional query forms, the client cannot exercise those forms until after a new out-of-band configuration update, because it does not have any instructions about how to map the new values into a URI. This is in contrast to draft-04's URL-based configuration, which would allow a client to attempt new query forms without requiring a configuration update. On Mon, Mar 26, 2018 at 4:30 AM, Stephane Bortzmeyer wrote: > On Thu, Mar 22, 2018 at 02:32:40PM +0000, > Martin Thomson wrote > a message of 45 lines which said: > > > 3. Specify that other parameters can be used to carry information > > about queries. Servers that find unknown query parameters MUST ignore > > them. > > > > 4. Define a new registry for header field parameters. (The URI > > template would have covered this neatly, so you could avoid that.) > > Yes, RFC 6570 is the right way to specify these parameters. > > You can get some inspiration from my (old) DNS looking glass: > > http://www.bortzmeyer.org/dns-lg-usage.html > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000e09dca0568f639c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This suggestion has now been implemented in draft-05.=C2= =A0 Do you feel the new text achieves your goal?

In part= icular, I will note the following sentences:

The DNS API server defines the URI = used by the
request through the use of a URI Template [RFC6570].=C2=A0 C= onfiguration
and discovery of the URI Template is done out of band from = this
protocol.

and

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">These examples use a DNS A= PI service with a URI Template of
=C2=A0 =C2=A0"https://dnsserver.example.net/dns-qu= ery{?dns}"

Based on this text, it = seems to me that if a client is configured out of band with a template of t= his kind, and the server is later upgraded to support additional query form= s, the client cannot exercise those forms until after a new out-of-band con= figuration update, because it does not have any instructions about how to m= ap the new values into a URI.

This is in contrast = to draft-04's URL-based configuration, which would allow a client to at= tempt new query forms without requiring a configuration update.
=

On Mon, Mar 26, 2= 018 at 4:30 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrot= e:
On Thu, Mar 22, 2018 at 02:32:40PM +00= 00,
=C2=A0Martin Thomson <martin= .thomson@gmail.com> wrote
=C2=A0a message of 45 lines which said:

> 3. Specify that other parameters can be used to carry information
> about queries.=C2=A0 Servers that find unknown query parameters MUST i= gnore
> them.
>
> 4. Define a new registry for header field parameters.=C2=A0 (The URI > template would have covered this neatly, so you could avoid that.)

Yes, RFC 6570 is the right way to specify these parameters.

You can get some inspiration from my (old) DNS looking glass:

http://www.bortzmeyer.org/dns-lg-usage.html

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

--000000000000e09dca0568f639c4-- --000000000000f41c3d0568f639e3 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDwadHNM/+yn0My/F4i7WLr lnlUbeZsNirit0bowjxggTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA0MDMxODUzNDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAU5+1TqR9e5fpRxzuf+M0bXZwJRAGliG2EzKV9KXG ZOwodPJd+4Bnz4U4D4tByjtXlwjFICxf5SFxx4AKdlsnyBVW//m7mPNp0RTVXe3yx/mQAjI7O//p HY5CJMzbOyM0v8oTYRBLNPQPcOAKN/rfKUpMZ/7DEB3Ozv93CwfMZMNsVcxbF5TaxPl/e3Tp9ah/ /30/jLj3lyjut2Gtib6lV8wBrZ2ZikSCS50l4lTn2isLu2NMQFS9Sf3GXrKDiNrYQCiNs7Yhrk1X JkbNP76sx6Vm61jtlSC/qHokLkVJ4N07nagneYyVCGKP2DjHkt0O+25Oz1/KzTUf2asgrt9xWA== --000000000000f41c3d0568f639e3-- From nobody Tue Apr 3 14:59:01 2018 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 0DEB312D87F for ; Tue, 3 Apr 2018 14:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SzefcUkNoavZ for ; Tue, 3 Apr 2018 14:58:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 673BB126C2F for ; Tue, 3 Apr 2018 14:58:58 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 3 Apr 2018 14:58:56 -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.1178.000; Tue, 3 Apr 2018 14:58:56 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: [Ext] [Doh] I-D Action: draft-ietf-doh-dns-over-https-05.txt Thread-Index: AQHTy5b2O+RKn2Kw00OpAORF/zSypw== Date: Tue, 3 Apr 2018 21:58:56 +0000 Message-ID: References: <152271985261.14004.9961915464941726907@ietfa.amsl.com> In-Reply-To: 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: <6AEB3AB33ADF714EB8F63762421E1D40@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-05.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:59:00 -0000 On Apr 3, 2018, at 10:48 AM, Patrick McManus wrote: > Paul and I have worked through the issues identified face to face in Lond= on and on the list and github. Its time to publish a new draft. s/Its/It was/ That is, -05 is the result of going through those issues. > The most interesting thing to note about it is the configuration primitiv= e has changed slightly from a URI with a particular set of query parameters= to a URI Template. The example should illustrate how these things are broa= dly similar but allow a degree of flexibility for future media formats fitt= ing into DoH. This flexibility came up in London, and in the github discuss= ion both before and after we met so we tried to find the right balance betw= een flexibility and complexity. I think what is in -05 balances those needs= while leaning towards simplicity. The fact we were making a (small) breaking change to the wire format for qu= eries might raise objections, but given that the document still isn't in WG= Last Call, much less IETF Last Call and IESG review, should cause develope= rs to keep a bit nimble. Hopefully the examples are still clear. Do note the differences in the diff= at . > We seem to have had pretty good review up to this point and are, imo, rea= ching a state of diminishing returns on the edits. Hopefully those are sign= s that a WGLC is close. ...if not immediately imminent. --Paul Hoffman= From nobody Tue Apr 3 19:15:52 2018 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 20080127735; Tue, 3 Apr 2018 19:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=gmail.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 Y9NzaU3Eg9OA; Tue, 3 Apr 2018 19:15:49 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 9ADA61243FE; Tue, 3 Apr 2018 19:15:49 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id h134so11475811vke.2; Tue, 03 Apr 2018 19:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F+nSoLytIB97BVpO+eqmQkm0PIMjXzBySqbcBLC9FAo=; b=E1OJ8jCuWYr9nuIIgoMXlqQnPSSPUWE7W1GxGaj3p0VVViP8es8yCXK7cCowJ0DTPj dxCryFIqMFV2Fb/DklWCzxXZO75O5bsjhBF9eMRt/zCbgBxSoaR+CPKNoGxz9YoOujyG fXPNuluXnh3G7EbRZrxzU7rjFByIJCDpktanct+sUffgmn5eCK9hOXts2a23ZcaB7dfa vW/KAzZ48J137NJnOdpjWKX8CMNN816hk81eB8yggrdD2oPg6n6JeYghQfgV6wnOVBJm 69RR/zVhztc9ITYJwe5A7xSMbgBp246Bx2K6UZ9y+YNe8MUu3NZuBTaSqofk43bV0CWs NzwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F+nSoLytIB97BVpO+eqmQkm0PIMjXzBySqbcBLC9FAo=; b=A58CKvqzKlkR8btAigsD15YKT5QyUoQ/mbTHtQfGBIHooUtGvEON8/L+BweffV6EoF g1M/Mgpmu6EdQsGWZghrtBN1CVey7beS8oYPeq7Mm54O2dqw86M3qAc5y1y39WKA/Uiu fW6G3N0TjFu8Aavu6TXB5c4YGcvfy9prpcpRHEGmnHe93Nm7QbNXfq65lsXy6+xppgqk HFgdvf7efR/a/NubnfcfMeKEXzCIMCAUiuQ7nlOtaKe9BN0jBk6MmhKn2F1UCljFwTaj M5fbLsaQfJL2GfFOG8hQYsBpzF3bCI4TqlpaJnMtp2BBuYxOkjaHhtgWf9i+8roHvCr5 Bmug== X-Gm-Message-State: ALQs6tAyO6Y1ZZxckS+dtAbNfogF/l6M/HoLyZ8uEuYzmMhKprQf/YXC ElA4YQaW5byNp1bAO4UiNrAon5BSIpEJ9j/cpdw= X-Google-Smtp-Source: AIpwx48HTYGg0l86ns0ln8NkkeuTwqrF1refNOCj/W1eaP93iD1NGbchEb6ygUzg+o+3PBBJ4e67twkGkOolsi16IdI= X-Received: by 10.31.235.130 with SMTP id j124mr257632vkh.85.1522808148525; Tue, 03 Apr 2018 19:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Tue, 3 Apr 2018 19:15:47 -0700 (PDT) In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> From: Davey Song Date: Wed, 4 Apr 2018 10:15:47 +0800 Message-ID: To: Martin Thomson Cc: Paul Hoffman , dnsop , DoH WG Content-Type: multipart/alternative; boundary="94eb2c094060c10a0c0568fc6667" Archived-At: Subject: Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:15:51 -0000 --94eb2c094060c10a0c0568fc6667 Content-Type: text/plain; charset="UTF-8" On 3 April 2018 at 17:58, Martin Thomson wrote: > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. It's not the emphasis. Peopole get tied of misbehavior (or unexperect behavior) of all kinds of middlebox. I just think DOH proxy should not add any fuel on that. Davey --94eb2c094060c10a0c0568fc6667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 April 2018 at 17:58, Martin Thomson <martin.thomson@gmail= .com> wrote:
If I understand your response (not sure that I do), that seems pretty<= br> academic and not at all persuasive.=C2=A0 For instance, if a client cared about testing TCP capabilities, it can always do its own resolution.

It's not the emphasis. Peopole get tied of mi= sbehavior (or unexperect behavior) of all kinds of middlebox. I just think = DOH proxy should not add any fuel on that.

Davey

--94eb2c094060c10a0c0568fc6667-- From nobody Tue Apr 3 19:35:45 2018 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 D96CE127867; Tue, 3 Apr 2018 19:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F31PDWPVuj8J; Tue, 3 Apr 2018 19:35:35 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 7FB16126CBF; Tue, 3 Apr 2018 19:35:35 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id h55-v6so20194152ote.9; Tue, 03 Apr 2018 19:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6GeL72Vb0+g11UUbh5j6Ardi5DUYx+rfVvTF5Pstr28=; b=ccs0sxDmOl6OGZp9/Ph82EHpuPXxgLAC2wWKM8g9VvVINhQLh/K6Dg11E6kjR4M1YU u4OXO5DpmYh9Ke8gkDAl4xXpCTye7aCkNfxmxsBuWNgI7/oL+OYf2y3CR+oLmMpolhyL xjoT/iBQ37tnVSV0/YO8H5NkbrwYTYuYBSmKHDt5HbT+8dXOxFkJ5AV1d+FhoiACeVpo uITkar+rneiHpmZRZbFrFCs3P0zHwGtwtvIBHRdKDfNBWKFhtE76YTax8w4IN8vbaNcV kVzOgMjSA3ZUu9RxlsYUrnsFifXrTCBtPa6s3nGhBCIFz+Nboq2BaeKm3jmy6JCnjZxf JaJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6GeL72Vb0+g11UUbh5j6Ardi5DUYx+rfVvTF5Pstr28=; b=tQmNxlhPLyWbmUW45mYWbTNemCZ5za2TZYLiToiM3A5xVOZuwtlr2Yc0+1xSQhdtWh WzYCCTP3RHOnd0xQraRwyIZPo0Lz1vvne2lew/nMKr0Zzy3TQ8k1rUaGidDaMVTBIWOO XjAribc50ZqyRYhTIqso3G8UA0oJIoVTj8II9nrjCl5GKvzKTNG0HwrOk7tM6ndNMmKX 0F7l78fpcyXxQq2e0uB3GuCXLc6DS3uPV8vbTFKBD+0s/Mr+Kjp30KIi+a5IMMqm4UG+ SbMCcmU4t/hCLWh8Dtj6u+B53qOt1VH6LahQDFBaYc1wbOhk5yG7syVbeADELmAT+8yZ 9i3g== X-Gm-Message-State: ALQs6tBgPBAH39wloQoeP3r2to5dZ2NvOSz1DONR/UgZZn3jOwZ7rSha HyV0IrVXNzOJcOKYNjuHabdT9iOo+RBfhBGEtqgLZMVP X-Google-Smtp-Source: AIpwx4/e4K6S3MFb3YcLWmKO7R3dTD1I3m9M4ol3hgZu8Oj7BinP79u1fz736lmXALAoxchEdhHDvhqzZqwTtaKfc24= X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr1298252ota.392.1522809334746; Tue, 03 Apr 2018 19:35:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 19:35:34 -0700 (PDT) In-Reply-To: <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> From: Martin Thomson Date: Wed, 4 Apr 2018 12:35:34 +1000 Message-ID: To: Paul Hoffman Cc: dnsop , DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:35:38 -0000 On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman wrote: > Martin: Are you saying that you want DOH to remove the optional parameter from the application/dns-udpwireformat registration? If so, what do you propose for the DNSOP WG? Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll concede that I'm probably missing something. By my current understanding, draft-ietf-dnsop-dns-wireformat-http is indistinguishable from a specific implementation of draft-ietf-doh-dns-over-https. That is, if a DOH server wanted to service all its queries by forwarding requests to a resolver [1], I can't see how that would be disallowed by DOH, and that's exactly what draft-ietf-dnsop-dns-wireformat-http appears to describe. Convince me that this isn't the case (or not, and I'll be in the rough on this). --Martin [1] ...after randomizing the ID. From nobody Tue Apr 3 20:39:37 2018 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 3231412946D; Tue, 3 Apr 2018 20:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RjCLcp8oE4br; Tue, 3 Apr 2018 20:39:29 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D975F126C89; Tue, 3 Apr 2018 20:39:28 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 328D63205A; Tue, 3 Apr 2018 23:39:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23236.18671.182273.977633@gro.dd.org> Date: Tue, 3 Apr 2018 23:39:27 -0400 From: Dave Lawrence To: dnsop , DoH WG In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 03:39:30 -0000 Martin Thomson writes: > Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll > concede that I'm probably missing something. I think that's right. -05 with the original_transport optional parameter accommodates the aims of that other draft. From nobody Tue Apr 3 21:45:42 2018 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 E18E4124234; Tue, 3 Apr 2018 21:45:33 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4YgOGo3wNfoe; Tue, 3 Apr 2018 21:45:31 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 37784126D0C; Tue, 3 Apr 2018 21:45:31 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id q38so12436379uad.5; Tue, 03 Apr 2018 21:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXNFvgIIpy1Q72KQ1o06ZUPZBMBMydSKp5RgdTWugy8=; b=FKUaUw5YwerOlyeeBw/O1kDJdvzEgzC7v4URKqRTWcPjpoXP4qzu4P+MjbC5Lfm42I 7gn3pLFoxYcj04M//IK/v6DzSM6iA6STe3geqz6YTBHz9lv+PuAYk1U9bHtAWvlWTlfm MusdSJNyezvmIV8vd2CwX5hQuDcFSEDKiWdmg35OtSMzYJYXlL8cFbFOuP17Cb4liANe ZRGJftgVPs6bKkq09TyubgXqJaLM10Z4yoNNLY2bKvBgPoPnODMyM8Z7KXsGh1yZHTqF mU+pEKkJKToByzamkL9AltORc/ORsAw+XmvrnEB8ge5BppXPwFc7deLFhoOwUFCVxZoZ +9kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXNFvgIIpy1Q72KQ1o06ZUPZBMBMydSKp5RgdTWugy8=; b=HfFQLoX87gEtyqMh3FPRnRupDRUK3/KnP9GVe7k/kDwq2ZrLvzPdtWy1VT6PYMTeU3 dGft+aoDv/nrfgZs9sC+9KOzY/HeLHdKSW5XySYUXV/EDbBoUU6OfWkhz/dDXTB5bYfz /79UtHK5Hk0YOaNw9bD5BclWlztbXXaDEp9TWaLPhNXc3Xw7pE+wEslxYdl5DVZaCaZb dIeH4jlZ49EndeRWOikZPginp+9fNDtxgsLsneLXbLOExmGfw80PexkrR7A3zuV8y9FI kBj7GN7xhSSSzER+7Y/C6JOILGqeCOTxQYa/niKGkw5LQGArgCpLqyS5gh+Q+9Br/gNB BMJA== X-Gm-Message-State: ALQs6tBhN1iU2kYwnYatbDY5ddJCjCgvGqI1NUDe/4cX6x349ovXa7Ko PLPVmfZ4gjh6subKMmfbAE9FtkR2WTPP9oKy53Q= X-Google-Smtp-Source: AIpwx4/tJJkXTVKvpyprEEg1rUZhBpGzNzcBgZkwYDqf/QLYlOBjsGhdhsMbOce2cUrNWTxYercJLkDhQWWshG6t9LM= X-Received: by 10.176.85.199 with SMTP id w7mr10150695uaa.145.1522817130147; Tue, 03 Apr 2018 21:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Tue, 3 Apr 2018 21:45:29 -0700 (PDT) In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> From: Davey Song Date: Wed, 4 Apr 2018 12:45:29 +0800 Message-ID: To: Martin Thomson Cc: Paul Hoffman , dnsop , DoH WG Content-Type: multipart/alternative; boundary="f403045e343419b4230568fe7e26" Archived-At: Subject: Re: [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:45:34 -0000 --f403045e343419b4230568fe7e26 Content-Type: text/plain; charset="UTF-8" I'm sorry to hear that. I would like to provide some information as a background if it's useful. dns-wireformat-http draft was originally proposed in DNSOP WG as a experimental draft in early 2016. We focus on the requirement of enhancing DNS availability bypassing the middlebox on the path via HTTP tunnel. It was later adopted in DNSOP WG as WG document. I think it was an original and sound work deserving us to work on at that time. However, it was postponed in 2017 and we are told that HTTP people has concern on it. At that time, draft-hoffman-dispatch-dns-over-https was proposed as a standards track aiming to defined HTTPS as substrate transport for DNS which is different from the DNS over HTTP tunnel case. Later DOH was created forcusing on HTTPS as DNS transport protocol. We were told that the proxy and tunnel case is not in the scope of DOH but we are suggested use the technology developed in DOH. At that time I still think it is valuable to introduce a use case of DNS over HTTP tunnel and define necessary protocol. The compromise is that we drop the free use of HTTP(without TLS) and HTTP 1.x because DOH has mandatory requirement on HTTPS and HTT /2. When I submited dnsop-dns-wireformat-http-02 weeks ago, I asked if we could introduce a optional parameter which is bettern than a new media type "application/dns-tcpwireformat". I suppose that optional parameter should defined in dnsop-dns-wireformat-http-02 instead of DOH draft. However, after original_transport optional parameter was defined in 05 version of doh draft, I'm afraid it was enlarged its scope to contain the proxy/tunnel case which make people think dns-wireformat-http is useless. I'm confused. So I would like to ask folks in the two WGs how to proceed: 1) Should dns-wireformat-http draft insists on the original defination of DNS over HTTP(s) tunnel with new HTTP header as a experimental document? Because that is the original experiment we have done to show the capacity of DNS over HTTP(s). 2) If the answer is no, how should dns-wireformat-http draft align itself with DOH document. My suggestion is to define the original_transport optional parameter in dns-wireformat-http draft. Or Is there any other way out not abandoning our work? As the co-author I still want to rescue it. -Davey On 4 April 2018 at 10:35, Martin Thomson wrote: > On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman > wrote: > > Martin: Are you saying that you want DOH to remove the optional > parameter from the application/dns-udpwireformat registration? If so, what > do you propose for the DNSOP WG? > > Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll > concede that I'm probably missing something. > > By my current understanding, draft-ietf-dnsop-dns-wireformat-http is > indistinguishable from a specific implementation of > draft-ietf-doh-dns-over-https. That is, if a DOH server wanted to > service all its queries by forwarding requests to a resolver [1], I > can't see how that would be disallowed by DOH, and that's exactly what > draft-ietf-dnsop-dns-wireformat-http appears to describe. > > Convince me that this isn't the case (or not, and I'll be in the rough on > this). > > --Martin > > [1] ...after randomizing the ID. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f403045e343419b4230568fe7e26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry to hear that. I would like to provide some i= nformation as a background if it's useful.

dns-wireformat-http draft = was originally proposed in DNSOP WG as a experimental draft in early 2016. = We focus on the requirement of enhancing DNS availability bypassing the mid= dlebox on the path via HTTP tunnel.=C2=A0 It was later adopted in DNSOP WG = as WG document. I think it was an original and sound work deserving us to w= ork on at that time.=C2=A0

<= /span>
However, it was postponed in 2017 and w= e are told that HTTP people has concern on it.=C2=A0 At that time,=C2=A0dra= ft-hoffman-dispatch-dns-over-https was proposed as a standards track aiming= to defined HTTPS as=C2=A0substrate transport for DNS which is different fr= om the DNS over HTTP tunnel case.=C2=A0

Later=C2=A0DOH was created= forcusing on HTTPS as DNS transport protocol. We were told that the proxy = and tunnel case is not in the scope of DOH but we are suggested use the tec= hnology developed in DOH. At that time I still think it is valuable to intr= oduce a use case of DNS over HTTP tunnel and define necessary protocol. The= compromise is that we drop the free use of HTTP(without TLS) and HTTP 1.x = because DOH has=C2=A0mandatory=C2=A0requir= ement on HTTPS and HTT /2.

When I submited dnsop-d= ns-wireformat-http-02 weeks ago, I asked if we could introduce a optional p= arameter which is bettern than a new=C2=A0= media type "application/dns-t= cpwireformat". I suppose=C2=A0that optional = parameter should defined in=20 dnsop-dns-wireformat-http-02=C2=A0instead = of DOH draft.=C2=A0However, after original_transport optional=C2=A0parameter was defined in=C2=A005 version of doh draft, I'm a= fraid it was enlarged its scope to contain the proxy/tunnel case which make= people think=C2=A0dns-wireformat-http is useless. I'm confused.= =C2=A0

So I would like to ask folks in the two WGs= how to proceed:

1) Should=20 dns-wireformat-ht= tp draft insists on the original defination of DNS over HTTP(s) tunnel with new HTT= P header as a experimental document? Because that is the original experimen= t we have done to show the capacity of DNS over HTTP(s).
2) If the answer is no, how sh= ould=C2=A0 dns-wireformat-ht= tp draft align itself with DOH document. My suggestion is to define the=C2= =A0original_transport optional=C2=A0parameter in=C2=A0 dns-wireformat-ht= tp draft.

Or Is = there any other way out=C2=A0not=C2=A0abandoning = our work? As the co-author I still want to=C2=A0rescue it.=C2=A0

-Davey

=C2=A0

On 4 April 2018 at 10:35= , Martin Thomson <martin.thomson@gmail.com> wrote:
O= n Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> Martin: Are you saying that you want DOH to remove the optional parame= ter from the application/dns-udpwireformat registration? If so, what do you= propose for the DNSOP WG?

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.=C2=A0 = But I'll
concede that I'm probably missing something.

By my current understanding, draft-ietf-dnsop-dns-wireformat-http is indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.=C2=A0 That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly w= hat
draft-ietf-dnsop-dns-wireformat-http appears to describe.

Convince me that this isn't the case (or not, and I'll be in the ro= ugh on this).

--Martin

[1] ...after randomizing the ID.

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

--f403045e343419b4230568fe7e26-- From nobody Tue Apr 3 22:44:27 2018 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 38BC8127078 for ; Tue, 3 Apr 2018 22:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L7A-iJ0oCkpw for ; Tue, 3 Apr 2018 22:44:24 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 E9B4F12702E for ; Tue, 3 Apr 2018 22:44:23 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id h55-v6so20533569ote.9 for ; Tue, 03 Apr 2018 22:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hZ6m6l2k5ALUwjWZslWSb/VtUrfgpYQjCmknrs+9i7E=; b=YnopcTen6kQhdgQGaMtPhCXJQY8+Bth+K9X/zwoag2tut7PfzCnRGf9oo9MyXauwyy TuvonNMvYrl9bex65Jgr+uQtaUZ+7sHDQSBDW0e3WqQ+sr5SvMvbVot+43O+gEDRHBQ4 s71M6YslkOMdHY0w2km6jm+g9wkHx1hgqT/0ICM/gQjQ/+01Owha0tVLXIzBP2U8Z+ct ioRq6AR2wCH+y4uFeR65P1oIuJ7KIx+zS6+01V+zAeYiliSTsj9LufN0DxrkCq7yYZBC YaHkOxzhEBQJJAvEYvlkeu6k754H8UQWpv4Mq8mxYvLB/MBXnLnuWUfch9oIqi84+Cmx Ydtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hZ6m6l2k5ALUwjWZslWSb/VtUrfgpYQjCmknrs+9i7E=; b=rtI/biKsrN1ooJ0kyGubmoTd6ZpBxclFBHQS4gWfGAlyDTu/lpwgmobKMcDG29Qfx4 hYJpPfvUtddimEnw9ANXnTxnBOWtQVVjT9s8K0y1FG9y5rSEKzzODpo9Ew2JQr0QJQxG vcQpObhje/G46TYX1J6xkuPEOzwveVk7ycPcJ4/BvRlbJ3ulg8v7jZxE/gN3cFIgi4ME EmLFbfCetJuE8M+JoabvmiLuZgy9kzoQFwmengazM5kMyU4E0juutP/ISOAIs98+l29j rOTbroRvGXmJl1yx6qJT8l0NU6w0ZsG/7DvWWlLtrKXkkPW7gCfS9N1M/EK0xPvDUqvJ 0Tfw== X-Gm-Message-State: ALQs6tA9gtn2/S63s6/uNCimccqK7jRZ4OmN+CELnVp7cKaZbU5FnsIt Z+qKPCPN/n4J1AZ+GcPsVSN8TrWNSdIM8QLBNN8= X-Google-Smtp-Source: AIpwx48itYQu2drx20WVhAhmST27DZM+oK/SzodfK/hEJrj5jiIRLPIVOEyf1Y29ZQ9g6tVjfRST/6VMRsOiU07+jHA= X-Received: by 2002:a9d:29ea:: with SMTP id g39-v6mr10333303otd.241.1522820663162; Tue, 03 Apr 2018 22:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 22:44:22 -0700 (PDT) In-Reply-To: References: <20180326083031.2bco57z33vyty766@nic.fr> From: Martin Thomson Date: Wed, 4 Apr 2018 15:44:22 +1000 Message-ID: To: Ben Schwartz Cc: Stephane Bortzmeyer , DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] New query formats X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 05:44:26 -0000 I don't know about Stephane, but I can live with this. Yes, it kicks the can down the road a little with respect to new query formats, but it doesn't foreclose on them. And as I said, without a discovery process we don't really have a good path to introducing new query formats. Note that mostly only applies to GET. POST can use new content types with all the costs associated with that, or it can do the same as proposed for GET. On Wed, Apr 4, 2018 at 4:53 AM, Ben Schwartz wrote: > This suggestion has now been implemented in draft-05. Do you feel the new > text achieves your goal? > > In particular, I will note the following sentences: > >> The DNS API server defines the URI used by the >> request through the use of a URI Template [RFC6570]. Configuration >> and discovery of the URI Template is done out of band from this >> protocol. > > > and > >> These examples use a DNS API service with a URI Template of >> "https://dnsserver.example.net/dns-query{?dns}" > > > Based on this text, it seems to me that if a client is configured out of > band with a template of this kind, and the server is later upgraded to > support additional query forms, the client cannot exercise those forms until > after a new out-of-band configuration update, because it does not have any > instructions about how to map the new values into a URI. > > This is in contrast to draft-04's URL-based configuration, which would allow > a client to attempt new query forms without requiring a configuration > update. > > On Mon, Mar 26, 2018 at 4:30 AM, Stephane Bortzmeyer > wrote: >> >> On Thu, Mar 22, 2018 at 02:32:40PM +0000, >> Martin Thomson wrote >> a message of 45 lines which said: >> >> > 3. Specify that other parameters can be used to carry information >> > about queries. Servers that find unknown query parameters MUST ignore >> > them. >> > >> > 4. Define a new registry for header field parameters. (The URI >> > template would have covered this neatly, so you could avoid that.) >> >> Yes, RFC 6570 is the right way to specify these parameters. >> >> You can get some inspiration from my (old) DNS looking glass: >> >> http://www.bortzmeyer.org/dns-lg-usage.html >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh > > From nobody Wed Apr 4 02:32:55 2018 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 8F2F8127137; Wed, 4 Apr 2018 02:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 G5cbnt_Td7mC; Wed, 4 Apr 2018 02:32:52 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431FC1270FC; Wed, 4 Apr 2018 02:32:52 -0700 (PDT) Received: from [88.212.170.147] (port=52231 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1f3emg-0001Yv-7Y (Exim 4.72) (return-path ); Wed, 04 Apr 2018 10:32:50 +0100 To: dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> From: Ray Bellis Message-ID: <2b531647-cca2-7e9e-5905-eab87e0e1a06@bellis.me.uk> Date: Wed, 4 Apr 2018 10:32:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 09:32:53 -0000 [added DOH WG to the cc:] On 04/04/2018 04:39, Dave Lawrence wrote > I think that's right. -05 with the original_transport optional > parameter accommodates the aims of that other draft. but ignores the concerns I raised yesterday that simply indicating "tcp" or "udp" is insufficient to allow a server to make policy decisions based on the meta-properties of the original request and its transport (whether that be a "real" tranport protocol like UDP or TCP or a pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc). Ray From nobody Wed Apr 4 04:00:00 2018 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 462BC127241 for ; Wed, 4 Apr 2018 03:59: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UnmRIxG-Orr1 for ; Wed, 4 Apr 2018 03:59:56 -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 3309B1271FD for ; Wed, 4 Apr 2018 03:59:47 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 27167 invoked from network); 4 Apr 2018 12:59:43 +0200 Received: from acjd214.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.53.214]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 4 Apr 2018 12:59:43 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org Message-ID: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> Date: Wed, 4 Apr 2018 12:58:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TJFpLYX1goUQ9zaBRflvRPvIsLqJ1V0nt" X-WP-MailID: f31ae8825e3247362703f4e1a23fd078 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [kTN0] Archived-At: Subject: [Doh] DOH server on non-standard ports X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 10:59:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TJFpLYX1goUQ9zaBRflvRPvIsLqJ1V0nt Content-Type: multipart/mixed; boundary="deHpKOcg2dK38WyvEDnv2BnwrMnaXDr4W"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org Message-ID: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> Subject: DOH server on non-standard ports --deHpKOcg2dK38WyvEDnv2BnwrMnaXDr4W Content-Type: multipart/mixed; boundary="------------733F43DE6083518625BEF12F" Content-Language: pl This is a multi-part message in MIME format. --------------733F43DE6083518625BEF12F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I think that it may be beneficial to specify that a DOH server MAY work o= n a port other than 443 and that the DOH client MUST support accessing DOH se= rvers on ports other than 443. I have been thinking about the possibility of adding support for DOH to a= home router. In the future, someone may modify dnsmasq so that it would act as= a DOH server - dnsmasq could then run on this router and provide DOH services. The port 443 would be already used by the router's management interface w= hich would probably run as a separate process on this router (as it would be a= n entirely different codebase). So dnsmasq would have to provide DOH servic= es on another port. Greetings, Mateusz Jo=C5=84czyk --------------733F43DE6083518625BEF12F Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------733F43DE6083518625BEF12F-- --deHpKOcg2dK38WyvEDnv2BnwrMnaXDr4W-- --TJFpLYX1goUQ9zaBRflvRPvIsLqJ1V0nt 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJaxLAeAAoJEPvWWrhhCv7GC24P/im9PzaHkbqwdSKsGkZVQ1ur tMF9JVG7k5qwF5BGRdZDIG/Ud+HSNLqYXBrZNnfpLX6je2HCJmBGNsDsu+IF1mND XvK44d66Nk0be0sbMyArdhTbsqkI1DTywlheMpHUgrXocvIFhJZG/GjyydeZDlC6 hXjgoM2Ttp87b8lreWbR6oq/zGMBEXk9igXwAnCE1KrpuVk7iywslTf1UHAiyhG3 H0DzVtUr2mYaztb5n2T6QvgPesBsd4nFnU1J6ZfbfE4PhfIScyG9/H376SuDbzkm 0g6gszc/z3YuMSAXuuBHCFNO0AOmr1qVmhaSGxQYRy1+AJ57zc/aV0O5YSREgnIq Gwyq00sV3N/w5tZ8+vzXLjbRQJDCTLL/Gj6fY5EBYnny70MIBat0PbgBNIchpBkn YbGz53Z7jXZ8GieGxwFNiL/1H4JkVm3O+X+rLTgINvnRqP7OqHelwsbidrsph83N pUXZuZeGxGrF/Zej9ZhiNqYTaUvrOKcwYFA+LbzI9B83eY6BaLZqz3t67xdSAhJ4 ch8fP3uiCQUWbnx1jWiihRD7EHFw/dFK9Q0CNQiHm9G2jMvMcqCT2c0fJv1yDX7i xnzCFSwYYZiSBbTRfYkaqay9NCXQtPx+9klDtHPu9rycDAprSr4d9tMQvN7AbV8I 4r5oZAp7vQjlmYxNO+sn =4GDz -----END PGP SIGNATURE----- --TJFpLYX1goUQ9zaBRflvRPvIsLqJ1V0nt-- From nobody Wed Apr 4 05:50:04 2018 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 7D7DC127444 for ; Wed, 4 Apr 2018 05:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucOM-2EegNtr for ; Wed, 4 Apr 2018 05:50:00 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 178EB12741D for ; Wed, 4 Apr 2018 05:50:00 -0700 (PDT) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5A1953A03B for ; Wed, 4 Apr 2018 08:49:59 -0400 (EDT) Received: by mail-ot0-f171.google.com with SMTP id v64-v6so23145153otb.13 for ; Wed, 04 Apr 2018 05:49:59 -0700 (PDT) X-Gm-Message-State: ALQs6tAaRbdGPWz6Avh33aUL4WtzeHXFwaFC/czmddaRRmHuXCfbVtjx jboeDALBheA/kBQP0jkQvithOieKqsO2IaZqOlY= X-Google-Smtp-Source: AIpwx48+n/kZ1rFsROPomSQmtjq8EEA9mU2fvvFCEsFpbojqDQ8BYy2PxeympYrfLTsvJx0atgUh1v7+jFm9xF0QUOM= X-Received: by 2002:a9d:55bb:: with SMTP id m56-v6mr10087448oth.110.1522846199108; Wed, 04 Apr 2018 05:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Wed, 4 Apr 2018 05:49:58 -0700 (PDT) In-Reply-To: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> References: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> From: Patrick McManus Date: Wed, 4 Apr 2018 08:49:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000bedb3f056905423f" Archived-At: Subject: Re: [Doh] DOH server on non-standard ports X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 12:50:02 -0000 --000000000000bedb3f056905423f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable neither https not uris are limited to any particular port. I don't see a problem here.. On Wed, Apr 4, 2018 at 6:58 AM, Mateusz Jo=C5=84czyk wr= ote: > Hello, > I think that it may be beneficial to specify that a DOH server MAY work o= n > a > port other than 443 and that the DOH client MUST support accessing DOH > servers > on ports other than 443. > > I have been thinking about the possibility of adding support for DOH to a > home > router. In the future, someone may modify dnsmasq so that it would act as > a DOH > server - dnsmasq could then run on this router and provide DOH services. > The port 443 would be already used by the router's management interface > which > would probably run as a separate process on this router (as it would be a= n > entirely different codebase). So dnsmasq would have to provide DOH > services on > another port. > > Greetings, > Mateusz Jo=C5=84czyk > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000bedb3f056905423f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
neither https not uris are limited to any particular port.= I don't see a problem here..

<= div class=3D"gmail_quote">On Wed, Apr 4, 2018 at 6:58 AM, Mateusz Jo=C5=84c= zyk <mat.jonczyk@o2.pl> wrote:
Hello,
I think that it may be beneficial to specify that a DOH server MAY work on = a
port other than 443 and that the DOH client MUST support accessing DOH serv= ers
on ports other than 443.

I have been thinking about the possibility of adding support for DOH to a h= ome
router. In the future, someone may modify dnsmasq so that it would act as a= DOH
server - dnsmasq could then run on this router and provide DOH services. The port 443 would be already used by the router's management interface= which
would probably run as a separate process on this router (as it would be an<= br> entirely different codebase). So dnsmasq would have to provide DOH services= on
another port.

Greetings,
Mateusz Jo=C5=84czyk

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


--000000000000bedb3f056905423f-- From nobody Wed Apr 4 07:22:06 2018 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 266AA127601; Wed, 4 Apr 2018 07:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 I3Z5bVXtcVeG; Wed, 4 Apr 2018 07:22:03 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A7F12025C; Wed, 4 Apr 2018 07:22:02 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:55900 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1f3jIV-0005rz-Ab (Exim 4.72) (return-path ); Wed, 04 Apr 2018 15:21:59 +0100 To: Paul Vixie Cc: dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> From: Ray Bellis Message-ID: <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> Date: Wed, 4 Apr 2018 15:22:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AC4C2F7.7050906@redbarn.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:22:05 -0000 On 04/04/2018 13:20, Paul Vixie wrote: > tcp and udp are the two ways a query might have reached the > initiating proxy, and that distinction is the only thing the > responding proxy needs to know. I disagree, I don't think that transport protocols should continue to be used as things that should be used for policy decisions. Per my previous message, they were a suitable proxy (no pun intended) for "this came from an unspoofable address", or "this channel can handle large responses" but there are other ways to achieve that now that aren't strictly transport. For example, presence of EDNS cookies satisfies the "unspoofable address" and therefore would permit RRL to be skipped for that client, but "UDP with Cookies" isn't a transport. [I appreciate that this isn't the best example because that cookie *might* get all the way through to the backend server anyway. But it also might not]. > if DOH becomes a standard transport, then we could add that > identifier as well -- but i don't think a client capable of DOH is > going to be using this particular proxy method. We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on DNS-over-QUIC too. None of those are true "transports", but server operators may wish to make policy decisions based on the resulting meta-properties of them. Ray From nobody Wed Apr 4 07:54:28 2018 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 D46F712D958; Wed, 4 Apr 2018 07:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pxYwdkA3jQld; Wed, 4 Apr 2018 07:54:22 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD0412D94F; Wed, 4 Apr 2018 07:54:22 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 323257594C; Wed, 4 Apr 2018 14:54:20 +0000 (UTC) Message-ID: <5AC4E70C.7020003@redbarn.org> Date: Wed, 04 Apr 2018 07:54:04 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ray Bellis CC: dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> In-Reply-To: <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:54:24 -0000 ray, i won't engage on the question, should i want to do this. the working group mantra is interoperability -- as in, if you want to do this, here's an interoperable way. i'm not asking that the working group ratify the intent, or recommend the method. (as went ECS.) the proxy is transparent. we list it in resolv.conf or as a forwarder. it regenerates the queries on the far side. it has to differentiate between tcp and udp because the unmodified client is making strategy decisions and implementing those using that transport choice. this is not a service. DOH is a service. this is a proxy, which i would like to have be interoperable. please don't ask me to change what i want to build; that would be out-of-scope. paul re: Ray Bellis wrote: > On 04/04/2018 13:20, Paul Vixie wrote: > >> tcp and udp are the two ways a query might have reached the >> initiating proxy, and that distinction is the only thing the >> responding proxy needs to know. > > I disagree, I don't think that transport protocols should continue to be > used as things that should be used for policy decisions. > > Per my previous message, they were a suitable proxy (no pun intended) > for "this came from an unspoofable address", or "this channel can handle > large responses" but there are other ways to achieve that now that > aren't strictly transport. > > For example, presence of EDNS cookies satisfies the "unspoofable > address" and therefore would permit RRL to be skipped for that client, > but "UDP with Cookies" isn't a transport. > > [I appreciate that this isn't the best example because that cookie > *might* get all the way through to the backend server anyway. But it > also might not]. > >> if DOH becomes a standard transport, then we could add that >> identifier as well -- but i don't think a client capable of DOH is >> going to be using this particular proxy method. > > We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on > DNS-over-QUIC too. None of those are true "transports", but server > operators may wish to make policy decisions based on the resulting > meta-properties of them. > > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- P Vixie From nobody Wed Apr 4 08:14:18 2018 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 6BF3512DA02 for ; Wed, 4 Apr 2018 08:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 sIP_8ukCFvix for ; Wed, 4 Apr 2018 08:14:08 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 D64E512DA00 for ; Wed, 4 Apr 2018 08:14:07 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p67so14325473qke.13 for ; Wed, 04 Apr 2018 08:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l4UNxQWm8N1ub7NOisU6uRDQ5SmB8imqqAyKT5XaINw=; b=GXJbo2gaqaKdErA/0wseI+XBib/srgV6tf7euMh23Ro6pV2UniFLCCE8m8YUnqqkb1 ++1eS3RDKqOwSORpHvIRTlwTwaQjrqdEu0SqOakQwSH5enOIhrZaHR7Id28WbwLvML+j wHD/HOzzGmVNjRxfbF8uCTTTaxPzZsKNft81hM9oNburBUDmvm1AgBpL3tTbVzkyo3jT GxYyvgI3EylnWXnx94KMrDxaO7dZlr9qgh7djuw42pEcssyzmYRujvr5Cgo7FtIbph1Z oOqXmtBMg3vz8y+XZTCSi/Ea17PD61zK1h/1lTEnksy19bZco437V35M6bmiaicZ2lgH ai1w== 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=l4UNxQWm8N1ub7NOisU6uRDQ5SmB8imqqAyKT5XaINw=; b=J++qnX8rtMuH32hSUrZwkZJOhefKkSh0Xq1Gg+yXbI3o+JvIXXhk63d1cjfSCBomhi 9pRrvyzeat7S5TbEIXXLDibh2J+zJlXz4fT7DrGrtGr1MxDdbOWzPX7Lx6ve9E894RtE C87AwomfcOjuqZQ4BAel8B/6lZhq8UiyrZb6O06iC769GC32SaPUwI0QrrHVeSahyAjN Q/UIGoBLjhHO3ayb/AUkofQdVsG8PoOJIyhrXV6j8se5FDWWxGVqG2GixNvNoCatfdaq sd3KWXef4yDs/HD1zQfvN4Lb5AUMYnjDV7qI2qEDLmUSXmhT9nrpwH1uQ8nws6qBe7jr FngQ== X-Gm-Message-State: ALQs6tAeOSzdXPvGu7wXs24/EW6v+99vMQMYH8yTw5SWWJRjisknAiR/ uajo71hFQ9Yxs2VQIR1E61CWXa07UJs= X-Google-Smtp-Source: AIpwx48KYcBG6toMKZAobCIjRwH5TiiI5Ke0Fvo/BMY5weWy0siMwn2cnYtEFSuCCFGaBhFCfnHSHQ== X-Received: by 10.55.31.165 with SMTP id n37mr23755444qkh.184.1522854846963; Wed, 04 Apr 2018 08:14:06 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id 42sm4549656qty.51.2018.04.04.08.14.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 08:14:06 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C0BE3665-6E6E-4BDC-929E-842F823398D5" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 11:14:04 -0400 In-Reply-To: <5AC4E70C.7020003@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:14:11 -0000 --Apple-Mail=_C0BE3665-6E6E-4BDC-929E-842F823398D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 10:54 AM, Paul Vixie wrote: > this is not a service. DOH is a service. this is a proxy, which i = would like to have be interoperable. please don't ask me to change what = i want to build; that would be out-of-scope. Maybe another question to ask is "okay, Paul wants to build this, but = why does the IETF need to standardize it?" I don't mean that the answer should be "it doesn't," but rather that I = don't actually see why this is valuable, and maybe I'm not the only one = who needs to hear more of a sales pitch. --Apple-Mail=_C0BE3665-6E6E-4BDC-929E-842F823398D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 10:54 AM, Paul Vixie <paul@redbarn.org> = wrote:
this is not a = service. DOH is a service. this is a proxy, which i would like to have = be interoperable. please don't ask me to change what i want to build; = that would be out-of-scope.

Maybe another question to ask is "okay, Paul = wants to build this, but why does the IETF need to standardize = it?"

I don't = mean that the answer should be "it doesn't," but rather that I don't = actually see why this is valuable, and maybe I'm not the only one who = needs to hear more of a sales pitch.

= --Apple-Mail=_C0BE3665-6E6E-4BDC-929E-842F823398D5-- From nobody Wed Apr 4 08:37:03 2018 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 6BC6E12DA47 for ; Wed, 4 Apr 2018 08:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 IK4KfaDquHgL for ; Wed, 4 Apr 2018 08:36:59 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC3912DA2C for ; Wed, 4 Apr 2018 08:36:58 -0700 (PDT) Received: from [88.212.170.147] (port=57445 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1f3kT1-0007AG-52 (Exim 4.72) for doh@ietf.org (return-path ); Wed, 04 Apr 2018 16:36:55 +0100 To: doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> From: Ray Bellis Message-ID: Date: Wed, 4 Apr 2018 16:36:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AC4E70C.7020003@redbarn.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:37:01 -0000 On 04/04/2018 15:54, Paul Vixie wrote: > ray, i won't engage on the question, should i want to do this. the > working group mantra is interoperability -- as in, if you want to do > this, here's an interoperable way. i'm not asking that the working group > ratify the intent, or recommend the method. (as went ECS.) > > the proxy is transparent. we list it in resolv.conf or as a forwarder. > it regenerates the queries on the far side. it has to differentiate > between tcp and udp because the unmodified client is making strategy > decisions and implementing those using that transport choice. > > this is not a service. DOH is a service. this is a proxy, which i would > like to have be interoperable. please don't ask me to change what i want > to build; that would be out-of-scope. I'm not sure that we're talking about the same sort of proxy. I'm more concerned with the sort that might sit on the (far) server side of the equation, proxying between a DOH server and a real DNS server where those two servers are cooperating. This is (IMHO) a likely deployment model for DOH, until such time as the major OSS DNS server implementations include DOH natively. I'm therefore also concerned with how transport (or pseudo-transport) properties affect how those real DNS servers make policy decisions about their responses. Ray From nobody Wed Apr 4 08:37:22 2018 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 4FA1312DA47; Wed, 4 Apr 2018 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8MBihs6AH9Ua; Wed, 4 Apr 2018 08:37:19 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD6712DA2C; Wed, 4 Apr 2018 08:37:19 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CCA3A7594C; Wed, 4 Apr 2018 15:37:18 +0000 (UTC) Message-ID: <5AC4F11F.3050009@redbarn.org> Date: Wed, 04 Apr 2018 08:37:03 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:37:21 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 10:54 AM, Paul Vixie > wrote: >> this is not a service. DOH is a service. this is a proxy, which i >> would like to have be interoperable. please don't ask me to change >> what i want to build; that would be out-of-scope. > > Maybe another question to ask is "okay, Paul wants to build this, but > why does the IETF need to standardize it?" same as for ECS: not universally popular, but better if interoperable. > I don't mean that the answer should be "it doesn't," but rather that I > don't actually see why this is valuable, and maybe I'm not the only one > who needs to hear more of a sales pitch. there's code that implements this. there are people using it. there will be more of both. a standard will mean greater interoperability. -- P Vixie From nobody Wed Apr 4 08:41:33 2018 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 5074912DA3E for ; Wed, 4 Apr 2018 08:41:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 BLeLW4xEStYW for ; Wed, 4 Apr 2018 08:41:30 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 6F3DE12DA0A for ; Wed, 4 Apr 2018 08:41:30 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z23so22876833qti.5 for ; Wed, 04 Apr 2018 08:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bP3MjKhOu7OyviUKcFjYDmcSPXFJXdhNxWG0JPQaMPc=; b=nxDptREOA/Au0MnCxc7nMmPDTKBw9oX0RzEN1Ff0omw/WNInsjNkQPzNn0+m3dppVy iwXhjSmkhs5HmFvCDeyzupwu5sFTYQ2pUBh+5MfG1pwA4L9wZIiRxpAQ9NuJj4exy96o Rb6NGVAvX3TG9cS4TqfSLrdNAtMGYYtAaL0RGrrC1KMF0dmZCZ+8so3e7jpKMr/7IaHe /3Yv+2StdprdMtTfp62Dpvvelgu2AU8M8vLorAhjBdkGPxcmfI8zcVZHe/F178kLTueK x/D0KAiSoTWCnWdqLvmEbjnfQnLcDLRbv1bWKTRrz93YQE1oa4NkWDEgkTxUDAaOOQE7 j8ag== 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=bP3MjKhOu7OyviUKcFjYDmcSPXFJXdhNxWG0JPQaMPc=; b=G5XG4/SFj02dKLhJn6w+JIgwl3GkgrKH6/Up2Dx56QhgL/6asKGptzSXWlElQPCrvF BXYCE8wTlvRONWEwG1/y0Vo3fb06b1ixwgly4ANqn3EAqUs7D+V+r48dXQO8AUKo0m7Q OWNGhu1SqMQwmpvzZ67fS61QrrSzsBhmPdCimDrravPEbKjZxsXV0i6n9ISkOt45Ze2O sKRa+CUSKqOShCziLSPe0y9rvTUUvoUWKvYVBzb/7ytvRS0OLYSBPlMqPjEv1LfpdUYV PR1+uexrS2udjW0hHC+SKF8q8ANjsMbOMN63ILanVZQMXJA0ef0KFkLu/TJS2W0Fv2sb EiMg== X-Gm-Message-State: ALQs6tDKuHkpryjW7UnR+fNYDA7bM9s0SsA1YvUP/0gek2lmJREsOuem AS9bvlR3tIHqLa7FRlXXIAIHFQ== X-Google-Smtp-Source: AIpwx49vl84n8GMmkwCqMjpVSw8ney7ziXE9KiS5MISDCmV10pZfJ8E7KRwu4YmEWzDSJm3g7L+Gyw== X-Received: by 10.237.41.194 with SMTP id o60mr26623952qtd.197.1522856489565; Wed, 04 Apr 2018 08:41:29 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id g9sm4354378qti.11.2018.04.04.08.41.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 08:41:29 -0700 (PDT) From: Ted Lemon Message-Id: <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4F70FB23-3124-4F61-B905-E5D5A84404E4" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 11:41:27 -0400 In-Reply-To: <5AC4F11F.3050009@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:41:32 -0000 --Apple-Mail=_4F70FB23-3124-4F61-B905-E5D5A84404E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 11:37 AM, Paul Vixie wrote: > there's code that implements this. there are people using it. there = will be more of both. a standard will mean greater interoperability. Why was the code written? Why are they using this? What is it about = this solution that makes it preferable, for their use case, to a smart = proxy that is itself a full-service resolver and thus shouldn't tunnel = information about the query transport? Given Bert's talk on camels, I think these are questions that are worth = asking, and the answer shouldn't be "because." --Apple-Mail=_4F70FB23-3124-4F61-B905-E5D5A84404E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 11:37 AM, Paul Vixie <paul@redbarn.org> = wrote:
there's code = that implements this. there are people using it. there will be more of = both. a standard will mean greater interoperability.

Why was the code written?   Why are they using this? =   What is it about this solution that makes it preferable, for = their use case, to a smart proxy that is itself a full-service resolver = and thus shouldn't tunnel information about the query = transport?

Given= Bert's talk on camels, I think these are questions that are worth = asking, and the answer shouldn't be "because."

= --Apple-Mail=_4F70FB23-3124-4F61-B905-E5D5A84404E4-- From nobody Wed Apr 4 08:49:16 2018 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 A6C4512DA49; Wed, 4 Apr 2018 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dz4ckK41UY3B; Wed, 4 Apr 2018 08:49:13 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1207C12DA3E; Wed, 4 Apr 2018 08:49:13 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8F8B17594C; Wed, 4 Apr 2018 15:49:12 +0000 (UTC) Message-ID: <5AC4F3F5.6080408@redbarn.org> Date: Wed, 04 Apr 2018 08:49:09 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> In-Reply-To: <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:49:15 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 11:37 AM, Paul Vixie > wrote: >> there's code that implements this. there are people using it. there >> will be more of both. a standard will mean greater interoperability. > > Why was the code written? Why are they using this? where the client can't be upgraded to DOH, and the network can't be upgraded to add VPN's, this allows a name server to be reachable with full fidelity (no middleboxes, so EDNS works) and better-than-cleartext privacy. i use it on my laptop when in a hotel room or coffee shop. > What is it about this > solution that makes it preferable, for their use case, to a smart proxy > that is itself a full-service resolver and thus shouldn't tunnel > information about the query transport? this is a far thinner solution than a full-service resolver, which would require local configuration and monitoring and so on, as well as topology stability that can't be guaranteed. > Given Bert's talk on camels, I think these are questions that are worth > asking, and the answer shouldn't be "because." this would never be part of the mandatory-to-implement "DNS core". -- P Vixie From nobody Wed Apr 4 08:51:40 2018 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 210DE12DA4A for ; Wed, 4 Apr 2018 08:51:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 yWtQEaS-RWsa for ; Wed, 4 Apr 2018 08:51:36 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 EC31012DA4C for ; Wed, 4 Apr 2018 08:51:35 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w23so15499481qtn.3 for ; Wed, 04 Apr 2018 08:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8b4sHCJjNn1xMo8/siZdybVdV0l+oED340LUGVX5C3A=; b=zAvvOMxIijZdHxWEO2yKttCFXkqt2gJSWXSdzeAG4pXBkxyprESuxsSBNhTE+yaEYw dOnfi3dQLYJW+4lvmQoImIFnCnoju+9ZkxLH/z1Q5WepaIGu/8lThw/qr3TWAqkEU9CY 1CImtHfzaR1QNHEsdeWYL/5ZTyBWf6PJDnF9C1KHz9Y6x1VSW1BSXciuvnHlEYNeq3JZ 1TbSpLotKgZiHGS8XcppfzndKNehWmBmpELKsa9btZF/smf7BEb++mc0MmlJSVDh+YSr nHWdFj80eV2vtxpJ4V+DJOa/UpAbRrGz01Ve9eFgN0KKZcRQETksLw6DtgN9hij57PHZ nlwQ== 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=8b4sHCJjNn1xMo8/siZdybVdV0l+oED340LUGVX5C3A=; b=oXHh1oLyB7XhilpKwdjiVujiE9W1vQd0JVfxoL7Rrepc9E79xFomgWaHSc01K68G+l PgEmqr99rOZDf9VOUoy+JtwHAja6GuHfsND63M/VgH2ZoADmClIDYuTQwESgyGqCzPq2 gKTlomuvIWQW4e5CftP7ZTmUoD3UVpp7qWez6ixw+Gt2HxclXyZsYPhXOY4nmABrFepX 5coZnENfobsNUDJI0oofAuiY85PZxi5K+ETFRBbsV+PJ56RI7IbtpjLlvVrYR/dOwAAZ HXjxgNUqNVq1MDo0XToqyR/plqyryd7ZWafRHEyQmL6VOHlKG6B02MfppA6Gkf8+RPbn 83UQ== X-Gm-Message-State: ALQs6tDKX70tsOKPohvImhMJoSp91peyYZidcv5I+/CgJk6UeFantzZs RM7LtLnihX2Kt9Zc8hcbs1rOEQ== X-Google-Smtp-Source: AIpwx49eOZGA5iXKBxetvRQ40ottimkImQE0JjGc9aiN4vbKhIu95YabGhAvGdqzFMFnRleyIaUTlQ== X-Received: by 10.237.33.111 with SMTP id 102mr27513561qtc.234.1522857095070; Wed, 04 Apr 2018 08:51:35 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d1sm4479243qtk.47.2018.04.04.08.51.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 08:51:34 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_02B355CE-B2C2-4214-B488-2934A546BCF9" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 11:51:33 -0400 In-Reply-To: <5AC4F3F5.6080408@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:51:38 -0000 --Apple-Mail=_02B355CE-B2C2-4214-B488-2934A546BCF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 11:49 AM, Paul Vixie wrote: > this is a far thinner solution than a full-service resolver, which = would require local configuration and monitoring and so on, as well as = topology stability that can't be guaranteed. For your laptop use case, why wouldn't you just have the thing running = on the laptop do truncation if the answer is too long? I admit that = this is more code, but it's not a lot more code, and what you're doing = instead is pretty hacky. The fact that it's not required to implement doesn't mean that it = doesn't contribute to the camel problem. --Apple-Mail=_02B355CE-B2C2-4214-B488-2934A546BCF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 11:49 AM, Paul Vixie <paul@redbarn.org> = wrote:
this is a far = thinner solution than a full-service resolver, which would require local = configuration and monitoring and so on, as well as topology stability = that can't be guaranteed.

For your laptop use case, why wouldn't you = just have the thing running on the laptop do truncation if the answer is = too long?   I admit that this is more code, but it's not a lot more = code, and what you're doing instead is pretty hacky.

The fact that it's not = required to implement doesn't mean that it doesn't contribute to the = camel problem.

= --Apple-Mail=_02B355CE-B2C2-4214-B488-2934A546BCF9-- From nobody Wed Apr 4 09:01:56 2018 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 2264D12DA3E for ; Wed, 4 Apr 2018 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 oS2W1QPyW17V for ; Wed, 4 Apr 2018 09:01:53 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 53CD21201F8 for ; Wed, 4 Apr 2018 09:01:53 -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]:51465) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f3kr9-000EaA-M2 (Exim 4.89_2) (return-path ); Wed, 04 Apr 2018 17:01:51 +0100 Date: Wed, 4 Apr 2018 17:01:51 +0100 From: Tony Finch To: Ray Bellis cc: doh@ietf.org In-Reply-To: Message-ID: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:01:55 -0000 Ray Bellis wrote: > > I'm more concerned with the sort that might sit on the (far) server side > of the equation, proxying between a DOH server and a real DNS server > where those two servers are cooperating. In this situation it is much simpler to set them up to never use UDP. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: North 6 to gale 8, backing south 4 or 5. Moderate or rough, becoming slight. Showers then fair. Good. From nobody Wed Apr 4 09:31:04 2018 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 70C75120724; Wed, 4 Apr 2018 09:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h6fV4Dh0Y4e4; Wed, 4 Apr 2018 09:30:55 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF10126D3F; Wed, 4 Apr 2018 09:30:55 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6757C7594C; Wed, 4 Apr 2018 16:30:54 +0000 (UTC) Message-ID: <5AC4FDAE.7040705@redbarn.org> Date: Wed, 04 Apr 2018 09:30:38 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Martin Thomson CC: Paul Hoffman , dnsop , DoH WG References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:30:56 -0000 Martin Thomson wrote: > On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman wrote: >> Martin: Are you saying that you want DOH to remove the optional parameter from the application/dns-udpwireformat registration? If so, what do you propose for the DNSOP WG? > > Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll > concede that I'm probably missing something. the use case is not well-expressed. as a co-author, i apologize. > By my current understanding, draft-ietf-dnsop-dns-wireformat-http is > indistinguishable from a specific implementation of > draft-ietf-doh-dns-over-https. That is, if a DOH server wanted to > service all its queries by forwarding requests to a resolver [1], I > can't see how that would be disallowed by DOH, and that's exactly what > draft-ietf-dnsop-dns-wireformat-http appears to describe. it's a high-fidelity virtual middlebox, to work around low-fidelity actual middleboxes. it is not a new dns transport protocol, which would require client and server changes. dns-over-https is a thin drop-in. -- P Vixie From nobody Wed Apr 4 09:31:14 2018 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 8CB0B12E89E; Wed, 4 Apr 2018 09:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 C8epweBQ3B-l; Wed, 4 Apr 2018 09:31:03 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABE312E882; Wed, 4 Apr 2018 09:31:03 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id ABC617594D; Wed, 4 Apr 2018 16:31:02 +0000 (UTC) Message-ID: <5AC4FDC4.4080608@redbarn.org> Date: Wed, 04 Apr 2018 09:31:00 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Dave Lawrence CC: dnsop , DoH WG References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> In-Reply-To: <23236.18671.182273.977633@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:31:07 -0000 Dave Lawrence wrote: > Martin Thomson writes: >> Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll >> concede that I'm probably missing something. > > I think that's right. -05 with the original_transport optional > parameter accommodates the aims of that other draft. yes. -- P Vixie From nobody Wed Apr 4 09:42:30 2018 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 31500126D3F; Wed, 4 Apr 2018 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tnBpXST7zDO3; Wed, 4 Apr 2018 09:42:23 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97D8129C5D; Wed, 4 Apr 2018 09:42:23 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 271267594C; Wed, 4 Apr 2018 16:42:23 +0000 (UTC) Message-ID: <5AC5006C.4050308@redbarn.org> Date: Wed, 04 Apr 2018 09:42:20 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:42:25 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 11:49 AM, Paul Vixie > wrote: >> this is a far thinner solution than a full-service resolver, which >> would require local configuration and monitoring and so on, as well as >> topology stability that can't be guaranteed. > > For your laptop use case, why wouldn't you just have the thing running > on the laptop do truncation if the answer is too long? that would be low fidelity. i need to run clients whose internet experience will not be influenced by middleboxes. > I admit that this is more code, but it's not a lot more code, and > what you're doing instead is pretty hacky. feel free to try it out: https://github.com/BII-Lab/DNSoverHTTP or: https://github.com/BII-Lab/DNSoverHTTPinGO these are out of date with respect to the current draft, but each works. i would like to see a standard that they can conform to, so that i'm safe building a larger infrastructure. > The fact that it's not required to implement doesn't mean that it > doesn't contribute to the camel problem. are we at the point where any of us can call anything we see no use for part of the camel problem? i'm hoping not, and so i'm going to ignore your statement here. "if you want to do this, here's an interoperable method" is this group's meme. it's not "this is the best engineering solution we were able to create for the problem we are willing to admit you might have." -- P Vixie From nobody Wed Apr 4 09:44:55 2018 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 2EEF2127978 for ; Wed, 4 Apr 2018 09:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ye0jBy8jCFPR for ; Wed, 4 Apr 2018 09:44:50 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 B9CF5120724 for ; Wed, 4 Apr 2018 09:44:50 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 141so27098124iou.12 for ; Wed, 04 Apr 2018 09:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kOiw+VVB+/+GfbBLImtTaEpGOo3+CZKhGq5MdG70o6s=; b=uLp/ArepwqbRkNolu/cdXd3QuG04Cu+In+cVtpnswbvdHIXL7bE+w/aGX/kjpQF7zg 1KIHcLLPcgZ0dvREWaE6QNDHM9OBdD1u/k5iDQ/u8jbGqaaQVAgrwVlM9Ed/e0djSz45 CgRqTQpMB5mDJKIL/sRD0f6Cd5QHrSTs3l3kTvgGyEbVzI4MBR7PPmHxcyWpwV4I0kW5 9elR650eUvAQydnlKYieqTgUY3cKIU+H0G7huZewzrKs6ZjxvmkpP5JWOHeyvuptZaCk s/sfW+zFJVusAzTzOEdWDGXFdxNEfzxvTwZhd425qDVP8nBYWZiM4yVqyJ3lOQuE2R9x U7kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kOiw+VVB+/+GfbBLImtTaEpGOo3+CZKhGq5MdG70o6s=; b=SJheSHRsUFuKjwOc70Hp6UUNzumYP17czU5lN/mmz8kw58xy1WZUw+PNkdmn/iwDyz yLr/AMcAFjd4kxGR1Y/J7c0yq6GzEo/wnNE1F5lYdZIkTfsYO5CdxggKSz2Zqx/FVW47 Ti7YL7Hr6vtJclskU1e7op4g4EKmhB0J/3Zgqn3xprZicVVQLtB08C1PxWBKj6v4wdbF jwlqDn73bKyYma9s7Mwf5zKbPdSIMKM+o5mhVWxggxSvIr6eDjsXssY/ks56twvSYW1n AQjPzQX6ovHUm66SrJaT5xjFMSaLtTWFrjNKJ/oNUJ0VdeZ1ydwf+BocL0LOPgAKSnwD zxbw== X-Gm-Message-State: AElRT7FWKa2gzmHzSqGdcCWRS47t30g519irLP+AstVCB8Am0YBnzxVi GChIKE5xq1wDe0osaCML6EfiJZf6FKAIhXBEas/XSg== X-Google-Smtp-Source: AIpwx4+qfUIaEiOAGdfGllZK1NXkwm4OUdgfrvYgyP6DxNpNX+f/2A4AW5unmLj8alq2K2aXrkG1wNcab2prLx0VxwY= X-Received: by 10.107.174.102 with SMTP id x99mr17960826ioe.18.1522860289469; Wed, 04 Apr 2018 09:44:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Wed, 4 Apr 2018 09:44:48 -0700 (PDT) In-Reply-To: <5AC5006C.4050308@redbarn.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> From: Ben Schwartz Date: Wed, 4 Apr 2018 12:44:48 -0400 Message-ID: To: Paul Vixie Cc: Ted Lemon , dnsop@ietf.org, DoH WG , Ray Bellis Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11449fe4a596b20569088a91" Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:44:53 -0000 --001a11449fe4a596b20569088a91 Content-Type: multipart/alternative; boundary="001a11449fe4992ba60569088a00" --001a11449fe4992ba60569088a00 Content-Type: text/plain; charset="UTF-8" If the stub and forwarder are both on your laptop, why do you need to truncate? Local UDP should have extremely large MTU. On Wed, Apr 4, 2018 at 12:42 PM, Paul Vixie wrote: > > > Ted Lemon wrote: > >> On Apr 4, 2018, at 11:49 AM, Paul Vixie > > wrote: >> >>> this is a far thinner solution than a full-service resolver, which >>> would require local configuration and monitoring and so on, as well as >>> topology stability that can't be guaranteed. >>> >> >> For your laptop use case, why wouldn't you just have the thing running >> on the laptop do truncation if the answer is too long? >> > > that would be low fidelity. i need to run clients whose internet > experience will not be influenced by middleboxes. > > I admit that this is more code, but it's not a lot more code, and >> what you're doing instead is pretty hacky. >> > > feel free to try it out: > > https://github.com/BII-Lab/DNSoverHTTP > > or: > > https://github.com/BII-Lab/DNSoverHTTPinGO > > these are out of date with respect to the current draft, but each works. i > would like to see a standard that they can conform to, so that i'm safe > building a larger infrastructure. > > The fact that it's not required to implement doesn't mean that it >> doesn't contribute to the camel problem. >> > > are we at the point where any of us can call anything we see no use for > part of the camel problem? i'm hoping not, and so i'm going to ignore your > statement here. > > "if you want to do this, here's an interoperable method" is this group's > meme. it's not "this is the best engineering solution we were able to > create for the problem we are willing to admit you might have." > > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11449fe4992ba60569088a00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the stub and forwarder are both on your laptop, why do = you need to truncate?=C2=A0 Local UDP should have extremely large MTU.

On Wed, Apr 4, 2= 018 at 12:42 PM, Paul Vixie <paul@redbarn.org> wrote:


Ted Lemon wrote:
On Apr 4, 2018, at 11:49 AM, Paul Vixie <paul@redbarn.org
 <mailto:paul@redba= rn.org>> wrote:
this is a far thinner solution than a full-service resolver, which
would require local configuration and monitoring and so on, as well as
topology stability that can't be guaranteed.

For your laptop use case, why wouldn't you just have the thing running<= br> on the laptop do truncation if the answer is too long?

that would be low fidelity. i need to run clients whose internet experience= will not be influenced by middleboxes.

I admit that this is more code, but it's not a lot more code, and
what you're doing instead is pretty hacky.

 feel free to try it out:

https://github.com/BII-Lab/DNSoverHTTP

or:

https://github.com/BII-Lab/DNSoverHTTPinGO

these are out of date with respect to the current draft, but each works. i = would like to see a standard that they can conform to, so that i'm safe= building a larger infrastructure.

The fact that it's not required to implement doesn't mean that it doesn't contribute to the camel problem.

 are we at the point where any of us can call anything we see no use for par= t of the camel problem? i'm hoping not, and so i'm going to ignore = your statement here.

"if you want to do this, here's an interoperable method" is t= his group's meme. it's not "this is the best engineering solut= ion we were able to create for the problem we are willing to admit you migh= t have."


--
P Vixie

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a11449fe4992ba60569088a00-- --001a11449fe4a596b20569088a91 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCrV0WeC5o0xuzugpRN15no DMIkFjOftdyewSRnFLffqzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA0MDQxNjQ0NTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFXfllVRk34qifGyazxDMo4pwGH2zjNORZ1hoPyZ9 jHO8Xh+VQlMG4QgligJo4Ngl3VHhfXS5SYzIBMo9Cj7ZkyJShzfKRUkgEmkP61PqlSQUNKOwnXrV iZPftVF6dhgdT+nXBu6tLGx9vtxroJLRwo1OdsWL8ZfWFPkL0v0qN00S6E6EWqwT6460Ebh1oVMH bkz/u2cSMNgTzNFU2plvfvXGmN1KWeOJR7LPTajTHcCC8On3wqREePNopZJR6HaTsheOPpdupLN0 yOvgDHjt+8axlTKKryRQoTY0uSxPNeS/B/+UToZ+n7PiQpmbcHOuMRCxcozWDISFM22ikYvNXA== --001a11449fe4a596b20569088a91-- From nobody Wed Apr 4 09:46:32 2018 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 1DC40129C5D; Wed, 4 Apr 2018 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Gl9F9nq13q61; Wed, 4 Apr 2018 09:46:28 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B9E126D3F; Wed, 4 Apr 2018 09:46:28 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 02AAD7594C; Wed, 4 Apr 2018 16:46:27 +0000 (UTC) Message-ID: <5AC50154.4020009@redbarn.org> Date: Wed, 04 Apr 2018 09:46:12 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ben Schwartz CC: Ted Lemon , dnsop@ietf.org, DoH WG , Ray Bellis References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:46:30 -0000 Ben Schwartz wrote: > If the stub and forwarder are both on your laptop, why do you need to > truncate? Local UDP should have extremely large MTU. i know this was addressed to me, but i didn't mention truncation, so it's to me a nonsequitur. -- P Vixie From nobody Wed Apr 4 10:19:28 2018 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 A763412D775 for ; Wed, 4 Apr 2018 10:19: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 gFI9IfX8alti for ; Wed, 4 Apr 2018 10:19:24 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 86962126C22 for ; Wed, 4 Apr 2018 10:19:24 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id h4so23882032qtn.13 for ; Wed, 04 Apr 2018 10:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VgIvyYOHodb2X1mrW0u3aSLzWoMsxY0W5pAvBahIcwA=; b=Bgly5M/ckdyFLV7Kr1v8ngwt3S2+ZBKv+OBz5lvY/piV9pzPVSPY9LM9o+97zoSiH/ AWxDc9f+0N39UnkRYtabzpg/p1WAV3Ydj1LnFtTLb2y0pS6SgWxhxnPe61ezlIWquOAT Ru2UIwbJqeba2rpxHwQDp0VolTWVf3gtct1Hmte18bVSjy07aBstlINbnhSEvbhT0FoZ XKbJl7utYGxFskVPriORvN1FGKgWdFds17+nujC5yvkTuOWoOYtTufPdr5VA9Kwk3wXR 1/u1oNS/AYpIVt2naYrGp6/+r49/kNfufKRgdF3N+GSvg8vNaVHTGDwKWWzy9f+NixYC AXwA== 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=VgIvyYOHodb2X1mrW0u3aSLzWoMsxY0W5pAvBahIcwA=; b=WzUMulotKcd/0xDzW8fTd1RsdsPAOwvzVWHQeQjIBM6F1HDSXVHyTbL1D/hldWsCJ0 zP2W/kpIiXVfYrjkfcSSpLPbSWBhBMryZkU1NBwAuJWEBLtB6DFbQiP2/WbpXOUvAYuO 0Xgci3J/h8XesQzvJ22V1QkUCArqq5UyDhp9/joJp2OFmCP1P3jINzdfUvY9PYCY161n o2sSFJ7KzwunXpnuSiTWv7ssHfeh0YlotRdeVGkrIgUWWhRAMr86GC02RXUZ7Y6WeoiR EvNM9IFTp4yEMsjyltpF7ne/SyP6oi03DNld1SPJdq8AoSoBOu9RqilNs3Omb73OMsKr 0nuw== X-Gm-Message-State: ALQs6tA92HeT2nyNbHMdi504Jm+olRh6Fn57DtfN7mJTzmAD5YkQ6Vxv S+ibFODR+MmhxYjH8C7NnGLrpoZ3hAA= X-Google-Smtp-Source: AIpwx495FHeRBq3Ojt66d2Y7E5xj/YlgVEq3gtMoxlBGcm4H8lC2d+4LKFzcH9ytw2gsWa5D91bOgg== X-Received: by 10.200.15.130 with SMTP id b2mr26751853qtk.322.1522862363623; Wed, 04 Apr 2018 10:19:23 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id k188sm4196641qkb.14.2018.04.04.10.19.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:19:22 -0700 (PDT) From: Ted Lemon Message-Id: <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_34F6B5DD-BC17-4FDD-B616-328837E167CA" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 13:19:21 -0400 In-Reply-To: <5AC5006C.4050308@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:19:27 -0000 --Apple-Mail=_34F6B5DD-BC17-4FDD-B616-328837E167CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 12:42 PM, Paul Vixie wrote: > that would be low fidelity. i need to run clients whose internet = experience will not be influenced by middleboxes. I'm having trouble figuring out where a middlebox would be here that = would reduce fidelity. Isn't the point of what you're doing to = completely bypass any middleboxes that are in the way? I think the diagram looks like this: LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service = Resolver<---internet--->Authoritative servers Where is the middlebox that's going to reduce fidelity? --Apple-Mail=_34F6B5DD-BC17-4FDD-B616-328837E167CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 12:42 PM, Paul Vixie <paul@redbarn.org> = wrote:
that would be = low fidelity. i need to run clients whose internet experience will not = be influenced by middleboxes.

I'm having trouble figuring out where a = middlebox would be here that would reduce fidelity.   Isn't the = point of what you're doing to completely bypass any middleboxes that are = in the way?

I = think the diagram looks like this:

LAPTOP<----link = a---->DNS-over-https-proxy<---link b--->Full Service = Resolver<---internet--->Authoritative servers

Where is the middlebox = that's going to reduce fidelity?

= --Apple-Mail=_34F6B5DD-BC17-4FDD-B616-328837E167CA-- From nobody Wed Apr 4 10:23:43 2018 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 593F1126C22; Wed, 4 Apr 2018 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IHByUSXJz0vH; Wed, 4 Apr 2018 10:23:34 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2278612AF84; Wed, 4 Apr 2018 10:23:33 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 949BA7594C; Wed, 4 Apr 2018 17:23:32 +0000 (UTC) Message-ID: <5AC50A04.6030407@redbarn.org> Date: Wed, 04 Apr 2018 10:23:16 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> In-Reply-To: <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:23:38 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 12:42 PM, Paul Vixie > wrote: >> that would be low fidelity. i need to run clients whose internet >> experience will not be influenced by middleboxes. > > I'm having trouble figuring out where a middlebox would be here that > would reduce fidelity. Isn't the point of what you're doing to > completely bypass any middleboxes that are in the way? > > I think the diagram looks like this: > > LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service > Resolver<---internet--->Authoritative servers > > Where is the middlebox that's going to reduce fidelity? you've cut too much context. my answer was to "just truncate". your followup is about "which middlebox." -- P Vixie From nobody Wed Apr 4 10:30:55 2018 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 C916412E878 for ; Wed, 4 Apr 2018 10:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=fugue-com.20150623.gappssmtp.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 FtDnK91WORuu for ; Wed, 4 Apr 2018 10:30:48 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 A4FB612E04A for ; Wed, 4 Apr 2018 10:30:48 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o205so23341687qke.3 for ; Wed, 04 Apr 2018 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tkmWTuLjMd6OQ2pR0rkt2p2lK6k2NQNAgI7D+plf4eY=; b=zj2JXXzldfz7elWArbmhGKLxDETp0cnPKVopIl920WnN9u7EquG+8FFJVaNPt1llo7 lOW2JlMQxTsxqRIRUWm3VRFaZIeAu67m/+Ae2gigW6/17nTsyJdPiIfnHpM2Pu+fVWE6 tbnYcOohYe6uvuhRCXhPdf6uajOA/yaOMtjc2Jd+q0xq9btbR2i9s5aCitVyk+3r3gmj dcMgTX+owhFW9PFOOEC9NJAdk08N7GI8lGBGDWIxHjeLUtPis5/33Q80aMx8iWRj/fGg MzURQZdUvuJ5ByfhKMDdWqO3J4QZgON3X0iwPpNRoaHp8rpRHFpLuJ7DEGdjAfKWqmUy lRFw== 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=tkmWTuLjMd6OQ2pR0rkt2p2lK6k2NQNAgI7D+plf4eY=; b=j6Xi5N9icGhOJXKnYoTc+chNwHLYAwIV3GpcKCU6yMKsfi5IBSbCWcSJEmBasoGjWl ZeNv5MLwjjifTvhMr6Xhv5L18sswLGSDp9J/HldRAB0qkP3em7SWYjOZuDacKBkS4EmZ Uy6fGeD9m3KLGtxc6/ElW1YB/Lw5Ckmy/nwEROHjlsnrvVL4L8mTHupT4TCLpWKfwejg wbVtpBeB4kvb4p1ok0goYVPgJiMPwCneGNM6nrA/oHuLcg3zow21+fHYMoABNQvy81O+ 2xipnY66GN/cIwiaPuKFWaYj6V7jmfnKieo2fODtUswmdGokxq78ZeR3ZaEPHG3XpJzz G7NQ== X-Gm-Message-State: ALQs6tCis4bdmsKDeJ04deRwla5ONzdGeV/9V5HJDCtRPs5iaAOyRMyf RlrSOqnNtXrJLm8KYzD+DLRh3A== X-Google-Smtp-Source: AIpwx49R84fa/BGybUKlkiNPvUzuLiFNSdKQA8MVoQZtCAl7T8H1+4YkR472re2o1/RZJ0b7Kw3KFw== X-Received: by 10.55.195.92 with SMTP id a89mr24610707qkj.33.1522863047699; Wed, 04 Apr 2018 10:30:47 -0700 (PDT) Received: from [192.168.1.144] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j19sm4719387qtf.21.2018.04.04.10.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:30:47 -0700 (PDT) From: Ted Lemon Message-Id: <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5A6637F7-6D8A-492D-B010-4F92E95A0595" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 13:30:45 -0400 In-Reply-To: <5AC50A04.6030407@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:30:54 -0000 --Apple-Mail=_5A6637F7-6D8A-492D-B010-4F92E95A0595 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 1:23 PM, Paul Vixie wrote: > you've cut too much context. my answer was to "just truncate". your = followup is about "which middlebox." Here's what I was replying to: >> For your laptop use case, why wouldn't you just have the thing = running >> on the laptop do truncation if the answer is too long? >=20 > that would be low fidelity. i need to run clients whose internet = experience will not be influenced by middleboxes. So you've said that the client's experience will be influenced by = middleboxes. I'm trying to understand what the scenario is where this = would happen. Hence my diagram: LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service = Resolver<---internet--->Authoritative servers That is, what is the problem you are trying to avoid that requires the = proxy to transparently tunnel rather than simply answering the query? --Apple-Mail=_5A6637F7-6D8A-492D-B010-4F92E95A0595 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 1:23 PM, Paul Vixie <paul@redbarn.org> = wrote:
you've cut = too much context. my answer was to "just truncate". your followup is = about "which middlebox."

Here's what I was replying to:

For your laptop use case, why wouldn't you = just have the thing running
on the laptop do truncation if = the answer is too long?

that would be low = fidelity. i need to run clients whose internet experience will not be = influenced by middleboxes.

So you've said that the client's experience will be = influenced by middleboxes.   I'm trying to understand what the = scenario is where this would happen.   Hence my diagram:

LAPTOP<----link a---->DNS-over-https-proxy<---link = b--->Full Service Resolver<---internet--->Authoritative = servers

That is, what is the problem you are trying to avoid that = requires the proxy to transparently tunnel rather than simply answering = the query?

= --Apple-Mail=_5A6637F7-6D8A-492D-B010-4F92E95A0595-- From nobody Wed Apr 4 11:35:45 2018 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 A97E412D775; Wed, 4 Apr 2018 11:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1LWIqPc7IJWZ; Wed, 4 Apr 2018 11:35:41 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE60E126C0F; Wed, 4 Apr 2018 11:35:41 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 915E37594C; Wed, 4 Apr 2018 18:35:40 +0000 (UTC) Message-ID: <5AC51AEC.10603@redbarn.org> Date: Wed, 04 Apr 2018 11:35:24 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org> <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> In-Reply-To: <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:35:43 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 1:23 PM, Paul Vixie > wrote: >> you've cut too much context. my answer was to "just truncate". your >> followup is about "which middlebox." > > Here's what I was replying to: > >>> For your laptop use case, why wouldn't you just have the thing running >>> on the laptop do truncation if the answer is too long? >> >> that would be low fidelity. i need to run clients whose internet >> experience will not be influenced by middleboxes. > > So you've said that the client's experience will be influenced by > middleboxes. i intended this to be heard as "will otherwise be influenced by middleboxes". > I'm trying to understand what the scenario is where this > would happen. Hence my diagram: > > LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service > Resolver<---internet--->Authoritative servers > > That is, what is the problem you are trying to avoid that requires the > proxy to transparently tunnel rather than simply answering the query? the proxy is transparent. from https://github.com/BII-Lab/DNSoverHTTP: > The proxy service does not interpret the DNS query or response in any > way. It could be DNS, EDNS, or something not yet invented at the time > of this writing. The only requirement is that each request message > solicits exactly one response message. If anything at all goes wrong > with the proxy service, the stub client will hear a DNS SERVFAIL > response. i intend that the endpoints (who are real dns speakers and listeners) be able to evolve, or never evolve, according to their own drumbeats. the real middlebox that's otherwise in the way is in my hotel room or coffee shop, and knows that udp/53 is a service address, and policy-routes my dns traffic to its own agent, which thinks it knows what DNS has to look like, and can't handle modern (1999-era) extensions like EDNS. by putting these messages inside https (a virtual high fidelity middle box), i make them invisible to the hotel's physical low fidelity middle box. and by respecting the originator's transport choice, i remain transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so on, in whatever order it wants to do. could this be done with a resolver using non-proxy DOH as a transport to its forwarder? sure. but that puts semantic intelligence in the middle, which will introduce configuration, logging, monitoring, diagnosis, upgrade, and patching costs. i don't want those here. -- P Vixie From nobody Wed Apr 4 11:45:04 2018 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 51FC8120713 for ; Wed, 4 Apr 2018 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 KZ1eXOpz7rvn for ; Wed, 4 Apr 2018 11:44:55 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 AB07F12D7E5 for ; Wed, 4 Apr 2018 11:44:55 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o64so23592592qkl.7 for ; Wed, 04 Apr 2018 11:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tp8SkonCyPDPl6ldo/j8e0QRF1IjjXkQ6UsA3ope+3A=; b=pyvzblfrHUEPcL/nc3V6s2pJNg1/Bg5uJdRUJnGCK4Ni3+Oo9ZisBV+oCiB1X0M83o BXkwHd0q841EF9j5/eHWKZ0eN/YVR2fqC6S6PN+8E+z3nZe2j92PSsOAK27cl7ymfgdc DFPk3eToWhWsYFhMDwbasy27oFzzyW+AT5VxQR4KCcGbbO6z8mR2pmN0J7jVNbx87zJU 585IsEfNbNrJu86wCWmoc/jTVqkBgJTWot7DJOe76WMpWqVhJ4lDtUVLA/ixDE8r7s3I 8KeSzV6oUEma1loGaSiQlJ7g9NrwpZtIoVzrXZmKHUSd0OzdFoCjpy11Hmr3/y4HIoPA yvBA== 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=Tp8SkonCyPDPl6ldo/j8e0QRF1IjjXkQ6UsA3ope+3A=; b=cD1TQ6sRUq8mR7Y1pSX5TS23qeonQEHk8KLDV3mZjgBsyig3JqV6vWs5KojJ+tkSyI DoSj6HVWDdSeNJ6uP3UAYZtiQPcVUuldCW+eSFtP6zXvViLeRM4xYgIwPEN3CpR19GUb 1oGA0dayAn860YuBLia7beZhS1GTBNKtgVjSV4C+EvQ9R75hKqaXxWYrEyDROb8dHw6i B62sPgbCTZVWWGQ2QDJPXS4irTtvYkgqtfTyxHbR21HYxZ/Dyv821YyBCa1OeV2MvHaJ Ba+lppHtEPDAK6yfqEq04B6V1FxnC1tojf0iXrAUdD8mw0ORgRfhG0MRLA9wqi60iAFJ QN7Q== X-Gm-Message-State: ALQs6tCgKiIlU1N5+EQFm6KVUFNiL5aQpDdWp3NvkJAQK7U65S0wr0v2 WDRo4+kAzuCse2yTisAkma5eP/aIkiI= X-Google-Smtp-Source: AIpwx4/UcIMgu2o36/t/DKjYk6BZJVBwZgAp2oEIqxTHwAS+rsIb90vcyVjIYnMhhpxQ3g+m9Bn1kg== X-Received: by 10.55.192.20 with SMTP id o20mr25303595qki.257.1522867494795; Wed, 04 Apr 2018 11:44:54 -0700 (PDT) Received: from [192.168.1.144] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d198sm4409575qkg.91.2018.04.04.11.44.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 11:44:54 -0700 (PDT) From: Ted Lemon Message-Id: <24035AD9-C0C4-4BE4-A58A-0E010FB3D0F6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1F75059F-C875-4309-B3A6-232F1A6D4E5C" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 14:44:53 -0400 In-Reply-To: <5AC51AEC.10603@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org> <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> <5AC51AEC.10603@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:44:59 -0000 --Apple-Mail=_1F75059F-C875-4309-B3A6-232F1A6D4E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 4, 2018, at 2:35 PM, Paul Vixie wrote: > could this be done with a resolver using non-proxy DOH as a transport = to its forwarder? sure. but that puts semantic intelligence in the = middle, which will introduce configuration, logging, monitoring, = diagnosis, upgrade, and patching costs. i don't want those here. So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the = destination port? --Apple-Mail=_1F75059F-C875-4309-B3A6-232F1A6D4E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Apr 4, 2018, at 2:35 PM, Paul Vixie <paul@redbarn.org> = wrote:
could this be = done with a resolver using non-proxy DOH as a transport to its = forwarder? sure. but that puts semantic intelligence in the middle, = which will introduce configuration, logging, monitoring, diagnosis, = upgrade, and patching costs. i don't want those here.

So essentially this is {UDP | TCP}-over-HTTPS, with = constraints on the destination port?


= --Apple-Mail=_1F75059F-C875-4309-B3A6-232F1A6D4E5C-- From nobody Wed Apr 4 11:58:12 2018 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 84AC912D775; Wed, 4 Apr 2018 11:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tq4pTV0Bnlkk; Wed, 4 Apr 2018 11:58:02 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3489D126D45; Wed, 4 Apr 2018 11:58:02 -0700 (PDT) Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 928CC7594C; Wed, 4 Apr 2018 18:58:01 +0000 (UTC) Message-ID: <5AC52029.9000103@redbarn.org> Date: Wed, 04 Apr 2018 11:57:45 -0700 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Ted Lemon CC: Ray Bellis , dnsop@ietf.org, doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org> <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> <5AC51AEC.10603@redbarn.org> <24035AD9-C0C4-4BE4-A58A-0E010FB3D0F6@fugue.com> In-Reply-To: <24035AD9-C0C4-4BE4-A58A-0E010FB3D0F6@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:58:03 -0000 Ted Lemon wrote: > On Apr 4, 2018, at 2:35 PM, Paul Vixie > wrote: >> could this be done with a resolver using non-proxy DOH as a transport >> to its forwarder? sure. but that puts semantic intelligence in the >> middle, which will introduce configuration, logging, monitoring, >> diagnosis, upgrade, and patching costs. i don't want those here. > > So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the > destination port? no. it uses a DNS response message of rcode SERVFAIL for error signalling. so, it is as transparent as possible, and no more. -- P Vixie From nobody Wed Apr 4 12:12:18 2018 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 3A13512DA6B for ; Wed, 4 Apr 2018 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=fugue-com.20150623.gappssmtp.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 Uca5EaNvo1Mb for ; Wed, 4 Apr 2018 12:12:15 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 619B512DA68 for ; Wed, 4 Apr 2018 12:12:15 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id s78so23677995qkl.8 for ; Wed, 04 Apr 2018 12:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=x8sERHXdCp0C3vt4KTrHIIDcCXeu95DqTauHmzGU8pw=; b=dys1V7tDflJXhfwctQIdqd6DHLN1BOXIbuWhFaBnyA6bb/p61Bu+GXqP3vvoLPvmqI BJ2U7sxD2mcpLqdVSjO/SyXhH6+/MvcYb+ynkmd1wk6YHFFDqKUkLrTn5cc9IxY2o0vf +vi3nid/JvxnQ6FnQHDFVS0Q4VoHx7ewhfd2LmbDwuu3Hb/2kQ1/DAiaQOvXw/SOcIGY kfbQz1LcNt2+o/QoMq4GvqCL7OwwGtf1I0WyfEZVWo63uEwbk6wLj0kPoNhZgwiV2E1l HyLbP1jOVSl/ZuBovKX8bvx3u47fxJqlh7X2xdyNzGLmlttzZBK+imOy7h06g29JzGKS aXPQ== 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=x8sERHXdCp0C3vt4KTrHIIDcCXeu95DqTauHmzGU8pw=; b=nDDJSu5/wGEZgcSp/0wwhj1dM7A8ejY3qNfChERuKSsAik57gwyvrl1j8xJ8NXHCtx Sq1+St7U4RjGydCV/o76IeJk3jB5I66TWi9mfTIIsc2DR0cMlLamEcq05aZiqUb3CIVj YAVf/C0G3Du0p9aXpLNvfHo+5eaGRDw5YtXTgb9GdGRs5q3LyifYidr9CL2PsbexKUOL c4IzREFe9rzMC4SBExIxf9D+VRd+EoAq1rN5qA2f3AU2uOlDs+YmnPUWE28rf42Q3GHd Rq5SBTniW1mPKD1R4OTm9u4o8/aQ6QGaEqtjSrhpf7NWXgOYI7GUho0+JLkn29woHmSd kHug== X-Gm-Message-State: ALQs6tAiDliWgqGJvb7eXT8yCB0rHlWaIBAC41BMSn9o394/Cv1T0glQ v1GUED+rXLLWXvZvZ8piJefjvoPacEY= X-Google-Smtp-Source: AIpwx49s2a0mltyiIQPEX+Zi3V6Ks3pZlteYeng7GpmIyLvGZzYCjy24+giQ1xI/NKEfGlLEmerIEA== X-Received: by 10.55.26.86 with SMTP id a83mr24742999qka.165.1522869134364; Wed, 04 Apr 2018 12:12:14 -0700 (PDT) Received: from [192.168.1.144] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id w21sm1324579qto.48.2018.04.04.12.12.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 12:12:13 -0700 (PDT) From: Ted Lemon Message-Id: <53502E6D-8AB9-4198-9824-5F070FC763D7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F9DB2B5D-5B70-4B4C-BAF5-5287F38BEC38" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 15:12:12 -0400 In-Reply-To: <5AC52029.9000103@redbarn.org> Cc: Ray Bellis , dnsop@ietf.org, doh@ietf.org To: Paul Vixie References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org> <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com> <5AC51AEC.10603@redbarn.org> <24035AD9-C0C4-4BE4-A58A-0E010FB3D0F6@fugue.com> <5AC52029.9000103@redbarn.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 19:12:17 -0000 --Apple-Mail=_F9DB2B5D-5B70-4B4C-BAF5-5287F38BEC38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 4, 2018, at 2:57 PM, Paul Vixie wrote: > no. it uses a DNS response message of rcode SERVFAIL for error = signalling. so, it is as transparent as possible, and no more. Okay. So the upstream proxy is intended to simply take the "tcp" or = "udp" indication and do the query using tcp or udp as indicated? What = if I write a proxy that doesn't support this behavior=E2=80=94will your = downstream proxy fail to interoperate with it? E.g., if it does the = query using TCP, or automatically fails over to TCP if it gets a = truncated response, and therefore returns a long response to a UDP = query, will bad things happen? --Apple-Mail=_F9DB2B5D-5B70-4B4C-BAF5-5287F38BEC38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 4, 2018, at 2:57 PM, Paul Vixie <paul@redbarn.org> = wrote:
no. it uses a = DNS response message of rcode SERVFAIL for error signalling. so, it is = as transparent as possible, and no more.

Okay.   So the upstream proxy is = intended to simply take the "tcp" or "udp" indication and do the query = using tcp or udp as indicated?   What if I write a proxy that = doesn't support this behavior=E2=80=94will your downstream proxy fail to = interoperate with it?   E.g., if it does the query using TCP, or = automatically fails over to TCP if it gets a truncated response, and = therefore returns a long response to a UDP query, will bad things = happen?

= --Apple-Mail=_F9DB2B5D-5B70-4B4C-BAF5-5287F38BEC38-- From nobody Wed Apr 4 14:11:43 2018 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 4C1EA126BF0; Wed, 4 Apr 2018 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 tcpu8ZEzxKFO; Wed, 4 Apr 2018 14:11:36 -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 1223412D967; Wed, 4 Apr 2018 14:11:33 -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]:43451) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f3pgn-000vpp-eA (Exim 4.89_2) (return-path ); Wed, 04 Apr 2018 22:11:29 +0100 Date: Wed, 4 Apr 2018 22:11:29 +0100 From: Tony Finch To: Paul Vixie cc: Ted Lemon , dnsop@ietf.org, doh@ietf.org, Ray Bellis In-Reply-To: <5AC5006C.4050308@redbarn.org> Message-ID: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:11:39 -0000 Paul Vixie wrote: > Ted Lemon wrote: > > > > For your laptop use case, why wouldn't you just have the thing running > > on the laptop do truncation if the answer is too long? > > that would be low fidelity. I'm interested to know what breaks with something like dnscrypt-proxy or stubby that works with your proxy. >From a quick look, I think your proxy doesn't handle AXFR and (more generally) doesn't map client TCP connections onto server TCP connections, so it doesn't allow a client to distinguish between servers that have serial vs concurrent DNS-over-TCP request handling in a way that a truly high-fidelity tunnel would. Tony. -- f.anthony.n.finch http://dotat.at/ Cromarty, Forth: North 5 to 7, occasionally gale 8 in Forth, becoming variable 3 or 4. Moderate or rough. Sleet, fair later. Good occasionally poor. From nobody Wed Apr 4 21:45:46 2018 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 1EA08127136; Wed, 4 Apr 2018 21:45:39 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 48N0wIb66GSB; Wed, 4 Apr 2018 21:45:37 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 A456F126C89; Wed, 4 Apr 2018 21:45:37 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id y46-v6so25859790otd.4; Wed, 04 Apr 2018 21:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxX5gvcbXXlrC0tr+du3F7AVBvLDJYxGdmJ/6/7VL6s=; b=aH/XvXUdph2GtKyecHK2j1DEFFsxrFTh0lif5BlRaHeFJFM6fa2GxR1yuxuf+woIzw q+aXOPSkDhRPIAeFv/6TjJFT0oPTBf0cJKoBEtz+BpZxMONxzl2qKwYwxlqVj+C8/2Zz 7qt3Djpr3OhGwbDZI9W2JcjLyTJi5i8RIE+pGKllhX6L351LYBWFo0zsAOpFSazKkVHo HBHR2bG9mGpS8h4sH1+L9lhMlbeqo9E+QKqkZ48w+N2hVVVKAH+ZUgCKP3tIphj2XbvP H1anYbhNDddkUp/kq+OufVmcLvm24lqoD7XqCuHbFv7gnN9GYXNEc5a+ZckBev98A4TR JzGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxX5gvcbXXlrC0tr+du3F7AVBvLDJYxGdmJ/6/7VL6s=; b=F9uddpaxKwIbtwRzwHNVrf7X7LIOR5bvoHE/FB6OirRR5CwEtsjLhjtLN8paYOt0pX DxmoEUC1yqiMjsvURZXLhU+ECOBF8435McQiyt0/zj0fHujFNRWBlXkrv4GwQ+MMSGwi NLprq4drhTpjPknM1kRHd70SraxSe4HU++5RnewFDOQ/iRLJxMN4mJ00FJEEJAHlgCw8 IndfuCQLXZ05uwWK4Loa68tC+Mlx5ACkPloNn+EDlP8FllWjbxKhiVhYP8TnpYCv0MJ2 +zTeZZqiKXn4MmyGMukCtMReLv9vnAcD0r7XUmnrm36nlL10kLJvjaKwZZn4Unyme0ve sAxQ== X-Gm-Message-State: ALQs6tAAJMg5ZWsTNpRZXoxCzVr0hHrax0MCyquoUkf4oAUsnh+unr3r elu9KUC0mT0Ex/19RByZuQpPpEzJ0wP2c0mbwoU= X-Google-Smtp-Source: AIpwx4+OiAVy3J3xmQLsyD+/rIqvi4abKpVmqzDwPWC0yPlxQrfvVCcsk8vcvxJDQKrFHSl4d07jf3a3tDv1q1dKbKk= X-Received: by 2002:a9d:1311:: with SMTP id f17-v6mr130849ote.15.1522903537006; Wed, 04 Apr 2018 21:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 21:45:36 -0700 (PDT) In-Reply-To: <5AC5006C.4050308@redbarn.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <5AC5006C.4050308@redbarn.org> From: Martin Thomson Date: Thu, 5 Apr 2018 14:45:36 +1000 Message-ID: To: Paul Vixie Cc: Ted Lemon , dnsop , DoH WG , Ray Bellis Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:45:39 -0000 On Thu, Apr 5, 2018 at 2:42 AM, Paul Vixie wrote: > that would be low fidelity. i need to run clients whose internet experience > will not be influenced by middleboxes. So don't include the middlebox in your communications. It's all the rage nowadays. From nobody Thu Apr 5 13:54:02 2018 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 236C012D7E8; Thu, 5 Apr 2018 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHUDsb-2qXg8; Thu, 5 Apr 2018 13:53:53 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 4133912D7E4; Thu, 5 Apr 2018 13:53:53 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id C5D093A081; Thu, 5 Apr 2018 16:53:52 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id f63-v6so11827793oic.4; Thu, 05 Apr 2018 13:53:52 -0700 (PDT) X-Gm-Message-State: AElRT7HC7PFBX2JeZICMNmjTO6v0tLFZp8DkZXJhCTulMOZHFhGhJsy4 a6dn49tqokrDJDW1zYdh8lz3cdIkPZ5+m+EkjK4= X-Google-Smtp-Source: AIpwx4/rQIlqXgaggULd9UjCFcqDW4FW4tZYc1gFklxp/NIstIoURV0HTMFVJl2jQwgmaWMFNcclI54TNa9FJ3anuBE= X-Received: by 2002:aca:cd42:: with SMTP id d63-v6mr14301227oig.213.1522961632395; Thu, 05 Apr 2018 13:53:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Thu, 5 Apr 2018 13:53:51 -0700 (PDT) From: Patrick McManus Date: Thu, 5 Apr 2018 16:53:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: Paul Vixie , dnsop , DoH WG , Ted Lemon , Ray Bellis Content-Type: multipart/alternative; boundary="0000000000001b09ee0569202346" Archived-At: Subject: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:53:55 -0000 --0000000000001b09ee0569202346 Content-Type: text/plain; charset="UTF-8" Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 6838), I think including this in doh is premature because Media Type registrations can be updated by mechanisms laid out in RFC6838 and in this case such an update could occur without impacting existing DoH deployments. (i.e. it does not need to be future proofed). Therefore the definition of the parameter should accompany the work that makes use of it if a future standards document chooses to go down that path. As a bonus we avoid unused clutter if it doesn't happen. I also get the feeling that there isn't yet strong consensus on the anticipated use case or the exact form it needs to take - we should let that process work itself out separately before registration. I've chatted with Paul, and our recommendation is to remove the original_transport parameter from DoH and encourage dnsop to update the registration if/when a different standard needs to make use of it. thoughts? -Patrick --0000000000001b09ee0569202346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

We've had quite = a thread re the -05 optional parameter to the dns-udpwireformat registratio= n.

The parameter is defined as having no meaning f= or DoH, but was included to accommodate a use case the dnsop wg is consider= ing. Future proofing, if you like.

Upon consid= eration (and a read of 6838), I think including this in doh is premature be= cause Media Type registrations can be updated by mechanisms laid out in RFC= 6838 and in this case such an update could occur without impacting existing= DoH deployments. (i.e. it does not need to be future proofed).
<= br>
Therefore the definition of the parameter should accompany th= e work that makes use of it if a future standards document chooses to go do= wn that path. As a bonus we avoid unused clutter if it doesn't happen. = I also get the feeling that there isn't yet strong consensus on the ant= icipated use case or the exact form it needs to take - we should let that p= rocess work itself out separately before registration.

I've chatted with Paul, and our recommendation is to remove th= e original_transport parameter from DoH and encourage dnsop to update the r= egistration if/when a different standard needs to make use of it.

thoughts?

-Patrick
<= br>
--0000000000001b09ee0569202346-- From nobody Thu Apr 5 13:57:01 2018 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 2CECC12D7E8; Thu, 5 Apr 2018 13:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=akamai.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 GPqWcJo5qgzq; Thu, 5 Apr 2018 13:56:51 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 C1E2A12D7E4; Thu, 5 Apr 2018 13:56:51 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35Kqcc4001289; Thu, 5 Apr 2018 21:56:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=a0ZKYv5l0tD4/+ekm3GYFmrqU0zx6HGfB/kkggMuMbo=; b=kULKCi0dB/ehXICCogm4VgxvDx27olXsUwvdkhvTGjWI8FfwxteT+8yL4kVDecnDP+fU aXPa++TiCfkb6DqF9FN2QqoXWTzv7QC3GzF/nmzUvIuxSF3+WWbwvQX1t9b/+AaVVrsF Cm/a/sgY2wxvBtguh37MXSz0KdAbLHSgA+/zktgeg71xIFaMIthzS+WseG9eTV2wVuM+ MJ3ZmgzSVuOanEjzC/gIGarzVWc8S3KboXbShMXi1ASTtpnnlmEz3yBklKq1PPero+Wj uiRhfh1yD4+HBV1boL3OpThd3I4dopReJNmHDm20Sc7/g+auE3hRlA1C0RR0Fc1SDpfj Ww== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g5apc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 21:56:42 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35KpRhl001932; Thu, 5 Apr 2018 16:56:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nvcbhx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 16:56:41 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Apr 2018 16:56:41 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Thu, 5 Apr 2018 16:56:40 -0400 From: "Hewitt, Rory" To: Patrick McManus , Martin Thomson CC: Ted Lemon , dnsop , DoH WG , Paul Vixie , Ray Bellis Thread-Topic: [Doh] re original_transport indicator Thread-Index: AQHTzSA/Hoab/GGFzky8kAfRAazUvaPypqMA Date: Thu, 5 Apr 2018 20:56:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017B_01D3CCE5.EB3A9B20" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050211 Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:56:54 -0000 ------=_NextPart_000_017B_01D3CCE5.EB3A9B20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_017C_01D3CCE5.EB3A9B20" ------=_NextPart_001_017C_01D3CCE5.EB3A9B20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Good idea - future-proofing is great in theory, but it sounds like there's a lot of non-consensus on the DNSOP side that we might end up adding something that is superseded anyway. Rory From: Patrick McManus [mailto:pmcmanus@mozilla.com] Sent: Thursday, April 5, 2018 1:54 PM To: Martin Thomson Cc: Ted Lemon ; dnsop ; DoH WG ; Paul Vixie ; Ray Bellis Subject: [Doh] re original_transport indicator Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 6838), I think including this in doh is premature because Media Type registrations can be updated by mechanisms laid out in RFC6838 and in this case such an update could occur without impacting existing DoH deployments. (i.e. it does not need to be future proofed). Therefore the definition of the parameter should accompany the work that makes use of it if a future standards document chooses to go down that path. As a bonus we avoid unused clutter if it doesn't happen. I also get the feeling that there isn't yet strong consensus on the anticipated use case or the exact form it needs to take - we should let that process work itself out separately before registration. I've chatted with Paul, and our recommendation is to remove the original_transport parameter from DoH and encourage dnsop to update the registration if/when a different standard needs to make use of it. thoughts? -Patrick ------=_NextPart_001_017C_01D3CCE5.EB3A9B20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

= Good idea - future-proofing is great in theory, but it sounds like = there's a lot of non-consensus on the DNSOP side that we might end up = adding something that is superseded anyway.=

=  

= Rory

=  

From: Patrick McManus = [mailto:pmcmanus@mozilla.com]
Sent: Thursday, April 5, 2018 = 1:54 PM
To: Martin Thomson = <martin.thomson@gmail.com>
Cc: Ted Lemon = <mellon@fugue.com>; dnsop <dnsop@ietf.org>; DoH WG = <doh@ietf.org>; Paul Vixie <paul@redbarn.org>; Ray Bellis = <ray@bellis.me.uk>
Subject: [Doh] re original_transport = indicator

 

Hi = All,

 

We've had quite a thread re the -05 optional parameter = to the dns-udpwireformat registration.

 

The parameter is defined as having no meaning for DoH, = but was included to accommodate a use case the dnsop wg is considering. = Future proofing, if you like.

 

Upon consideration (and a read of 6838), I think = including this in doh is premature because Media Type registrations can = be updated by mechanisms laid out in RFC6838 and in this case such an = update could occur without impacting existing DoH deployments. (i.e. it = does not need to be future proofed).

 

Therefore the definition of the parameter should = accompany the work that makes use of it if a future standards document = chooses to go down that path. As a bonus we avoid unused clutter if it = doesn't happen. I also get the feeling that there isn't yet strong = consensus on the anticipated use case or the exact form it needs to take = - we should let that process work itself out separately before = registration.

 

I've chatted with Paul, and our recommendation is to = remove the original_transport parameter from DoH and encourage dnsop to = update the registration if/when a different standard needs to make use = of it.

 

thoughts?

 

-Patrick

 

------=_NextPart_001_017C_01D3CCE5.EB3A9B20-- ------=_NextPart_000_017B_01D3CCE5.EB3A9B20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDQwNTIwNTYzOFowIwYJKoZIhvcNAQkEMRYEFEqpYq2hvuqHEbVa1K1JuDTCWjJlMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAIEwSrT1rgr7hvI7EWWf8cAs3Cqifn3LdemwugdwikQ49GTehBl2avvAz+d1 g/II1QYzmQRfrDhhF8jR66NdpwOeAjFvmasDOSrl5jmjk8mK+G/2/1h9ZyKsNzMfYp2FE2OUFcBi j+O6xJXHB/siUb4rgqksk90WVr0ICWnUEiVj10ZMFN1lvNG3aYjkghIIso5ydk2QUboICMsYEomQ aU2++Nd8GP56Knu07xLNDkdnOzPx+3q0TDez5lX3MrGJZQjUmw9B3swkRRikrpSFbOa88tqZZkiS 9hEBmKCiDafgecwP9DBeH5OuTn1Bf3z9Mu3ebaE+z1imY2Rq031ic8UAAAAAAAA= ------=_NextPart_000_017B_01D3CCE5.EB3A9B20-- From nobody Thu Apr 5 18:12:13 2018 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 0EE811252BA; Thu, 5 Apr 2018 18:12:11 -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, FREEMAIL_FROM=0.001, 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=gmail.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 eDV-Su_a1ZuM; Thu, 5 Apr 2018 18:12:09 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 EECAF1200A0; Thu, 5 Apr 2018 18:12:08 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 188-v6so24147066oih.8; Thu, 05 Apr 2018 18:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AzBiRJWqPDZpMb2hezClDiI8osS5/IpvKF/3+ermPDg=; b=IP+QrvXdyxaTCp7WbChSS7MCTo+J8jRvVxIg5LPPNSTIafavRwhQ/RpDv32YvIakXH LbCHyJpttnzn6kcjI1Hm5santIbIlI3wKSLXDaY3DF5yHrO9oNMNgllPKxVfKiYR0TqN 0tVcVnFB4J8dA4aHVAwQGjFUqJ6RpS/6xyJs1xVXWG3ykzKtXVHR+0fzB87A7TImSDmQ GSg5z80ZO2bFFTpg+2QEzJNeo131s4PB/9P8Ka1KdcRb9BK50VHr3zUUKvUG1krXfDFz 2CFiNoK9MqH6C0LSihFq03eGSEyzYmPUs6S3BqojNzYdNS42mg/sKzj2EyQIFmq48lxx EGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AzBiRJWqPDZpMb2hezClDiI8osS5/IpvKF/3+ermPDg=; b=R3cOresuCb6tmfqWdaUu4zHY7I4Ash6fvreRuc747aE+Xrlk7TP4kxF5WJw803kkxt PdeSKmiH7MMsMqTcg6Kcnc25UFD10r+a7jjxvXcsR8Gl5RSSDTdPVeFc3aUNLaq6+n3t vccj3RCtA1l9Fz0qjOUVmtBMl8A0IjLlGE4X3MpRwyOKowGo6/kVTz7/552nRq6N22Am W6xSqD8r526tLQZ5WpEuvyhrsRcLW8ghA83zTRB8thkdB4CdT8LayejYWnFkuTOdx1n3 Xf6C6uLDA5tBC6ec4zxKQiipoC1hmRBiT8YVJLucrsAxiC+vvq9S/HlrYro1/VbwAp5W s0Jw== X-Gm-Message-State: ALQs6tAI8VhzzI0K3yHojpWLOpbhDeOQNIIBYZOG/jgJPk2RZDAXaVNY kdE06eVwdOeMQFfcW1blsZ/zNMTZyBmHGTdnM5I= X-Google-Smtp-Source: AIpwx496FKjtlmEN7aW6Kv1iRMXt9SwUHaR1FKLJe23UliHgrB4AM4OQp2J8ho8UI2cqXSRoq7H6w/puRfMOEOG9iTs= X-Received: by 2002:aca:4ac2:: with SMTP id x185-v6mr13163778oia.295.1522977128046; Thu, 05 Apr 2018 18:12:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 5 Apr 2018 18:12:07 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 6 Apr 2018 11:12:07 +1000 Message-ID: To: Patrick McManus Cc: Paul Vixie , dnsop , DoH WG , Ted Lemon , Ray Bellis Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 01:12:11 -0000 +1 to this. And maybe there is an outcome that doesn't need this parameter. I probably misunderstood some of the expectations people have for the parameter. With the benefit of time and sleep, it's possible that I now understand the disconnect. My model of content-type - and by extension its parameters - is of a description of the content. However, it appears as though at least some people had different uses for the parameter: for requests, it would be an instruction/suggestion to the server to make a DNS request using the identified transport; for responses, it would be a description of where the DNS request came from. I never considered that interpretation, but - assuming that this is what it was - and the intent was to provide a means for the client to control how the server makes requests (and to see how they were made). In that case, I have a possible alternative design for the use case in the dnsop draft. Right now, DOH doesn't really say how a DNS API Server gets its responses. It could be that the API server is part of a resolver, or it could be that the DNS API Server makes a request to another resolver. But specific uses of the DOH protocol could come with additional constraints that would enable the use cases in the dnsop draft, at least as I understand them. If the goal of the dnsop draft is to extend the reach of a DNS client (note: not a DNS API client) across a network that is in some way less hostile to HTTP than it is to DNS, then I think that it can still use DOH. A DNS API server could be configured to operate in a very simple mode with no caching, just direct transposition of a request from HTTP to a request on UDP or TCP. A DNS client could be configured with two DNS API clients. Each client uses a different DNS API Server endpoint. Those endpoints would be specifically configured to use only UDP or TCP. For instance: https://use.only/tcp{?dns} would cause the server to make a request using TCP. https://use.only/udp{?dns} would cause the server to make a request using UDP. At this point, this is simple DOH, but with extra contextual information about server operation. The concerns about the requirement for HTTPS is a relevant concern. If there are cases where an unprotected HTTP connection carrying DNS is expected to traverse a network without modification where DNS encounters difficulty, maybe the dnsop draft can concentrate on that particular aspect of this. I don't think that the suggestion in DOH to use HTTP/2 is a problem; DOH permits the use of any version of HTTP. On Fri, Apr 6, 2018 at 6:53 AM, Patrick McManus wrote: > Hi All, > > We've had quite a thread re the -05 optional parameter to the > dns-udpwireformat registration. > > The parameter is defined as having no meaning for DoH, but was included to > accommodate a use case the dnsop wg is considering. Future proofing, if you > like. > > Upon consideration (and a read of 6838), I think including this in doh is > premature because Media Type registrations can be updated by mechanisms laid > out in RFC6838 and in this case such an update could occur without impacting > existing DoH deployments. (i.e. it does not need to be future proofed). > > Therefore the definition of the parameter should accompany the work that > makes use of it if a future standards document chooses to go down that path. > As a bonus we avoid unused clutter if it doesn't happen. I also get the > feeling that there isn't yet strong consensus on the anticipated use case or > the exact form it needs to take - we should let that process work itself out > separately before registration. > > I've chatted with Paul, and our recommendation is to remove the > original_transport parameter from DoH and encourage dnsop to update the > registration if/when a different standard needs to make use of it. > > thoughts? > > -Patrick > From nobody Fri Apr 6 02:49:25 2018 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 AE4771241F5 for ; Fri, 6 Apr 2018 02:49:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OS8qrZNc1xkN for ; Fri, 6 Apr 2018 02:49:21 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) (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 BDD74120725 for ; Fri, 6 Apr 2018 02:49:20 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 23271 invoked from network); 6 Apr 2018 11:49:18 +0200 Received: from agsc6.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.80.6]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 6 Apr 2018 11:49:18 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org References: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> Message-ID: Date: Fri, 6 Apr 2018 11:49:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gFpSv6nRTtUZONRk3DJFNW8tiHgaRgLx6" X-WP-MailID: 561e66ada48bc7f9e3fa22368489c5de X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [ccPk] Archived-At: Subject: Re: [Doh] DOH server on non-standard ports X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 09:49:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gFpSv6nRTtUZONRk3DJFNW8tiHgaRgLx6 Content-Type: multipart/mixed; boundary="HAjy8zBLJPdMc6tDPaG5CJLcG9U7SYHdJ"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org Message-ID: Subject: Re: DOH server on non-standard ports References: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> In-Reply-To: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> --HAjy8zBLJPdMc6tDPaG5CJLcG9U7SYHdJ Content-Type: multipart/mixed; boundary="------------F6419F448C89E5FA752EF682" Content-Language: pl This is a multi-part message in MIME format. --------------F6419F448C89E5FA752EF682 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK, but wouldn't it be beneficial to specify explicitly that DOH clients = MUST support accessing DOH servers on ports other then 443 - for compatibility= reasons? I would propose to add the following text: A DNS API server MAY work on a port other then 443 so all DNS API clients MUST support accessing DOH servers on ports other than 443. at the end of section 4 "The HTTP Request". Greetings, Mateusz Jo=C5=84czyk Patrick McManus on Wed, 04 April 2018 12:50 UTC wrote: > neither https not uris are limited to any particular port. I don't see = a > problem here.. > > W dniu 04.04.2018 o=C2=A012:58, Mateusz Jo=C5=84czyk pisze: >> Hello, >> I think that it may be beneficial to specify that a DOH server MAY wor= k on a >> port other than 443 and that the DOH client MUST support accessing DOH= servers >> on ports other than 443. >>=20 >> I have been thinking about the possibility of adding support for DOH t= o a home >> router. In the future, someone may modify dnsmasq so that it would act= as a DOH >> server - dnsmasq could then run on this router and provide DOH service= s. >> The port 443 would be already used by the router's management interfac= e which >> would probably run as a separate process on this router (as it would b= e an >> entirely different codebase). So dnsmasq would have to provide DOH ser= vices on >> another port. >>=20 >> Greetings, >> Mateusz Jo=C5=84czyk >>=20 --------------F6419F448C89E5FA752EF682 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------F6419F448C89E5FA752EF682-- --HAjy8zBLJPdMc6tDPaG5CJLcG9U7SYHdJ-- --gFpSv6nRTtUZONRk3DJFNW8tiHgaRgLx6 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJax0KcAAoJEPvWWrhhCv7GSXAP+QGu/co4QQ6XDuiv8SN1qZT6 4VZdwUM29qh7jetmggpFMicNLeLfdnpCXiIJjNPY+Z8L5QymNZcXimBJUcTczGfB 0TZ1FoFDwHnExV6auX1YdxdaNnNm0vG1JR8IwkorZnALzRrQytDn7W1gkY3dJGsr 27p6fMSnmZ3Ttw5W9zWz0ng0GfW1wLwL8o8RbXucQJ0h54m4jMFo/YAF5WDEXNju 7jRk6z4wCDx1l/V2CDMppwv/437533tWJbk69820ONGGj8Rxa7V9X5Xk/SKIXS+A pwgiIVAG6Up3JnGJ+qgOQT9X2JDNXtaHV9RMwQibsK8Q+RbwXC8cDF3veK5dnQ4B 5KTEGO/FE4KcicYwC+XMN2BbKaFNKUbbYVBKtktUzCr+nnCGTUkuivS2MePbLJfS IMM4FPQe7StMl1FMc3DS/7y59quMq18Om7yRBN3N0k2wNw/m7pryn1zHZvjc8Y7Q nv7FT4No6hrSzQvKVn5GBFsMTByclu+F7w5FFrd+zynt4rfQvl/49mY7WVEYmyUB MiAvzaSkP+bATRw9sQO/SFMOM21bPYzngN7/jNeWpUf9YkQkt50hz2UNobjL8ijw gr8YUbHI0x4tmaLyBkzlJDpPqeGDrbimhva6zR/iyfO4zEa4u6j0925jHbp2EDFf k856EHo6eTbnBLRrPEcB =yluX -----END PGP SIGNATURE----- --gFpSv6nRTtUZONRk3DJFNW8tiHgaRgLx6-- From nobody Fri Apr 6 10:32:23 2018 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 C903912422F for ; Fri, 6 Apr 2018 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HTKiPOHbUQD for ; Fri, 6 Apr 2018 10:32:19 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51712025C for ; Fri, 6 Apr 2018 10:32:19 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6916E3A03F for ; Fri, 6 Apr 2018 13:32:16 -0400 (EDT) Received: by mail-oi0-f45.google.com with SMTP id u141-v6so1763900oif.1 for ; Fri, 06 Apr 2018 10:32:16 -0700 (PDT) X-Gm-Message-State: ALQs6tDnp0fNpu87KVoq3WMW2CjDsmGfGXwYWOro7A/ZUKUCelu4m5Ry tRfTX4dtcLWFE5KBAFAWAjcEUiUpPQRg3Sh1AXQ= X-Google-Smtp-Source: AIpwx4+I48yiGEsfXd09PcUM9BKxwFxj2Z0lkk+2o+tp48YAm8W/Etrud6BvyW/U2VlqGiwEuh0hiRlvE8h6MTnssZo= X-Received: by 2002:aca:5a44:: with SMTP id o65-v6mr1547094oib.38.1523035936102; Fri, 06 Apr 2018 10:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Fri, 6 Apr 2018 10:32:15 -0700 (PDT) In-Reply-To: References: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> From: Patrick McManus Date: Fri, 6 Apr 2018 13:32:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000f3a13e0569316fc5" Archived-At: Subject: Re: [Doh] DOH server on non-standard ports X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:32:22 -0000 --000000000000f3a13e0569316fc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable one of the nice things about DoH is that it does not squat on any particular part of the URI space which will allow many deployments to integrate DoH into existing servers. (That's actually one of the points of bcp56bis, and a good argument for tossing the .wk url out). obviously, that's not always possible (such as your example) and a different port is required.. but that's not really desirable and is already possible so I don't think I support the change in language. On Fri, Apr 6, 2018 at 5:49 AM, Mateusz Jo=C5=84czyk wr= ote: > OK, but wouldn't it be beneficial to specify explicitly that DOH clients > MUST > support accessing DOH servers on ports other then 443 - for compatibility > reasons? > > I would propose to add the following text: > A DNS API server MAY work on a port other then 443 so all DNS API > clients MUST support accessing DOH servers on ports other than 44= 3. > > at the end of section 4 "The HTTP Request". > > Greetings, > Mateusz Jo=C5=84czyk > > Patrick McManus on Wed, 04 April 2018 12:50 UTC wrote: > > neither https not uris are limited to any particular port. I don't see = a > > problem here.. > > > > W dniu 04.04.2018 o 12:58, Mateusz Jo=C5=84czyk pisze: > >> Hello, > >> I think that it may be beneficial to specify that a DOH server MAY wor= k > on a > >> port other than 443 and that the DOH client MUST support accessing DOH > servers > >> on ports other than 443. > >> > >> I have been thinking about the possibility of adding support for DOH t= o > a home > >> router. In the future, someone may modify dnsmasq so that it would act > as a DOH > >> server - dnsmasq could then run on this router and provide DOH service= s. > >> The port 443 would be already used by the router's management interfac= e > which > >> would probably run as a separate process on this router (as it would b= e > an > >> entirely different codebase). So dnsmasq would have to provide DOH > services on > >> another port. > >> > >> Greetings, > >> Mateusz Jo=C5=84czyk > >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000f3a13e0569316fc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
one of the nice things about DoH is that it does not = squat on any particular part of the URI space which will allow many deploym= ents to integrate DoH into existing servers. (That's actually one of th= e points of bcp56bis, and a good argument for tossing the .wk url out).

obviously, that's not always possible (such as yo= ur example) and a different port is required.. but that's not really de= sirable and is already possible so I don't think I support the change i= n language.

On Fri, Apr 6, 2018 at 5:49 AM, Mateusz Jo=C5=84czyk <mat.jonczy= k@o2.pl> wrote:
OK, but wou= ldn't it be beneficial to specify explicitly that DOH clients MUST
support accessing DOH servers on ports other then 443 - for compatibility r= easons?

I would propose to add the following text:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A DNS API server MAY work on a port other then = 443 so all DNS API
=C2=A0 =C2=A0 =C2=A0 =C2=A0 clients MUST support accessing DOH servers on p= orts other than 443.

at the end of section 4 "The HTTP Request".

Greetings,
Mateusz Jo=C5=84czyk

Patrick McManus on Wed, 04 April 2018 12:50 UTC wrote:
> neither https not uris are limited to any particular port. I don't= see a
> problem here..
>
> W dniu 04.04.2018 o=C2=A012:58, Mateusz Jo=C5=84czyk pisze:
>> Hello,
>> I think that it may be beneficial to specify that a DOH server MAY= work on a
>> port other than 443 and that the DOH client MUST support accessing= DOH servers
>> on ports other than 443.
>>
>> I have been thinking about the possibility of adding support for D= OH to a home
>> router. In the future, someone may modify dnsmasq so that it would= act as a DOH
>> server - dnsmasq could then run on this router and provide DOH ser= vices.
>> The port 443 would be already used by the router's management = interface which
>> would probably run as a separate process on this router (as it wou= ld be an
>> entirely different codebase). So dnsmasq would have to provide DOH= services on
>> another port.
>>
>> Greetings,
>> Mateusz Jo=C5=84czyk
>>

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


--000000000000f3a13e0569316fc5-- From nobody Fri Apr 6 11:06:16 2018 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 573021272E1 for ; Fri, 6 Apr 2018 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NWdkRUzLqQdv for ; Fri, 6 Apr 2018 11:06:04 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA1512D955 for ; Fri, 6 Apr 2018 11:06:04 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 3F48B364E6; Fri, 6 Apr 2018 14:06:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23239.46858.235194.288981@gro.dd.org> Date: Fri, 6 Apr 2018 14:06:02 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <39301825-be3c-5888-ce99-45caf5ab0857@o2.pl> Archived-At: Subject: Re: [Doh] DOH server on non-standard ports X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:06:08 -0000 Patrick McManus writes: > obviously, that's not always possible (such as your example) and a different > port is required.. but that's not really desirable and is already > possible so I don't think I support the change in language. I don't see why any change in language is necessary either. The Internet has a very, very long and rich history of running any given protocol on any given port the end points agree on. I don't know how anyone would reasonably conclude that the only port that DoH could possibly run on is 443, and so adding text to be explicit about it is just unnecessarily superfluous. From nobody Fri Apr 6 16:29:45 2018 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 42721126BF0; Fri, 6 Apr 2018 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SFa5idv--hSo; Fri, 6 Apr 2018 16:29:41 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8407E126E64; Fri, 6 Apr 2018 16:29:41 -0700 (PDT) Received: from [192.168.1.203] (unknown [85.191.60.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 468717594C; Fri, 6 Apr 2018 23:29:39 +0000 (UTC) Message-ID: <5AC802E0.2000200@redbarn.org> Date: Fri, 06 Apr 2018 19:29:36 -0400 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Martin Thomson CC: Patrick McManus , dnsop , DoH WG , Ted Lemon , Ray Bellis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 23:29:43 -0000 Martin Thomson wrote: > +1 to this. > > And maybe there is an outcome that doesn't need this parameter. I > probably misunderstood some of the expectations people have for the > parameter. With the benefit of time and sleep, it's possible that I > now understand the disconnect. > > My model of content-type - and by extension its parameters - is of a > description of the content. However, it appears as though at least > some people had different uses for the parameter: for requests, it > would be an instruction/suggestion to the server to make a DNS request > using the identified transport; for responses, it would be a > description of where the DNS request came from. my original design added an http header, which was seen as even worse. someone suggested adding to the content-type, and i went along with it even though there is no difference in actual type of actual content. > I never considered that interpretation, but - assuming that this is > what it was - and the intent was to provide a means for the client to > control how the server makes requests (and to see how they were made). > In that case, I have a possible alternative design for the use case in > the dnsop draft. > > Right now, DOH doesn't really say how a DNS API Server gets its > responses. It could be that the API server is part of a resolver, or > it could be that the DNS API Server makes a request to another > resolver. But specific uses of the DOH protocol could come with > additional constraints that would enable the use cases in the dnsop > draft, at least as I understand them. this all sounds good to me. > If the goal of the dnsop draft is to extend the reach of a DNS client > (note: not a DNS API client) across a network that is in some way less > hostile to HTTP than it is to DNS, then I think that it can still use > DOH. A DNS API server could be configured to operate in a very simple > mode with no caching, just direct transposition of a request from HTTP > to a request on UDP or TCP. A DNS client could be configured with two > DNS API clients. Each client uses a different DNS API Server > endpoint. Those endpoints would be specifically configured to use > only UDP or TCP. > > For instance: > https://use.only/tcp{?dns} would cause the server to make a request using TCP. > https://use.only/udp{?dns} would cause the server to make a request using UDP. > > At this point, this is simple DOH, but with extra contextual > information about server operation. i am generally supportive of this approach; in fact i wish i'd thought of it. the specifics will be different, as in: /proxy_dns?proto=tcp /proxy_dns?proto=udp but i agree that encoding the original transport in the URI is better than either extending the content-type or adding another http header. --- i object, as before, to "dns-udpwireformat" as a name. these are dns messages, which when carried by udp are raw, and when carried in tcp are preceded by a two-octet length indicator for framing of multiple messages sharing the same stream. so, the string to be registered should be "dns-message". -- P Vixie From nobody Fri Apr 6 21:30:10 2018 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 401A2126FB3; Fri, 6 Apr 2018 21:30:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 A6zZhtwbvEP6; Fri, 6 Apr 2018 21:30:06 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 68BA1124319; Fri, 6 Apr 2018 21:30:06 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id f47-v6so3343040oth.2; Fri, 06 Apr 2018 21:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qkaswSmp4s3rA3XelMuELRMhPj590W3h0YOb7xvlvYw=; b=GBLrQXnZQpYI+9DMhloqVBLDIiwW/Pg2OWDb+91Xmsa7LYRKDna1iiEGa02UAUW18U FVUmx0YnxtKmYsHOcF+8vHYe6CSOyzYVo6yAHoyj7bd/fJAnewvQqyPcdvEbT4wZrWtY CC/G/RBaV3zEiT8PqQbTIcJgexTzlNUuGuRYSI4iXt/q0x2t9aq3yay3S6ihTbdimW4X 4HigxCaHqrQaZdu5XQhnIdOY48ipxisKIxUkoOHeDP4/r87LKDiwY+X7RMZ2Tmn+VuM7 5OznMCgmN66YKC8GzfRPjoZELba+3ItyIHIUrqhAkpNn/TYNYZ65CyyLfuclL35CdnKy JNvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qkaswSmp4s3rA3XelMuELRMhPj590W3h0YOb7xvlvYw=; b=rse/Am/x5ss3VBxyr39XMcQLSS+r0ByijVpSguU5uGHCWNzwJvyFrhrPxL7SKd7IYx DkowzchgQprKRtocHHM1A1F+LroMc2RRMYd3+mLbLA3cikGJHHsV+XGojRczz2594Fg8 6bXhv1L6sOFesmuOUwoZ0Fqvjg7ql9SBZwLXVINpVmXYj9WW/pBwMWn1d91E5advRI/9 HHbkjB7w8UrRWv8Gc6DitqbGlCnpUk1u+tQlWoEWNooEi0oDRfO7Un6zAeMhIeExfBQE xSqXtMawrBi9t2IxoSzfYc06BC/2OmjiFj8dBe9gF5yBOqmTZ1cG9iYCmEkLr1emCTlV w35A== X-Gm-Message-State: ALQs6tCu65FyDiZ5pU+IWertSAFkUfTK7HjPGzq7ZG7wqZb25gDKYNUP RJLUBBJsPoTuO0g66gccxuFqE0AW4rZ2aFpAAI0= X-Google-Smtp-Source: AIpwx4+JkG9MMRM9kLSssJtWyZSmTY6JXhQd/GrGW8Tu9lGUf77Fb0qKFs1wIneoCsL7wWvUs7YzqmUZ0xuEAEHMT5Q= X-Received: by 2002:a9d:1311:: with SMTP id f17-v6mr5616616ote.15.1523075405653; Fri, 06 Apr 2018 21:30:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 21:30:05 -0700 (PDT) In-Reply-To: <5AC802E0.2000200@redbarn.org> References: <5AC802E0.2000200@redbarn.org> From: Martin Thomson Date: Sat, 7 Apr 2018 14:30:05 +1000 Message-ID: To: Paul Vixie Cc: Patrick McManus , dnsop , DoH WG , Ted Lemon , Ray Bellis Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 04:30:08 -0000 On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie wrote: > my original design added an http header, which was seen as even worse. > someone suggested adding to the content-type, and i went along with it even > though there is no difference in actual type of actual content. A header field isn't all bad. At least from my perspective, anyway. That said, it is true that adding to the content is a better choice. I appreciate that this isn't a great fit in this case. > i am generally supportive of this approach; in fact i wish i'd thought of > it. the specifics will be different, as in: > > /proxy_dns?proto=tcp > /proxy_dns?proto=udp .../request{?dns}{?proto} is the way you would write that. > i object, as before, to "dns-udpwireformat" as a name. these are dns > messages, which when carried by udp are raw, and when carried in tcp are > preceded by a two-octet length indicator for framing of multiple messages > sharing the same stream. so, the string to be registered should be > "dns-message". I agree with this principle, and have expressed similar concerns with the name. However, I just checked the media type registry [1] and I think that a better choice is message/dns. Just like message/http and message/sip. [1] https://www.iana.org/assignments/media-types/media-types.xhtml#message From nobody Fri Apr 6 22:10:22 2018 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 C32ED126579; Fri, 6 Apr 2018 22:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1BaBgWbpLvhQ; Fri, 6 Apr 2018 22:10:15 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3B312420B; Fri, 6 Apr 2018 22:10:15 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 65E6436690; Sat, 7 Apr 2018 01:10:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23240.21174.392316.975292@gro.dd.org> Date: Sat, 7 Apr 2018 01:10:14 -0400 From: Dave Lawrence To: dnsop , DoH WG In-Reply-To: References: <5AC802E0.2000200@redbarn.org> Archived-At: Subject: Re: [Doh] [DNSOP] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 05:10:17 -0000 Martin Thomson writes: > I think that a better choice is message/dns. I personally prefer this to dns-udpwireformat / dns-wireformat From nobody Sat Apr 7 12:31:45 2018 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 C546A1205D3; Sat, 7 Apr 2018 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 rZfZlUU-sO38; Sat, 7 Apr 2018 12:31:42 -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 057261200C5; Sat, 7 Apr 2018 12:31:41 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1464620FC7; Sat, 7 Apr 2018 15:31:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 07 Apr 2018 15:31:38 -0400 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rrb0gc /xHv9kKIemljlzf1ngOMivhsJvc+hAUvC0QIw=; b=dN0rqybYj8Pqz2uXy3decl m4fFOfbtbGKG1G2Xz40l1vGjwQvLHT9tfnbVc/102YN5OZdj1oD6tXKB+/2BpcwG fx+4KhoGt6h7AxrRzLji4bz73Nt9d5BrcmXLojMbAdJ9YxXGhyhHFghnpDtWttJE PXT2k9CliwWXCkrRBY1AOGjKoQtzPEl3jl7rXUlAnlQIBmyBpt7paLq0YorZSHR3 BFzRUALH03DK/nCH0Vnd3PKGO3ikJWsU8hqAvusb7vnkgG75FbKPD75cGE9T/Wd3 khh0Jyep1hasD2qL0zTLVFLBZguzlBqbeSflipQ3qq62crT1T04lDWCHJBXl5Lyg == X-ME-Sender: Received: from [192.168.1.176] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F4701025D; Sat, 7 Apr 2018 15:31:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (15D100) In-Reply-To: <5AC802E0.2000200@redbarn.org> Date: Sat, 7 Apr 2018 20:31:33 +0100 Cc: Martin Thomson , dnsop , DoH WG , Ted Lemon , Patrick McManus , Ray Bellis Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AC802E0.2000200@redbarn.org> To: Paul Vixie Archived-At: Subject: Re: [Doh] media type name, was Re: re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:31:44 -0000 > On 7 Apr 2018, at 00:29, Paul Vixie wrote: >=20 > i object, as before, to "dns-udpwireformat" as a name. these are dns messa= ges, which when carried by udp are raw, and when carried in tcp are preceded= by a two-octet length indicator for framing of multiple messages sharing th= e same stream. so, the string to be registered should be "dns-message". Yes! Much nicer and more accurate. Tony. --=20 f.anthony.n.finch http://dotat.at= From nobody Sat Apr 7 20:15:51 2018 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 C05121242F7; Sat, 7 Apr 2018 20:15:44 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fxn2U466NsOV; Sat, 7 Apr 2018 20:15:42 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 AF26E1200A0; Sat, 7 Apr 2018 20:15:42 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id v4so3009208uaj.3; Sat, 07 Apr 2018 20:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9GSgF+livP09CKz+Ajr3+WEIXEcYh92ymjZ/YR6YbKQ=; b=dLSVUvbdgYIfFBzphy/M080ZWeS5fxIfgF6JYBb68F+MOI3qXG7G5jXfd0kp6lyZEC tR0duhOFh/DwTFX960dyidYRQz6GYZT48wgNekUo0LF7isHorXmtCnoyOgHKKR9m6tWP LNXAkUjUcpoFvH+uXSkJkqwICul4vbY/2ckRs2sxSPJt3dA/WF6fxV9OKQdP/r5yn3nk E86SecarBnjmUBIl/RYkCcMad5+ohfbnP7bJThj4fsdfDh6XWK0WZxZNPA40eQydOmJG QtomG6qCkR38uuBabnpBdAphtqjwRZcKW7xfFigAJsrUjV4Ow/4hHeKOKELiGDzKBYzy 1G8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9GSgF+livP09CKz+Ajr3+WEIXEcYh92ymjZ/YR6YbKQ=; b=eetQl88fy6KwPCaTRT8aL2Rf2aq/heNPScYPwfs/CdY2pV4mJjx6FqjpkbtC/rXqvp NpqHYZh50h/vY7iD9itLrAuxrvDV69NOf+FFcBx3U7qWa6DTQ8VbVPj6HTtuTIZ8RTtI EDoVG77qRbnzdGU3AHZB2/z5tLfp7xFSIAWk1M06Zyzdoe1hAciLY+jrrMx+0nCo9EgX o5Unu61fsRQDREA+Di/VFzzvhJySqFyX7mhd99UbLlqvwF33tA1x/OaavGb2TGmoOZZm 2+KnvGm3tOmqv9ImPOUXPmeDQRNOjOlr4Nc4eBORrhfXm7sgaDz/a6H3DlecPXcZWjMX nfJQ== X-Gm-Message-State: ALQs6tCUug86cQUw8Kv/Yqkii7y5YHH0iWIH6g58Cpx4p0s8GXEq22TV z1QJehR7zfIiUJZi1CpXnoqWC4eulLa1oN0ibEU= X-Google-Smtp-Source: AIpwx4/0tB5dCmynP/Hp9nR1oUK/S5QzSZ+r8KqG14QGydNFo8Y9D/Sl8LWDZPan0NzQNkpzL0s2lHCXYVer3fY8I+o= X-Received: by 10.176.69.182 with SMTP id u51mr20896389uau.93.1523157341466; Sat, 07 Apr 2018 20:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.90.104 with HTTP; Sat, 7 Apr 2018 20:15:40 -0700 (PDT) In-Reply-To: <5AC802E0.2000200@redbarn.org> References: <5AC802E0.2000200@redbarn.org> From: Davey Song Date: Sun, 8 Apr 2018 11:15:40 +0800 Message-ID: To: Paul Vixie Cc: Martin Thomson , dnsop , DoH WG , Ted Lemon , Patrick McManus , Ray Bellis Content-Type: multipart/alternative; boundary="94eb2c11b82446791805694db414" Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 03:15:45 -0000 --94eb2c11b82446791805694db414 Content-Type: text/plain; charset="UTF-8" On 7 April 2018 at 07:29, Paul Vixie wrote: > > > i am generally supportive of this approach; in fact i wish i'd thought of > it. the specifics will be different, as in: > > /proxy_dns?proto=tcp > /proxy_dns?proto=udp > > but i agree that encoding the original transport in the URI is better than > either extending the content-type or adding another http header. > It sounds a better approch. We can define the variables "proto" in dnsop-dns-wireformat-http instead of adding a parameter of content-type. There is a sentence in DOH draft support new variables in URI. Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. I think it should edited a little bit : s/ new media/ new media types and new use cases i object, as before, to "dns-udpwireformat" as a name. these are dns > messages, which when carried by udp are raw, and when carried in tcp are > preceded by a two-octet length indicator for framing of multiple messages > sharing the same stream. so, the string to be registered should be > "dns-message". > > +1 Davey > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --94eb2c11b82446791805694db414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 7 April 2018 at 07:29, Paul Vixie <paul@redbarn.org> w= rote:

 i am generally supportive of this approach; in fact i wish i'd thought = of it. the specifics will be different, as in:

/proxy_dns?proto=3Dtcp
/proxy_dns?proto=3Dudp

but i agree that encoding the original transport in the URI is better than = either extending the content-type or adding another http header.
=C2=A0
It sounds a better approch.=C2=A0=C2=A0We = can define the variables "proto"=C2=A0in=C2=A0dnsop-dns-wireforma= t-http instead of adding a parameter of content-type.

<= div>There is a sentence in DOH draft support new variables in URI.=C2=A0

=C2=A0 =C2=A0Future specifications for new media typ= es MUST define the variables
=C2=A0 =C2=A0used for URI Template p= rocessing with this protocol.

I think it should ed= ited a little bit : s/ new media/ new media types and new use cases

i object, as before, to "dns-udpwireformat" as a name. these are = dns messages, which when carried by udp are raw, and when carried in tcp ar= e preceded by a two-octet length indicator for framing of multiple messages= sharing the same stream. so, the string to be registered should be "d= ns-message".
<= /font>

=

+1

Davey=C2= =A0

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

--94eb2c11b82446791805694db414-- From nobody Sun Apr 8 11:12:08 2018 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 F410412D77B; Sun, 8 Apr 2018 11:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zIuvps-_0vp8; Sun, 8 Apr 2018 11:12:05 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994C8129C59; Sun, 8 Apr 2018 11:12:05 -0700 (PDT) Received: from [192.168.0.198] (unknown [85.191.103.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 50C257594C; Sun, 8 Apr 2018 18:12:03 +0000 (UTC) Message-ID: <5ACA5B69.2020602@redbarn.org> Date: Sun, 08 Apr 2018 14:11:53 -0400 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Davey Song CC: Martin Thomson , dnsop , DoH WG , Ted Lemon , Patrick McManus , Ray Bellis References: <5AC802E0.2000200@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] re original_transport indicator X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 18:12:07 -0000 sean gallagher did an excellent writeup on all this in arstechnica today: https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns/ he didn't mention the bii/tisf proxy method from three years ago, but since our draft has languished somewhat, i can hardly blame him. vixie From nobody Mon Apr 9 09:08:48 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE9126CD8; Mon, 9 Apr 2018 09:08:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152329012604.30804.10999413911543482261@ietfa.amsl.com> Date: Mon, 09 Apr 2018 09:08:46 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 16:08:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-06.txt Pages : 17 Date : 2018-04-09 Abstract: This document describes how to run DNS service over HTTP (DOH) using https:// URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-06 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 9 09:12:29 2018 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 C528112D77A for ; Mon, 9 Apr 2018 09:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.18 X-Spam-Level: ** X-Spam-Status: No, score=2.18 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MISSING_HEADERS=1.207, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1koI_RbKPznO for ; Mon, 9 Apr 2018 09:12:26 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id D335C126CD8 for ; Mon, 9 Apr 2018 09:12:25 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0C99F3A019 for ; Mon, 9 Apr 2018 12:12:23 -0400 (EDT) Received: by mail-oi0-f43.google.com with SMTP id u141-v6so8161329oif.1 for ; Mon, 09 Apr 2018 09:12:23 -0700 (PDT) X-Gm-Message-State: ALQs6tB2xtjDuTTqqLS28Hnx4nGRBdqMvXMpg+Ybzae3jtxyOfzS6yFO YwK4X7z9KcovZJTwnsiKl0MiErTsVGMDd88nY4c= X-Google-Smtp-Source: AIpwx4/rn78Ehoupl0loclCm6hkUO0weQttqNrvzlUUHTLXTKa8mwkPQiAJL1m6w0Insm71B7DjO2fm5kMDXLUVVq8Q= X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr20585112oib.132.1523290342779; Mon, 09 Apr 2018 09:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.23 with HTTP; Mon, 9 Apr 2018 09:12:22 -0700 (PDT) In-Reply-To: <152329012604.30804.10999413911543482261@ietfa.amsl.com> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> From: Patrick McManus Date: Mon, 9 Apr 2018 12:12:22 -0400 X-Gmail-Original-Message-ID: Message-ID: Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000c5740605696cabf3" Archived-At: Subject: Re: [Doh] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 16:12:28 -0000 --000000000000c5740605696cabf3 Content-Type: text/plain; charset="UTF-8" Hi All, Thank you to all for getting this into good shape. Some changes to be aware of based on input: * media type has changed to message/dns * the optional media type parameter has been removed * some text, particular wrt caching and the media type, has been internally moved.. resulting in the caching text being consolidated into one place and the http information being closer together as well. The substance is not changed (other than as noted above) On Mon, Apr 9, 2018 at 12:08 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS Over HTTPS WG of the IETF. > > Title : DNS Queries over HTTPS > Authors : Paul Hoffman > Patrick McManus > Filename : draft-ietf-doh-dns-over-https-06.txt > Pages : 17 > Date : 2018-04-09 > > Abstract: > This document describes how to run DNS service over HTTP (DOH) using > https:// URIs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-06 > https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000c5740605696cabf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Thank you to all for= getting this into good shape. Some changes to be aware of based on input:<= /div>

* media type has changed to message/dns
= * the optional media type parameter has been removed
* some text,= particular wrt caching and the media type, has been internally moved.. res= ulting in the caching text being consolidated into one place and the http i= nformation being closer together as well. The substance is not changed (oth= er than as noted above)




On Mon, = Apr 9, 2018 at 12:08 PM, <internet-drafts@ietf.org> = wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DNS Over HTTPS WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= DNS Queries over HTTPS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Hoffman
=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 Patrick McManus
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-doh-dns-over-https-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-04-09

Abstract:
=C2=A0 =C2=A0This document describes how to run DNS service over HTTP (DOH)= using
=C2=A0 =C2=A0https:// URIs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-doh-dns-over-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-doh-dns-over-https-06
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-doh-dns-over-https-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-doh-dns-over-https-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--000000000000c5740605696cabf3-- From nobody Mon Apr 9 11:44:04 2018 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 B10191273B1 for ; Mon, 9 Apr 2018 11:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] 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 Q2KqgvtiIgVg for ; Mon, 9 Apr 2018 11:44:01 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 01DEB129C6E for ; Mon, 9 Apr 2018 11:44:01 -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]:43075) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f5bln-0004ts-LX (Exim 4.89_2) (return-path ); Mon, 09 Apr 2018 19:43:59 +0100 Date: Mon, 9 Apr 2018 19:43:59 +0100 From: Tony Finch To: Patrick McManus cc: DoH WG In-Reply-To: Message-ID: References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 18:44:03 -0000 Patrick McManus wrote: > > * media type has changed to message/dns This is a really nice-looking media type but I don't think DNS fits in the remit of the message top-level type: RFC 6838 page 11 suggests message subtypes have to be MIME objects. (RFC 2046 says roughly the same thing but less clearly.) Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin: Southeast backing northeast 5 or 6, occasionally 7 in Malin. Rough or very rough, becoming high for a time at first in southwest Rockall. Showers then fair. Good, occasionally poor. From nobody Mon Apr 9 14:39:35 2018 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 450C612D965 for ; Mon, 9 Apr 2018 14:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 O3PBUluQZBEg for ; Mon, 9 Apr 2018 14:39:32 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 095EC12D95B for ; Mon, 9 Apr 2018 14:39:32 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 9 Apr 2018 14:39:30 -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.1178.000; Mon, 9 Apr 2018 14:39:30 -0700 From: Paul Hoffman To: DoH WG CC: Martin Thomson Thread-Topic: [Ext] [Doh] I-D Action: draft-ietf-doh-dns-over-https-06.txt Thread-Index: AQHT0Es9RbqXSI7ca0WL734QIUP2nw== Date: Mon, 9 Apr 2018 21:39:30 +0000 Message-ID: <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> In-Reply-To: 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.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 21:39:34 -0000 On Apr 9, 2018, at 2:43 PM, Tony Finch wrote: >=20 > Patrick McManus wrote: >>=20 >> * media type has changed to message/dns >=20 > This is a really nice-looking media type but I don't think DNS fits in th= e > remit of the message top-level type: RFC 6838 page 11 suggests message > subtypes have to be MIME objects. (RFC 2046 says roughly the same thing > but less clearly.) Agree. Martin: want to pick another? --Paul Hoffman From nobody Mon Apr 9 15:56:09 2018 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 6388A12D86E for ; Mon, 9 Apr 2018 15:56:08 -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, FREEMAIL_FROM=0.001, 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=gmail.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 VU7fqrukiUG1 for ; Mon, 9 Apr 2018 15:56:06 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 840F11243F6 for ; Mon, 9 Apr 2018 15:56:06 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id z8-v6so9319836oix.2 for ; Mon, 09 Apr 2018 15:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P50vA5K+HIxkJDVoLM5j5+6JZxyU+dNSqYYNtIHRFDQ=; b=nfZ6WNz65+fUixk7r9ofJvp3IvwohQUq3kQHuKUznujBKCiXPCPymI1X6DmcHWpN5u GT76JZvV7T8vrGE1VB/tMrX1R3W6hJnNJQcPc68wlqEMLBWdbwdHZsoj2G2AAAaRQNC9 ztolXiKcUyCQ0ulXx3luB4/DlU8ZZofTQv6wfhgVmeJ892BddhrVf4ts0AiSlYhGWgfo aYKWHcIES/RNorWyGb5ksEirzVO/fRwsOw3jB3asU8l70gbVqlAxn2HNRy2R4paXe+sV 1ulG56YyJzjnXa2chI6GY92BJ03/yJ1I5Ja+Oj6C9fvorKnV85OcOR2yCcCbQSTD5KMc vu4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P50vA5K+HIxkJDVoLM5j5+6JZxyU+dNSqYYNtIHRFDQ=; b=k5wgY6sheUevS505puKtS8IR1XhuB1YTjESfk+L92uB25G6scJBJnmKwJKQ/1WRNe5 8KOE0QbxWFPpWOppDNFxsC418WWySn3c+uG2ciCfyxVOyNjU/aoZyHNyz8jb4y0urZZA /kP4RTbPwv5Dm6YWNZR8kuQ325WpQG2CLdDd6a9AmtzpVO8jPZyoN5E4xpDDRucsp7PN 7L7u/UzI6CdLcw3XHLmaACTAqjs9TZ1xPpZTduWwP0mPE7JQ1QLq4gezO7cN+FBRGF4P Na7rZa2ZYtejpZP+eMKx4BEDCoX8oKhDtJPUTcUHTi0tIk9Gn9yTmWCH48+6UPWENH+q g0iw== X-Gm-Message-State: ALQs6tAUjSmdrW+I2nMxKwn5sS1vYvIVdV0gNokQ3TrY+t1JfTGyyRQZ R0rssUBvd5kxIumpbH8qXThi7A3M7JSgLaNRwW4= X-Google-Smtp-Source: AIpwx49Uebv4UgbP3v1BNsGHV2+Y7yXc9hthbpPc7K3cYLfM+ujV0TLVzDTz/AiMmjs8IKIs1fh3TpVyc8jFoTweAlo= X-Received: by 2002:aca:ab44:: with SMTP id u65-v6mr589608oie.272.1523314565577; Mon, 09 Apr 2018 15:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 15:56:05 -0700 (PDT) In-Reply-To: <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> From: Martin Thomson Date: Tue, 10 Apr 2018 08:56:05 +1000 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:56:08 -0000 On Tue, Apr 10, 2018 at 7:39 AM, Paul Hoffman wrote: > On Apr 9, 2018, at 2:43 PM, Tony Finch wrote: >> >> Patrick McManus wrote: >>> >>> * media type has changed to message/dns >> >> This is a really nice-looking media type but I don't think DNS fits in the >> remit of the message top-level type: RFC 6838 page 11 suggests message >> subtypes have to be MIME objects. (RFC 2046 says roughly the same thing >> but less clearly.) > > Agree. > > Martin: want to pick another? Ugh: Tony is right. message/ is defined as being MIME only. That's short-sighted and selfish. Top-level types should have broad applicability and that assumes that there is only MIME. I would say that application/dns is perfectly sufficient. But I am just one person. From nobody Mon Apr 9 16:09:40 2018 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 342E012D87A for ; Mon, 9 Apr 2018 16:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 jmP-UU1f7ma0 for ; Mon, 9 Apr 2018 16:09:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 94EC212D86F for ; Mon, 9 Apr 2018 16:09:37 -0700 (PDT) Received: from [172.18.0.15] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w39N9Doo075071 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Apr 2018 18:09:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.18.0.15] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 9 Apr 2018 18:09:08 -0500 Cc: Paul Hoffman , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <650A2F87-DCD0-4802-8278-2716C9F00E98@nostrum.com> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> To: Martin Thomson Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 23:09:39 -0000 That=E2=80=99s taken. Perhaps =E2=80=9Capplication/dns-message=E2=80=9D woul= d work? /a > On Apr 9, 2018, at 17:56, Martin Thomson wrote:= >=20 >> On Tue, Apr 10, 2018 at 7:39 AM, Paul Hoffman wr= ote: >>> On Apr 9, 2018, at 2:43 PM, Tony Finch wrote: >>>=20 >>> Patrick McManus wrote: >>>>=20 >>>> * media type has changed to message/dns >>>=20 >>> This is a really nice-looking media type but I don't think DNS fits in t= he >>> remit of the message top-level type: RFC 6838 page 11 suggests message >>> subtypes have to be MIME objects. (RFC 2046 says roughly the same thing >>> but less clearly.) >>=20 >> Agree. >>=20 >> Martin: want to pick another? >=20 > Ugh: Tony is right. message/ is defined as being MIME only. That's > short-sighted and selfish. Top-level types should have broad > applicability and that assumes that there is only MIME. >=20 > I would say that application/dns is perfectly sufficient. But I am > just one person. >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Mon Apr 9 17:59:59 2018 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 CC79E120227 for ; Mon, 9 Apr 2018 17:59:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 hSvb2gdUm13u for ; Mon, 9 Apr 2018 17:59:56 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 33CC91201F8 for ; Mon, 9 Apr 2018 17:59:56 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id y46-v6so10856154otd.4 for ; Mon, 09 Apr 2018 17:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YfyE4hnNjOynMoswTsdWanIiTOwgonypNTovPlBlGZs=; b=bIXCAh9wQf5OSSbW1QF0EoGNmsVS776ZY+LpBuPDuZQOTngI6iGZ20xbVMNgUETGf5 BM9tx2yffIKtQlZzjS7JtWshc8oVbYabyjQQ/lg/OaBsXWV8LgLpFqFbfIy9eKiyLPv2 EOtm8BDFrGCz5C9+O8Au/TPLNYYua0RmdUAPTn9Ni8Ge1MTkYsLO/DRQBu+fGOlP5Ds6 x1LCea49FId7gmpSL1OYCEdekfaO5zVRpw3sXcIBNbCApzcVykY8G/7zScVsSbjYoQU2 RBcdbSoSgSeyhpXRV33mGeDcf9WRkwCQKrcaLwhZfKbAvl1UdvliaCCt0JWaaKvo/fMq 5XtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YfyE4hnNjOynMoswTsdWanIiTOwgonypNTovPlBlGZs=; b=r+eu9r20wTJhwpAR3kRGmU6ySp9iye3o5CC/kChzlQne+IJU2wOeGLeGy9/U/TG/Pl j1BG1X6yYc0BFv0MfCtdF96iDdhag7ypwKz3r1/Yz/9J1Mh0cW293v5uKb6SMu0wZ/Jk TNtih5Px1u1sEQV7ycte5jiCjs+992vMfIoyRJ8Xy7JWccOUMi/EB8D25mCzH9v9VCMX RoQQdvGoqmDF6NWTYM2jkDH90rmAd1OUoE2H3panipcc/4XIGVKBWzh6RQFoPCED9ym7 F/NuHpMOXfoq1ZlknHkTyG6S9m21x5nrjfh24Uy0dX21cmVAXhLSAVjxevZDlV4/+0ad MJVA== X-Gm-Message-State: ALQs6tAetU0egAafaTbePQ6TbID0MPR6fMPBcmzOPQzJ9IepLiWAGgae Q+gUuKPHV+1sOtLYJ6bboiOl15w9aN+g5NrmMso0Sg== X-Google-Smtp-Source: AIpwx4+lfW1PRiv+WBEAYcZ0stiNDO0Wuhx2/B1mgkZxZqvyYHhVriekSKo4Abf50EmN1lKYol7obAW9KrSmqB/cbj8= X-Received: by 2002:a9d:6001:: with SMTP id h1-v6mr14932573otj.283.1523321995443; Mon, 09 Apr 2018 17:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 17:59:55 -0700 (PDT) In-Reply-To: <650A2F87-DCD0-4802-8278-2716C9F00E98@nostrum.com> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> <650A2F87-DCD0-4802-8278-2716C9F00E98@nostrum.com> From: Martin Thomson Date: Tue, 10 Apr 2018 10:59:55 +1000 Message-ID: To: Adam Roach Cc: Paul Hoffman , DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 00:59:58 -0000 On Tue, Apr 10, 2018 at 9:09 AM, Adam Roach wrote: > That=E2=80=99s taken. Perhaps =E2=80=9Capplication/dns-message=E2=80=9D w= ould work? I should have checked. dns-message is where we ended up before, and so aga= in. From nobody Wed Apr 11 11:23:01 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D23126C89; Wed, 11 Apr 2018 11:23:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152347098031.2259.8716567224029483211@ietfa.amsl.com> Date: Wed, 11 Apr 2018 11:23:00 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-07.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:23:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-07.txt Pages : 17 Date : 2018-04-11 Abstract: This document describes how to run DNS service over HTTP (DOH) using https:// URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 14 09:37:14 2018 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 AFF1D126CC7 for ; Sat, 14 Apr 2018 09:37:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pw5pEW9YgEl7 for ; Sat, 14 Apr 2018 09:37:10 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 9CEE41241F5 for ; Sat, 14 Apr 2018 09:37:09 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 4995 invoked from network); 14 Apr 2018 18:37:06 +0200 Received: from agsm209.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.209]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 14 Apr 2018 18:37:06 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org Message-ID: Date: Sat, 14 Apr 2018 18:36:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pHAqOQ5kFFj8jLRjzraRjyPklXo0hOiN6" X-WP-MailID: d0fc87a98c4c0189a7cd73ecfcc422be X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [EaNE] Archived-At: Subject: [Doh] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 16:37:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pHAqOQ5kFFj8jLRjzraRjyPklXo0hOiN6 Content-Type: multipart/mixed; boundary="z1Opxz9mdFbKpclYooduMyMKVAlMRuGkd"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: doh@ietf.org Message-ID: Subject: Fallback to untrusted DOH servers --z1Opxz9mdFbKpclYooduMyMKVAlMRuGkd Content-Type: multipart/mixed; boundary="------------6758852D7F19807E82D31867" Content-Language: pl This is a multi-part message in MIME format. --------------6758852D7F19807E82D31867 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Current DOH draft specifies that: A client MUST NOT trust a DNS API server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party. Instead, a client MUST only trust DNS API server that is configured as trustworthy. It may happen that either no trustworthy DOH server has been configured, = or the configured DOH server is not working. In such cases a DOH client would us= ually revert to using an untrusted DNS server on port 53, possibly one that was= discovered through unsecure DHCP. This DNS resolver would also be able to= poison DNS caches then. I think that in this case it would be better to use whatever DOH server i= s available as an alternative to an even worse old-school DNS. To avoid cac= he poisoning attacks, the client would then have to drop DNS caches after sw= itching to a more trustworthy DNS once it has been configured or is available. Also, the current draft does not specify any way of querying IP addresses= of hosts on the local network - it is assumed that if a DNS API server would= return NXDOMAIN the client would query the local old-school DNS server whether t= he hostname translates to an IP address on a local network. In the future, t= here may be specified a discovery mechanism for a local fallback DOH server, f= or example by a DHCP option. A client would have to drop DNS caches when switching networks anyway to = avoid any stale entries related to local hosts. Therefore, I would propose the following text: A client SHOULD NOT trust a DNS API server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party. Instead, a client SHOULD only trust a DNS API server= that is configured as trustworthy. A client MAY use an untrustworthy DNS API server as a fallback, for example: when no trustworthy DNS API= server is configured, no configured DNS server works or when the trustworthy DNS API server returned NXDOMAIN (and checking wh= ether the hostname is a local domain). The client MUST drop DNS caches when switching from an untrustworthy DNS API server to a trustworthy one. It should be also noted that the client should drop DNS caches when switc= hing from an unsecure DNS to DOH. "A client SHOULD drop DNS caches when switching from less secure DNS retrieval mechanisms to DOH." Greetings, Mateusz Jo=C5=84czyk --------------6758852D7F19807E82D31867 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------6758852D7F19807E82D31867-- --z1Opxz9mdFbKpclYooduMyMKVAlMRuGkd-- --pHAqOQ5kFFj8jLRjzraRjyPklXo0hOiN6 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa0i4wAAoJEPvWWrhhCv7GPMgP/0Hs62DzGFMg4i+x73Ng3W5a n0KvcYBpjG1E/zug3A6H9MrMdC1//TSJfz+OaOR2dk/8JYJJe1GFbWakqBqRTS1W 3ba/a8DsbbTmtocXZHlSCbbyp/INZA/6Jks7dw1pi8eMzpy+Yw5Z9q9etTme78kZ 7ByJHKJaziy6/i5OAK1ww7S5osKI/r6p6Sdy0qnD0tq10N8FIAc40lDgczgdsFul /YPO5Uzt3iC3wPpEnFc+K9swpPrstqkyaGWmUrLVyCIaHKD2XTx4G5p5Su8S2EuY SMoN25oSD3H38WIte1dTcKCy7jOr+Vp1BK769eCp3RXHRbAk33wgBMRg2sSfmTEt FYzcyOH5HdHtj12HV1W8qZ5z+3JYku5/dhIy4HyfSEGRHjXr6LAu6tDSJxzWH1N0 QBfN+8CgU9Riu+2+wPT902oTbhzvpM8MXWu/hGIrHb53ge/GyBD3sKqiOU6OSLT9 uaCSWxUdwo37J2+xvPhUuvGAd7JdEkdqT9Q7WvLbTVDyXCmy7+Kuin4W7609ersc YntKTkK75HP6B74UOEm+1H8hiXDwH8E9CuslCNWig2AGHKpBfb3C5fOcF9V4mRMU ezsCgQIB0fJr+TuP6kfwPM6jFPUpQ2TC9Ere83SYbqcZ0EEvfwJyknPFZgnP05LD VD8lIjdMWfCZTHeYxmMS =OTdr -----END PGP SIGNATURE----- --pHAqOQ5kFFj8jLRjzraRjyPklXo0hOiN6-- From nobody Sat Apr 14 10:34:39 2018 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 B6CFF120725 for ; Sat, 14 Apr 2018 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 2rBPTsLuFmNB for ; Sat, 14 Apr 2018 10:34:36 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 395B91201FA for ; Sat, 14 Apr 2018 10:34:36 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id p6so8503905pfn.4 for ; Sat, 14 Apr 2018 10:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nQMsNYI1eKP5WE4N6l9DyC727vO8UAinmZXhk55tO4U=; b=hlsMHEPCKS9uIhhhcrx9mQIiTPvZLKG0lZAscCJ6ZxlO56UVo3QFVOg8YvRMw71Smp niq9m/xxqcEXBTFj4DlEs03i9oTnP0P9ReHxSmzasL3HkA8hGpA5FaWwb1Y6MpmF7hVh YzPBGqsA2wcqcGh9+iEaTzghCnuhdlYoNe/3zNuozTvht4mn3NWHvXOMhA9fBDcxevOQ iqY2SHeBoxa+URSAFM4CGWAcJuZ/fRfgjckond4ftW6xFfWLuiYdrKoekcmt6+z29Va1 lx10/y3oU4kTw086G83pbM2kJQlZbpdIlMag52yUvLji5d2Qx0IJ/JyovHU6WegdyIbZ mnsg== 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=nQMsNYI1eKP5WE4N6l9DyC727vO8UAinmZXhk55tO4U=; b=E5wf6H9KS/0jz+wlUSTwe8ZNDtXhWDm7FTmREwzLpPyubcCwi15TzpzZUjcXzrcmaP oxugJuiOycZCfbAYDCFtUj9dOdpqtrFyNoAmSaaEollRJCxG3OVO6tn9nmenyLOdOmUl N///cQH9IEneOAPIGE+0VooTU9r9N/PEXCFM0yzTcCbc5nyLhwCdOfG4FrxMjfQuqZyK 3v3vs9DmMfsyzeThzeUXeofd+YmRT+qO8exCKs4D4FlLw+db1gZCAE6URMwml+/4md0M KvqTJ3fnFMYvrdOpk//WRm8oUX7kc4ph6FrQnyUgYFj6Y+4julT2OOnHTzxtsktH2KIb snvQ== X-Gm-Message-State: ALQs6tAESZz3s6yqd8qEfRTQOnN7eBSgX2v2MP0qGqPbUVlqDJVvq/qA E3WP2aR2KK3QsJQYuEMipzCq98petGo= X-Google-Smtp-Source: AIpwx4+tacrXINpVpAncMc++8E1ZxlcWwhCmvyt6lNABS44CRlGi9jCfX38DPsuxMvmBkAdBunctxg== X-Received: by 10.98.196.83 with SMTP id y80mr15833679pff.117.1523727275639; Sat, 14 Apr 2018 10:34:35 -0700 (PDT) Received: from cavall.lan ([162.255.121.238]) by smtp.gmail.com with ESMTPSA id v23sm15378790pfn.65.2018.04.14.10.34.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Apr 2018 10:34:34 -0700 (PDT) From: Ted Lemon Message-Id: <0471D49C-3047-4161-8EC3-A31D41573841@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A409664-C992-4DCA-B6A7-7B2F741BD51C" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sat, 14 Apr 2018 10:34:31 -0700 In-Reply-To: Cc: doh@ietf.org To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 17:34:39 -0000 --Apple-Mail=_2A409664-C992-4DCA-B6A7-7B2F741BD51C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk = wrote: > It may happen that either no trustworthy DOH server has been = configured, or the > configured DOH server is not working. In such cases a DOH client would = usually > revert to using an untrusted DNS server on port 53, possibly one that = was > discovered through unsecure DHCP. This DNS resolver would also be able = to poison > DNS caches then. >=20 > I think that in this case it would be better to use whatever DOH = server is > available as an alternative to an even worse old-school DNS. To avoid = cache > poisoning attacks, the client would then have to drop DNS caches after = switching > to a more trustworthy DNS once it has been configured or is available. What threat model do you want to address? Two things spring to mind as = things you might care about: "do I trust the DNS server" "is the connection to the DNS server private?" If the resolver was configured with keying information that can be = validated as part of making the connection to the server, then you trust = the server. What exactly that means is a question in itself, but let's = take that for granted for now. In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have = (1), so it doesn't matter which one you use, except that if you use some = method other than DHCP to get to the DOH server, potentially what you = have reached is even _less_ trustworthy than the DNS server. So you = could as easily be worse off as better off. What you do get with DOH-I-don't-know as compared to DNS-I-don't-know is = (2), for some value of "private." So what threats does preferring DOH protect you from? What threats = _doesn't_ it protect you from? What vulnerabilities does it create? = I think you need to answer all three of these questions if you're going = to make the case that untrusted DOH should be preferred over untrusted = DNS. Your question about the local resolver is interesting. I think what it = points to, though, is that what DOH does is to solve a very different = problem than the problem you are trying to solve with it. If you want to solve the problem you are proposing to solve, the place = it needs to be solved is in the local stub resolver implementation. = This is something we've seen before, and there's even an RFC that talks = about it, RFC7556. =46rom the perspective of RFC7556, your "trusted" = DOH resolver represents a provisioning domain, and it's the domain in = which you would prefer to look up names. Your local DNS resolver = represents another provisioning domain. =20 Provisioning domain DNS caches must be separate, to avoid cache = poisoning. You might have a whitelist of domains that can be looked up = using the local resolver, and all other domains are just not available = if the trusted DOH server isn't present. Or you could have a blacklist = of domains that are only sent to the trusted DOH server, and other = domains can go either way. Or some other security policy.= --Apple-Mail=_2A409664-C992-4DCA-B6A7-7B2F741BD51C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> = wrote:
It may happen = that either no trustworthy DOH server has been configured, or = the
configured = DOH server is not working. In such cases a DOH client would = usually
revert to = using an untrusted DNS server on port 53, possibly one that = was
discovered = through unsecure DHCP. This DNS resolver would also be able to = poison
DNS caches = then.

I think that = in this case it would be better to use whatever DOH server is
available as = an alternative to an even worse old-school DNS. To avoid cache
poisoning = attacks, the client would then have to drop DNS caches after = switching
to a more = trustworthy DNS once it has been configured or is = available.

What threat model do you want to address?   Two things = spring to mind as things you might care about:
  1. "do I trust the DNS server"
  2. "is the connection to the DNS server private?"

If the resolver = was configured with keying information that can be validated as part of = making the connection to the server, then you trust the server.   = What exactly that means is a question in itself, but let's take that for = granted for now.

In the case of DOH-I-don't-know versus DNS-I-don't-know, you = don't have (1), so it doesn't matter which one you use, except that if = you use some method other than DHCP to get to the DOH server, = potentially what you have reached is even _less_ trustworthy than the = DNS server.   So you could as easily be worse off as better = off.

What you = do get with DOH-I-don't-know as compared to DNS-I-don't-know is (2), for = some value of "private."

So what threats does preferring DOH protect you from?   = What threats _doesn't_ it protect you from?   What vulnerabilities = does it create?   I think you need to answer all three of these = questions if you're going to make the case that untrusted DOH should be = preferred over untrusted DNS.

Your question about the local resolver = is interesting.   I think what it points to, though, is that what = DOH does is to solve a very different problem than the problem you are = trying to solve with it.

If you want to solve the problem you are proposing to solve, = the place it needs to be solved is in the local stub resolver = implementation.   This is something we've seen before, and there's = even an RFC that talks about it, RFC7556.   =46rom the perspective = of RFC7556, your "trusted" DOH resolver represents a provisioning = domain, and it's the domain in which you would prefer to look up names. =   Your local DNS resolver represents another provisioning domain. =   

Provisioning domain DNS caches must be separate, to avoid = cache poisoning.   You might have a whitelist of domains that can = be looked up using the local resolver, and all other domains are just = not available if the trusted DOH server isn't present.   Or you = could have a blacklist of domains that are only sent to the trusted DOH = server, and other domains can go either way.   Or some other = security policy.
= --Apple-Mail=_2A409664-C992-4DCA-B6A7-7B2F741BD51C-- From nobody Sat Apr 14 13:54:46 2018 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 14F5812702E for ; Sat, 14 Apr 2018 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8cedLw0S5NRe for ; Sat, 14 Apr 2018 13:54:43 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 886CE1250B8 for ; Sat, 14 Apr 2018 13:54:43 -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.1178.4; Sat, 14 Apr 2018 13:54:41 -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.1178.000; Sat, 14 Apr 2018 13:54:41 -0700 From: Paul Hoffman To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] Fallback to untrusted DOH servers Thread-Index: AQHT1A7a/lQnvejv10e8iPgmrDz+j6QBMtUA Date: Sat, 14 Apr 2018 20:54:39 +0000 Message-ID: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_A9DB326A-F6F3-4859-B7A3-E15DEC7D896A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 20:54:45 -0000 --Apple-Mail=_A9DB326A-F6F3-4859-B7A3-E15DEC7D896A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk = wrote: >=20 > Hello, > Current DOH draft specifies that: >=20 > A client MUST > NOT trust a DNS API server simply because it was discovered, or > because the client was told to trust the DNS API server by an > untrusted party. Instead, a client MUST only trust DNS API server > that is configured as trustworthy. >=20 > It may happen that either no trustworthy DOH server has been = configured, or the > configured DOH server is not working. In such cases a DOH client would = usually > revert to using an untrusted DNS server on port 53, possibly one that = was > discovered through unsecure DHCP. This DNS resolver would also be able = to poison > DNS caches then. The topic of how a user (well, really, an OS or browser) choose a DNS = server to use is a worthy one to look at, but not in this document. If = someone wants to start such a document, it needs to deal with trust in = DHCP, DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH = policy. (There are likely additional topics...) --Paul Hoffman --Apple-Mail=_A9DB326A-F6F3-4859-B7A3-E15DEC7D896A 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----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlrSao8ACgkQsZnCoeEP RXt9JwgApq460fl9eNN5HSE3JiSRyskhLwVQoK5GEwysgopTZwF1HCI3HZruCGQh zc0SYiVjhCBJzbP72LQDYuogHLpDWl6S7D4yEn9r2MOTUZg2GY71T7eCwc5Qbkrj Q9c1h9EfwNeLbbY/c2p2Wfh8iNzSttWzAjyngMAhjyrSzGoJVPw5VruTrchCQbtp QeKsqocM5bHxEMLMTd9CbczWWtxn73wsx5y7Y/6CHvG1ju+esXXcl0y8a6E0werF QPOYYPEhtp1Kph9yP0/RgxyGz54xzN6Nc8dI69PGYV+qCOb1NLDErHdfZK+v21uS QVR8ktFS3B8yHCHGrUUSNDD9IV4Lug== =chP/ -----END PGP SIGNATURE----- --Apple-Mail=_A9DB326A-F6F3-4859-B7A3-E15DEC7D896A-- From nobody Sun Apr 15 10:19:22 2018 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 EF5EF12420B for ; Sun, 15 Apr 2018 10:19:19 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 igJtYQZ73zB1 for ; Sun, 15 Apr 2018 10:19:16 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) (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 5EF801241F5 for ; Sun, 15 Apr 2018 10:19:16 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 29174 invoked from network); 15 Apr 2018 19:19:13 +0200 Received: from agtx104.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.127.104]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 15 Apr 2018 19:19:13 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Ted Lemon , doh@ietf.org References: <0471D49C-3047-4161-8EC3-A31D41573841@fugue.com> Message-ID: <3cce2b3e-c1aa-a142-4106-7da12c46a7f2@o2.pl> Date: Sun, 15 Apr 2018 19:19:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <0471D49C-3047-4161-8EC3-A31D41573841@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpU9AX6sbEg93bSMwvRR7tAbNS56o6N1T" X-WP-MailID: aac10aae8b411ac218ca2ebeade8a22e X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [gSOX] Archived-At: Subject: Re: [Doh] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 17:19:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LpU9AX6sbEg93bSMwvRR7tAbNS56o6N1T Content-Type: multipart/mixed; boundary="kvK3RlvXzd9YKfAWzzh4Vz3rw4z3KsSRM"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Ted Lemon , doh@ietf.org Message-ID: <3cce2b3e-c1aa-a142-4106-7da12c46a7f2@o2.pl> Subject: Re: [Doh] Fallback to untrusted DOH servers References: <0471D49C-3047-4161-8EC3-A31D41573841@fugue.com> In-Reply-To: <0471D49C-3047-4161-8EC3-A31D41573841@fugue.com> --kvK3RlvXzd9YKfAWzzh4Vz3rw4z3KsSRM Content-Type: multipart/mixed; boundary="------------75286C40B6A103CB73AAE19F" Content-Language: pl This is a multi-part message in MIME format. --------------75286C40B6A103CB73AAE19F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 14.04.2018 o=C2=A019:34, Ted Lemon pisze: > On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk wrote: >> It may happen that either no trustworthy DOH server has been configure= d, or the >> configured DOH server is not working. In such cases a DOH client would= usually >> revert to using an untrusted DNS server on port 53, possibly one that = was >> discovered through unsecure DHCP. This DNS resolver would also be able= to poison >> DNS caches then. >> >> I think that in this case it would be better to use whatever DOH serve= r is >> available as an alternative to an even worse old-school DNS. To avoid = cache >> poisoning attacks, the client would then have to drop DNS caches after= switching >> to a more trustworthy DNS once it has been configured or is available.= >=20 > What threat model do you want to address? =C2=A0 Two things spring to m= ind as things > you might care about: >=20 > 1. "do I trust the DNS server" > 2. "is the connection to the DNS server private?" >=20 >=20 > If the resolver was configured with keying information that can be vali= dated as > part of making the connection to the server, then you trust the server.= =C2=A0 What > exactly that means is a question in itself, but let's take that for gra= nted for now. >=20 > In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have= (1), so > it doesn't matter which one you use, except that if you use some method= other > than DHCP to get to the DOH server, potentially what you have reached i= s even > _less_ trustworthy than the DNS server. =C2=A0 So you could as easily b= e worse off as > better off. I have been thinking exactly about discovering DOH servers via DHCP (in t= his or a future RFC). I cannot think about any other sensible method of *discove= ring* a DOH server (as opposed to using a preconfigured one). A DOH server discovered via DHCP can be used for bootstrapping (a way of = getting the address of the trusted DOH resolver). For example, it may be used to = query the IP address of dns.google.com. >=20 > What you do get with DOH-I-don't-know as compared to DNS-I-don't-know i= s (2), > for some value of "private." >=20 Yup. Untrusted DOH protects the content of requests against everyone othe= r then the DOH server operator. > So what threats does preferring DOH protect you from? =C2=A0 What threa= ts _doesn't_ > it protect you from? =C2=A0 What vulnerabilities does it create? =C2=A0= I think you need > to answer all three of these questions if you're going to make the case= that > untrusted DOH should be preferred over untrusted DNS. > So what threats does preferring DOH protect you from? Preferring DOH protects against passive network attacks (packet sniffing = - as opposed to active attacks). The NSA possibly monitors and stores DNS traf= fic. > What threats _doesn't_ it protect you from? Trying to phish the user is the most dangerous thing that I can imagine. = An attacker on the local network can run their own DOH server, try to spoof = the DHCP response, and then redirect the user to a phishing site. But I would argue that an attacker on the local network can mount an ARP spoofing attack and redirect all network traffic through themselves anywa= y and then try to phish the user this way. The untrusted DOH server can block some domains. It can also be used to m= onitor which sites the user visits. All of this is no worse then using untrusted old-school DNS. Here, however, we are talking about a last-resort situation, and some kin= d of fallback is neccessary - to untrusted DOH or untrusted DNS. > What vulnerabilities does it create? I would argue that no new (in comparison to old DNS), if properly impleme= nted (with separate caches). On the other hand, why untrusted DNS should be preferred over untrusted D= OH, as the current draft implicitly specifies? We may end up with the whole Internet using few DOH servers. There are pr= obably few providers that would host publicly-available DOH servers: Cloudflare (1.1.1.1), Google, OpenDNS, IBM (or the folks responsible for 9.9.9.9) an= d possibly Microsoft and Apple (for use with Windows / macOS) [3]. I doubt = that OpenDNS would be happy to have their DOH server configured in application= s as default, and Microsoft and Apple as well (in products other then theirs).= This would be very different from the current situation where most people= are using the DNS server of their own ISP (discovered via DHCP). That change may be great because it increases privacy, but could create s= everal points of failure for the whole Internet [1]. It would be vulnerable to D= oS or some manipulation by the NSA. It is important to have some local fallback= - i.e. DOH or DNS servers hosted by ISPs. > Your question about the local resolver is interesting. =C2=A0 I think w= hat it points > to, though, is that what DOH does is to solve a very different problem = than the > problem you are trying to solve with it. >=20 > If you want to solve the problem you are proposing to solve, the place = it needs > to be solved is in the local stub resolver implementation. =C2=A0 This = is something > we've seen before, and there's even an RFC that talks about it, RFC7556= =2E =C2=A0 From > the perspective of RFC7556, your "trusted" DOH resolver represents a > provisioning domain, and it's the domain in which you would prefer to l= ook up > names. =C2=A0 Your local DNS resolver represents another provisioning d= omain. =C2=A0=C2=A0 >=20 I'm not sure that RFC7556 is exactly concerned with the problem we are ta= lking about. > Provisioning domain DNS caches must be separate, to avoid cache poisoni= ng. =C2=A0=20 Yup, DNS caches would have to be separate. I have been talking about drop= ping caches when switching providers, but having separate caches is much bette= r. > You> might have a whitelist of domains that can be looked up using the = local > resolver, and all other domains are just not available if the trusted D= OH server > isn't present. =C2=A0 Or you could have a blacklist of domains that are= only sent to > the trusted DOH server, and other domains can go either way. =C2=A0 Or = some other > security policy. I have been talking about sensible defaults, not maintaining whitelists /= blacklists [2]. Currently, I suppose that most of the serious DOH resolvers work this way= (or will work this way): if the DOH query returns NXDOMAIN, they check the ad= dress with a local resolver. This way they introduce (almost) no regressions wh= en resolving names. This scheme is (I would argue) secure - when a global domain name is not = used, it does not hurt much if it resolves to something when querying the local= resolver. Thus I would argue that no whitelists / blacklists are necessar= y. The current DOH draft forbids using a local, discovered DOH server for resolution of local names. Greetings, Mateusz Jo=C5=84czyk [1] This would be much worse then the current situation with DNS root ser= vers. [2] The whitelists / blacklists could be simple, though: for example most= Internet domain names end with a well-known country domain name, while mo= st local names do not have dots in the middle or are in the subdomain ".loca= l" or something similar. [3] I'm skipping providers like ClearBrowsing and hobby sites incapable o= f processing much traffic. --------------75286C40B6A103CB73AAE19F Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------75286C40B6A103CB73AAE19F-- --kvK3RlvXzd9YKfAWzzh4Vz3rw4z3KsSRM-- --LpU9AX6sbEg93bSMwvRR7tAbNS56o6N1T 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa04mQAAoJEPvWWrhhCv7G29AP/3551Y9ywBVeHROTIcIxvNS7 1mwabmcQH1CxXIyTTvuEdyL2rKeQpW1FeeKab4rayCxI//WK16+y2AEPzACAp5rv XkwlFNpXp5gWT5nFbZ5rElJ3SvOgQ++SBAWY6sbIl5Hjhrs/Qk6rKRKGIwbFZ5vJ 7JU8vquUa+Q5yh1oCQJebyD55Caxq605TjkQXdInM+TQn7j/l27iaiN/trFGNkZo oQN5MUO9pIpRQNbq9b3yiG86Bba5w7K/KoKWXKxyaqTK2S80DiVMq3tpTu+4eut5 sUSLqqDuaHZ19dgMzxV2N6wwZwE+TrHeFkZoJ7NLyPwFIyz4yjuXkWDBiTTavzVe szBbCiCFpXuOWgo9ckTAh899SoUZxHi9666+hLfVefG8RfDk4gFvvyvWRuDRJSkp hgGnAIap5G7+HVycaeSRERMmflySf99EFtuv11ny/Ub3fThKSCOHD/IkCliLc699 x1Grl4NvSo40fMrDlspVkXNGJnY89dRcrkHieWdM285a6rsTRjRFeJjc9PQZzhsI esM5IXt3h/Q/I1Qfgw7VczbOtAkjV/2Glh7oIEoFe/tQAj4fON5WuWKN9QnLkgtO YUTNwvap38xky58TUgQMhf1Ez3EiLRyQXOylhcexZgK1hk9M8S89qyDY2yNlZNUO kTsD1Sy/oAdbXzlbvOQE =p1jF -----END PGP SIGNATURE----- --LpU9AX6sbEg93bSMwvRR7tAbNS56o6N1T-- From nobody Sun Apr 15 11:39:24 2018 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 4C34F126D73 for ; Sun, 15 Apr 2018 11:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 60uzUesvtvlX for ; Sun, 15 Apr 2018 11:39:20 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.175]) (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 637CA126D05 for ; Sun, 15 Apr 2018 11:39:20 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 20439 invoked from network); 15 Apr 2018 19:39:18 +0200 Received: from agtx104.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.127.104]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 15 Apr 2018 19:39:18 +0200 To: Paul Hoffman , doh@ietf.org References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> Date: Sun, 15 Apr 2018 19:39:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="41TGZQucbLKmXSITNtHaOy7rvax184KOW" X-WP-MailID: 0adcc024d68deacf8dfd41b6dda5209d X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [MfPU] Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 18:39:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --41TGZQucbLKmXSITNtHaOy7rvax184KOW Content-Type: multipart/mixed; boundary="u8CK52IqKpKdIww4BFgltobOBRbD5xSSh"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman , doh@ietf.org Message-ID: <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> Subject: Re: [Ext] [Doh] Fallback to untrusted DOH servers References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> In-Reply-To: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> --u8CK52IqKpKdIww4BFgltobOBRbD5xSSh Content-Type: multipart/mixed; boundary="------------759DC821FEE9CF9C26A83220" Content-Language: pl This is a multi-part message in MIME format. --------------759DC821FEE9CF9C26A83220 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 14.04.2018 o=C2=A022:54, Paul Hoffman pisze: > On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk w= rote: >> >> Hello, >> Current DOH draft specifies that: >> >> A client MUST >> NOT trust a DNS API server simply because it was discovered, or >> because the client was told to trust the DNS API server by an >> untrusted party. Instead, a client MUST only trust DNS API server >> that is configured as trustworthy. >> >> It may happen that either no trustworthy DOH server has been configure= d, or the >> configured DOH server is not working. In such cases a DOH client would= usually >> revert to using an untrusted DNS server on port 53, possibly one that = was >> discovered through unsecure DHCP. This DNS resolver would also be able= to poison >> DNS caches then. >=20 > The topic of how a user (well, really, an OS or browser) choose a DNS s= erver to use is a worthy one to look at, but not in this document. If som= eone wants to start such a document, it needs to deal with trust in DHCP,= DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH policy. (The= re are likely additional topics...) This draft specifies some limitations on DNS resolvers a client can use. Therefore - I would argue - it is fine to discuss whether these limitatio= ns are appropriate and not overbroad. >=20 > --Paul Hoffman> Greetings, Mateusz Jo=C5=84czyk --------------759DC821FEE9CF9C26A83220 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------759DC821FEE9CF9C26A83220-- --u8CK52IqKpKdIww4BFgltobOBRbD5xSSh-- --41TGZQucbLKmXSITNtHaOy7rvax184KOW 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa045FAAoJEPvWWrhhCv7GPSIP/0148/33nSKvIrZjHepQ/7LZ 6tfAcdv8vNz0u+3thjXOCgAPzlKoyUwGecxhtpshyy4d6B+SXjGklwIVrFrEB+OP GVmVJogn94F6rJ3TDzASOrmlH/Lh6qHpBjxbomRXH+ym/TlJqa3GWCQCg89kYT7Y gqA6aJNcxbj6nxvb2Cu2ZKAZ4lF2SXOr43ykq0qrXuWx10ZmarONos5v1WYE9oXQ 1+wjRVE8kZAo/2Y2aywuuByuy4yMmt7A8+sOf8E/SbhzPEkgVpuGjHXZj81AkztE qkcdl/PCmY5pgIaZ35kEhtUyypNYqv6QpUklBA+lQhDhL9vzwm+hOwh9LL+R/zqx cPIj9DzfmlTtiKiAe1aM1F395GTdHxILXOBqSJm0DOJ+zpDMKwnqXWM1l9m8naIn T46qs43gqmC05vpfVLThECqLRjGvGiMi/krgtVWyJyuim+3h2UUypHtJ0+jdXGul zkY9DdaOS7IHsU6chyZX7CKShRSAkhUiBC0B/it2PSb4HKKP4dZs6vzCkaWCv8tm VzInmEtnRwHRrXCNLRRxVM32+qJsPYothKiTvAdZFA7xREoc1AXaURZXCw0m4wqB Jq0GpHrVi4UJvI9tnzUVNEazY8Y7If9u/seehgg6GyPnnFtXsJKnA1xKXjpO1Lf3 dQx23nQylhHyXLBfrcOJ =n2nF -----END PGP SIGNATURE----- --41TGZQucbLKmXSITNtHaOy7rvax184KOW-- From nobody Sun Apr 15 12:15:19 2018 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 2867412704A for ; Sun, 15 Apr 2018 12:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDecPCxN6jVG for ; Sun, 15 Apr 2018 12:15:15 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2BB126CE8 for ; Sun, 15 Apr 2018 12:15:15 -0700 (PDT) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id E4A5C3A024 for ; Sun, 15 Apr 2018 15:15:09 -0400 (EDT) Received: by mail-ot0-f171.google.com with SMTP id f47-v6so15119275oth.2 for ; Sun, 15 Apr 2018 12:15:09 -0700 (PDT) X-Gm-Message-State: ALQs6tCtq3X5iIFDjn40P2X+jVQuZFloGXoI9XkhR3RKR9MWj5Pzxjv2 kXlczbMmUMhCNIDWpum5QCntgPsIDhLNLrleQTA= X-Google-Smtp-Source: AIpwx4/7G5oWBSeNMM/yFlBGdEoOmr+J//Xo9PDMjwGbKL+u0pnKZrvufRoVBlXlkRS83sxglnBWK9svW6/iFLG29GY= X-Received: by 2002:a9d:2874:: with SMTP id h49-v6mr9289261otd.2.1523819709619; Sun, 15 Apr 2018 12:15:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Sun, 15 Apr 2018 12:15:08 -0700 (PDT) In-Reply-To: <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> From: Patrick McManus Date: Sun, 15 Apr 2018 15:15:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="0000000000007e8ad90569e7ec48" Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 19:15:18 -0000 --0000000000007e8ad90569e7ec48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The document says "must not trust simply because it was discovered".. "only trust configured".. and explicitly does not go into configuration. imo you're reading too much into the text. It's just trying to say an endpoint isn't to be trusted just because it speaks DoH and you found it (e.g. becuase www.example.com pushed you a DoH request and response). Note that it doesn't say "must not use" it says "must not trust". Whether or not you would use an untrusted server if you have no trusted options is not something that's going to be in scope here. On Sun, Apr 15, 2018 at 1:39 PM, Mateusz Jo=C5=84czyk w= rote: > W dniu 14.04.2018 o 22:54, Paul Hoffman pisze: > > On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk w= rote: > >> > >> Hello, > >> Current DOH draft specifies that: > >> > >> A client MUST > >> NOT trust a DNS API server simply because it was discovered, or > >> because the client was told to trust the DNS API server by an > >> untrusted party. Instead, a client MUST only trust DNS API server > >> that is configured as trustworthy. > >> > >> It may happen that either no trustworthy DOH server has been > configured, or the > >> configured DOH server is not working. In such cases a DOH client would > usually > >> revert to using an untrusted DNS server on port 53, possibly one that > was > >> discovered through unsecure DHCP. This DNS resolver would also be able > to poison > >> DNS caches then. > > > > The topic of how a user (well, really, an OS or browser) choose a DNS > server to use is a worthy one to look at, but not in this document. If > someone wants to start such a document, it needs to deal with trust in > DHCP, DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH policy. > (There are likely additional topics...) > > This draft specifies some limitations on DNS resolvers a client can use. > Therefore - I would argue - it is fine to discuss whether these > limitations are > appropriate and not overbroad. > > > > > --Paul Hoffman> > > Greetings, > Mateusz Jo=C5=84czyk > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000007e8ad90569e7ec48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The document says "must not trust simply because= it was discovered".. "only trust configured".. and explicit= ly does not go into configuration.

imo you're = reading too much into the text. It's just trying to say an endpoint isn= 't to be trusted just because it speaks DoH and you found it (e.g. becu= ase www.example.com pushed you a DoH= request and response). Note that it doesn't say "must not use&quo= t; it says "must not trust". Whether or not you would use an untr= usted server if you have no trusted options is not something that's goi= ng to be in scope here.

On Sun, Apr 15, 2018 at 1:39 PM, Mateusz Jo=C5=84czyk= <mat.jonczyk@o2.pl> wrote:
> On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk <= ;mat.jonczyk@o2.pl> wrote:
>>
>> Hello,
>> Current DOH draft specifies that:
>>
>>=C2=A0 =C2=A0A client MUST
>>=C2=A0 =C2=A0NOT trust a DNS API server simply because it was disco= vered, or
>>=C2=A0 =C2=A0because the client was told to trust the DNS API serve= r by an
>>=C2=A0 =C2=A0untrusted party.=C2=A0 Instead, a client MUST only tru= st DNS API server
>>=C2=A0 =C2=A0that is configured as trustworthy.
>>
>> It may happen that either no trustworthy DOH server has been confi= gured, or the
>> configured DOH server is not working. In such cases a DOH client w= ould usually
>> revert to using an untrusted DNS server on port 53, possibly one t= hat was
>> discovered through unsecure DHCP. This DNS resolver would also be = able to poison
>> DNS caches then.
>
> The topic of how a user (well, really, an OS or browser) choose a DNS = server to use is a worthy one to look at, but not in this document. If some= one wants to start such a document, it needs to deal with trust in DHCP, DH= CP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH policy. (There ar= e likely additional topics...)

This draft specifies some limitations on DNS resolvers a client can = use.
Therefore - I would argue - it is fine to discuss whether these limitations= are
appropriate and not overbroad.

>
> --Paul Hoffman>

Greetings,
Mateusz Jo=C5=84czyk

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


--0000000000007e8ad90569e7ec48-- From nobody Mon Apr 16 08:31:19 2018 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 5D3D312E05C for ; Mon, 16 Apr 2018 08:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 cJeYs93moajk for ; Mon, 16 Apr 2018 08:31:15 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 A514212DB6C for ; Mon, 16 Apr 2018 08:31:15 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1EC852804BD; Mon, 16 Apr 2018 17:31:14 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 18D142805BD; Mon, 16 Apr 2018 17:31:14 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 1257E2804BD; Mon, 16 Apr 2018 17:31:14 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0F3CD6424E41; Mon, 16 Apr 2018 17:31:14 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 016D541396; Mon, 16 Apr 2018 17:31:13 +0200 (CEST) Date: Mon, 16 Apr 2018 17:31:13 +0200 From: Stephane Bortzmeyer To: Martin Thomson Cc: Paul Hoffman , DoH WG Message-ID: <20180416153113.alje2qtittsgsrq2@nic.fr> References: <152329012604.30804.10999413911543482261@ietfa.amsl.com> <238C2A29-5A77-4561-8D2B-A9E3A66AC24E@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.4.16.152117 Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-06.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 15:31:18 -0000 On Tue, Apr 10, 2018 at 08:56:05AM +1000, Martin Thomson wrote a message of 27 lines which said: > I would say that application/dns is perfectly sufficient. Already reserved, with slightly different semantics (see RFC 4027 and 2540). From nobody Tue Apr 17 16:14:19 2018 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 BD4B9127010 for ; Tue, 17 Apr 2018 16:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxtJktEmu4iZ for ; Tue, 17 Apr 2018 16:14:15 -0700 (PDT) Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (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 D1862126C83 for ; Tue, 17 Apr 2018 16:14:14 -0700 (PDT) Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) (envelope from "albertito@blitiri.com.ar") ; Wed, 18 Apr 2018 00:14:12 +0100 Date: Wed, 18 Apr 2018 00:14:11 +0100 From: Alberto Bertogli To: doh@ietf.org Message-ID: <20180417231411.jcjfhqpgvqdkbupj@blitiri.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [Doh] Experimental implementation of DoH (draft -07) in dnss X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 23:14:16 -0000 Hi! I hope this is ok to post on this list. I've added experimental DoH support to a DNS proxy that I wrote some time ago (which also does DNS over the HTTPS+JSON defined by dns.google.com). It supports both server (DNS in, HTTPS out) and client (HTTPS in, DNS out) modes. You can find it here: https://blitiri.com.ar/git/r/dnss/ DoH support is still experimental, so some of the documentation has not been fully updated yet. I expect to adjust it as new drafts appear. Cache-related headers are on the TODO list (but it is fully functional without them anyway). Overall I found the draft very clear, and it was quite straightforward to implement (I hope I did not overlook anything major :) Thanks a lot! Alberto PS: In case you're curious, here are the two key changes: Client mode (DNS in, DoH out) patch: https://blitiri.com.ar/git/r/dnss/c/5cc895a891bade8fba30d611720f65652a1f6909/ Server mode (DoH in, DNS out) patch: https://blitiri.com.ar/git/r/dnss/c/9c203de38b9e12f4dd94db10f7df8284a9091d83/ Also once Cloudflare supports the -07's new content type the daemon should be able to talk with it just fine (it was working ok with -05). From nobody Wed Apr 18 12:07:40 2018 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 8F1EE126C26 for ; Wed, 18 Apr 2018 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 S3OYP13KkqeB for ; Wed, 18 Apr 2018 12:07:37 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 60DEF1252BA for ; Wed, 18 Apr 2018 12:07:37 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id q85-v6so3782988itc.0 for ; Wed, 18 Apr 2018 12:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XIuvEadNpQDGqzfuzv/vDwONuIcQgbB11IYcug1ZR5Q=; b=ZE+Nmc+pOJDP3dRQuUhvSahwEnwYb+wsI8rPVXX1LyXXnipm8hfrOz0lkjLPmQ/8rg Dxavva8XulHKFSoZMLOIzfLoirOWpn78ToZgV2fcJZ1fnIjBHacOOMPWvk8WByF1/35v V14kF3OKL8OWw/ZefYXKL2H//s4X2YMrNXP6kXE9HlyJBfhRcUanE1t5832IAjl60mVJ Kf0AWYVhN1e6vMXDjGpDfpSFh6r+nn+6Mr+WYNPt4wWfDRWzqdPeuYu5I4Ep8y67Jiad QxIEkHnR5SlscmuQZTMNEvwJXQjXoByYuVKDCFecSEBo5oUk86y26/cHnNQbeFffbmen ooVg== 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; bh=XIuvEadNpQDGqzfuzv/vDwONuIcQgbB11IYcug1ZR5Q=; b=keRN7fx89fLEn2kFSo06RcYTBqJADUgyEFv9EQ2GEmU88MOLCsYdOfg5zvumCBCLE/ RWp4myZdhYSWOMujedUDRL56bS42mjk0YtuPbIJ2FqM/Fj0u484b7cmme1boSyWlG7KK CWVwZXC2uk5QjygwwUb5dyb2hRefMgQROSM/T+cf0I+VN/OLjhSJSC5t+qxDnnJSnH9o 19I5BG6+ztW32t3fcyK4qyOe+5u27mX5eXr6yqWBSjdPq7lCnAYxXdiDDlqbdpb/ZJmI kBNrSIp5H+6g+sb4c+NB2dDKX2wLCjW/BV6SG6YAXzhPWVcFnVmtUjZW7r89EaBch/d5 Bsew== X-Gm-Message-State: ALQs6tAvJW2Wsolj5H+CVB6xb+raobYSQoW7+KYhgFVlpXnG1/gfuANZ 4uZJKABFRBZPHUsJOZLALntYfvSL03v4tZzJJsn1lcEejyw= X-Google-Smtp-Source: AIpwx48WaR8/ldnnr/EyZ7Wj8HoU6wDleqxvEkVnKOEEB6Yl5pPI5mY0avsmj6PjJ0xObB4g4FzcjJyB4JHbNrOBZ5M= X-Received: by 2002:a24:718a:: with SMTP id n132-v6mr3839070itc.7.1524078455924; Wed, 18 Apr 2018 12:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.80.21 with HTTP; Wed, 18 Apr 2018 12:07:35 -0700 (PDT) From: Ben Schwartz Date: Wed, 18 Apr 2018 15:07:35 -0400 Message-ID: To: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000064ce8056a242bdf" Archived-At: Subject: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 19:07:39 -0000 --000000000000064ce8056a242bdf Content-Type: multipart/alternative; boundary="000000000000fa2d9a056a242aa1" --000000000000fa2d9a056a242aa1 Content-Type: text/plain; charset="UTF-8" All, This message starts a two week WG Last Call on advancing: Title : DNS Queries over HTTPS Author : Paul Hoffman, Patrick McManus Filename : draft-ietf-doh-dns-over-https-07 Pages : 17 Date : 2018-04-11 as a Standards Track document. The last call will end on May 2, 2018. All substantive comments are to be sent to the doh@ietf.org list for discussions. Editorial comments can be sent to the document editor. You can find the latest version of the document here: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 Regards, Ben & tale --000000000000fa2d9a056a242aa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,
This message starts a two week WG Last Call on advancing:

=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = DNS Queries over HTTPS
=C2=A0 Author=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Paul Hoffman, Patrick McManus
=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-do= h-dns-over-https-07
=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 17=
<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12= .8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb= (255,255,255);text-decoration-style:initial;text-decoration-color:initial;f= loat:none;display:inline">=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-04-11

as a Standards Track docume= nt. The last call will end on=C2=A0May 2, 2018.
All substantive commen= ts are to be sent to the=C2=A0doh@ietf.org=C2=A0list for
discussions. Editorial commen= ts can be sent to the document editor.

You can fi= nd the latest version of the document here:
--000000000000fa2d9a056a242aa1-- --000000000000064ce8056a242bdf 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCRC4Se+e6WBYtzU9VTOZx4 tQM6Ibet5QXliVRecC8GLDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA0MTgxOTA3MzZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEADrLvALbDIHccSqLNRff0F6LTRAPppO1zFkxitP17 3nVfjCcnQMuzTnZ/gJUVcpMTWZQDuLaTVx9XB8b4AAKrmQ43JYdRw1/m6cLQc34uYYBwi9YnMZUX v90yIgHHQk6q4CuKMCn/NUKR005NzIHR4sa+athqwujeEOo8uenZl0J28a6pJRo6tRxQEFqFiWN6 8XR9Yqejf00PftpvgcfggCtZmQ1jJykqh7vmDp5OsKITzMDFcioZq3omtajf8c2b/0PG/GeROYRD nGgkpxzSCVocRHEoQ6oFiWdrUVfCL1tflFNA2FW0OnZ5e1ejcIxNwPq0hya6ipbtJHfv4Sl7nw== --000000000000064ce8056a242bdf-- From nobody Sun Apr 22 06:22:08 2018 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 2203112DA2B for ; Sun, 22 Apr 2018 06:22:03 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 eOZItNjVwTbl for ; Sun, 22 Apr 2018 06:21:58 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 7249C12D959 for ; Sun, 22 Apr 2018 06:21:55 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 30768 invoked from network); 22 Apr 2018 15:21:53 +0200 Received: from aclb249.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.103.249]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 Apr 2018 15:21:53 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , doh@ietf.org References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> Message-ID: <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> Date: Sun, 22 Apr 2018 15:21:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PWei9afLNWJIaxF7TScjMmDT4yFsK87s1" X-WP-MailID: 04b5e104e1ba67f76cd805682907fd46 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [AYPU] Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 13:22:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PWei9afLNWJIaxF7TScjMmDT4yFsK87s1 Content-Type: multipart/mixed; boundary="kQFgnegEEsjuQCcYOslEFOidE0rJ9Y38E"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , doh@ietf.org Message-ID: <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> In-Reply-To: --kQFgnegEEsjuQCcYOslEFOidE0rJ9Y38E Content-Type: multipart/mixed; boundary="------------F2BE5595191129121D91A9E0" Content-Language: pl This is a multi-part message in MIME format. --------------F2BE5595191129121D91A9E0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 15.04.2018 o=C2=A021:15, Patrick McManus pisze: > The document says "must not trust simply because it was discovered".. "= only > trust configured".. and explicitly does not go into configuration. > > imo you're reading too much into the text. It's just trying to say an e= ndpoint > isn't to be trusted just because it speaks DoH and you found it (e.g. b= ecuase > www.example.com pushed you a DoH request and > response). Note that it doesn't say "must not use" it says "must not tr= ust". > Whether or not you would use an untrusted server if you have no trusted= > options is not something that's going to be in scope here. Hello, Sorry, but I didn't have time to deal with DOH in the last week. I think if Your interpretation of DOH is correct, that the text is unclea= r there and should be clarified. I would suggest to add the following clarification: A client MAY use an untrustworthy DNS API server as a fallback. I am going to submit a draft that specifies how a fallback DNS API server= could be retrieved from DHCP. Greetings, Mateusz Jo=C5=84czyk > > On Sun, Apr 15, 2018 at 1:39 PM, Mateusz Jo=C5=84czyk > wrote: > > W dniu 14.04.2018 o=C2=A022:54, Paul Hoffman pisze: > > On Apr 14, 2018, at 9:36 AM, Mateusz Jo=C5=84czyk > wrote: > >> > >> Hello, > >> Current DOH draft specifies that: > >> > >>=C2=A0 =C2=A0A client MUST > >>=C2=A0 =C2=A0NOT trust a DNS API server simply because it was dis= covered, or > >>=C2=A0 =C2=A0because the client was told to trust the DNS API ser= ver by an > >>=C2=A0 =C2=A0untrusted party.=C2=A0 Instead, a client MUST only t= rust DNS API server > >>=C2=A0 =C2=A0that is configured as trustworthy. > >> > >> It may happen that either no trustworthy DOH server has been > configured, or the > >> configured DOH server is not working. In such cases a DOH client= would > usually > >> revert to using an untrusted DNS server on port 53, possibly one= that was > >> discovered through unsecure DHCP. This DNS resolver would also b= e able > to poison > >> DNS caches then. > > > > The topic of how a user (well, really, an OS or browser) choose a= DNS > server to use is a worthy one to look at, but not in this document.= If > someone wants to start such a document, it needs to deal with trust= in > DHCP, DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH p= olicy. > (There are likely additional topics...) > > This draft specifies some limitations on DNS resolvers a client can= use. > Therefore - I would argue - it is fine to discuss whether these > limitations are > appropriate and not overbroad. > > > > > --Paul Hoffman> > > Greetings, > Mateusz Jo=C5=84czyk > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > > --------------F2BE5595191129121D91A9E0 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------F2BE5595191129121D91A9E0-- --kQFgnegEEsjuQCcYOslEFOidE0rJ9Y38E-- --PWei9afLNWJIaxF7TScjMmDT4yFsK87s1 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa3IxvAAoJEPvWWrhhCv7GIAoP/jb9286EM6TdSjsSKhhu3Hbe wypLQM6aBt+Mq5cvGurve8Gai46mhZO725Xxg5A7z9eTtZq2UU1SgZu/1cQsgUE6 rK/7WdeNLy5l+4hHv9C/KP0AaZMQytOQqCGedM3uQceXo5Ej7ilknYDbXolP4BbS 0zzZ9KMwhvpu22O8hsPbU39N4q8LrnLD3uZkYVHHhwJWLm4bbffcKDVDKKsPTXXo pB77fzIWnzZk4Bt3aUTqCGR5F9G3dtBWHsK+akwpOu0wAvuk9dPi81uzpinsDuZx PXkFYvoqMjSveFTVYs73pqERhfZXVfkxLiF6CBV9vOl1yOEMm/e37/s5R2ig3fs7 UajCvbfDJHH1SOCDSMbMJ0aP/w42sYlsgjSI47jyV1bQS/11R+8xohtqgQXcolXq bB3+w20XKfMCHH/SSDC90eTrZJjvDnD1yEFWMBko57fW2Qn+Sg3+r6BwoldcL8wg sHtsWVZXWxWzi0//T8G4kgO6LMuPQGmYW20xEyFghAFMqGjdEqZrTipRtNQ96S+r iJ7lfMIoNLOwhmx5kFnjJNezrbefKMkcuvUBPvJaUZWId/6ODg+4tq8jHDH5/GM4 ggup92h4QYAMNEmW4HiXjX5rCTpLDnaLiu0s8ItRoBH7GHTbzc29tgkwu6Qp0ofI lt0ArCBx9K4EKbSOrw81 =qgTD -----END PGP SIGNATURE----- --PWei9afLNWJIaxF7TScjMmDT4yFsK87s1-- From nobody Sun Apr 22 08:15:36 2018 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 B642912D961 for ; Sun, 22 Apr 2018 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Xc9K7yI9fmSD for ; Sun, 22 Apr 2018 08:15:28 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4551412751F for ; Sun, 22 Apr 2018 08:15:28 -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.1178.4; Sun, 22 Apr 2018 08:15:26 -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.1178.000; Sun, 22 Apr 2018 08:15:25 -0700 From: Paul Hoffman To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= CC: DoH WG Thread-Topic: [Doh] [Ext] Fallback to untrusted DOH servers Thread-Index: AQHT1O4btV7cjbCdoU2f7xFlpQyfG6QNRTMAgAAfwgA= Date: Sun, 22 Apr 2018 15:15:25 +0000 Message-ID: <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> In-Reply-To: <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_E9221964-6438-4D98-90A3-069E5BCA7A5E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 15:15:32 -0000 --Apple-Mail=_E9221964-6438-4D98-90A3-069E5BCA7A5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 22, 2018, at 6:21 AM, Mateusz Jo=C5=84czyk = wrote: > I think if Your interpretation of DOH is correct, that the text is = unclear there > and should be clarified. > I would suggest to add the following clarification: >=20 > A client MAY use an untrustworthy DNS API server as a fallback. This seems horribly dangerous without a clear definition of "fallback". > I am going to submit a draft that specifies how a fallback DNS API = server could > be retrieved from DHCP. That would be quite useful. If you do that, wouldn't it define the DNS = API server as trusted? --Paul Hoffman --Apple-Mail=_E9221964-6438-4D98-90A3-069E5BCA7A5E 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----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlrcpwwACgkQsZnCoeEP RXvakwf/b2iRs28IgLr1xuolsLq9rnVeKfAF1sKgV/Ufrs1JtyzQxrQ9TO5q8bXk SVYYl/I5L/g4Tcko8txHo/4wMQDWoJS0dC2Gp/QfMovrd646z2z+/iGKhMwBBeFa EvJdKgGKm16r+JDRmO1QMlRF4zQ7oz3+QF2oH4KNrzU497m1hvsgYQ04xatj+6xT tZ6c0kQ7joRIuvkfOnJzQCeRsM4895nxOOtxg+F2zDjjtcDb+Dd5r4g+hXqa4lsg Zeb3KwVVKnhoiSGEWbjMjrLGufcolHZ2+Tc/nt22rVFLAjxmH25AJtc2x08pCAjX b40MVzqSTDL0EfiTLfjlayd6uNhbIw== =6ECz -----END PGP SIGNATURE----- --Apple-Mail=_E9221964-6438-4D98-90A3-069E5BCA7A5E-- From nobody Mon Apr 23 03:04:02 2018 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 AA047126BF6 for ; Mon, 23 Apr 2018 03:04:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z88psShMLPvB for ; Mon, 23 Apr 2018 03:03:59 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 0FB3B1241F8 for ; Mon, 23 Apr 2018 03:03:57 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 28702 invoked from network); 23 Apr 2018 11:37:14 +0200 Received: from alr129.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.26.47.129]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 23 Apr 2018 11:37:14 +0200 To: Paul Hoffman , doh@ietf.org References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> Date: Mon, 23 Apr 2018 11:36:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hJDrJykKDiCfoG7uZDSJpy2ljp07dZV0y" X-WP-MailID: 0d8b9f514abe5fb76772955601324b60 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [obOE] Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 10:04:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hJDrJykKDiCfoG7uZDSJpy2ljp07dZV0y Content-Type: multipart/mixed; boundary="0YO5hCMbyv2OtpJYYT65uAGHXqEITVSjb"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman , doh@ietf.org Message-ID: <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> In-Reply-To: <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> --0YO5hCMbyv2OtpJYYT65uAGHXqEITVSjb Content-Type: multipart/mixed; boundary="------------DA344D2499C190CE0279CAD4" Content-Language: pl This is a multi-part message in MIME format. --------------DA344D2499C190CE0279CAD4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 22.04.2018 o=C2=A017:15, Paul Hoffman pisze: > On Apr 22, 2018, at 6:21 AM, Mateusz Jo=C5=84czyk w= rote: >> I think if Your interpretation of DOH is correct, that the text is unc= lear there >> and should be clarified. >> I would suggest to add the following clarification: >> >> A client MAY use an untrustworthy DNS API server as a fallback. >=20 > This seems horribly dangerous without a clear definition of "fallback".= There was a definition of "fallback" in a modification I proposed several= mails ago, but I removed it for sake of simplicity. So, I would propose a following addition: A client MAY use an untrustworthy DNS API server as a fallback, for example: when no trustworthy DNS API= server is configured, no configured DNS server works or when the trustworthy DNS API server returned NXDOMAIN (and the client checks whether an untrustworthy DNS API server would resolve the addre= ss in question). The client MUST use separate DNS API caches for trustworthy and untrus= tworthy DNS API servers or drop DNS caches when switching from an untrustworth= y DNS API server to a trustworthy one. Ted Lemon suggested in a private e-mail that contacting an untrusworthy D= NS API server after the trustworthy DNS API server returned NXDOMAIN exposes all= mistyped domains to the untrustworthy DNS API server. This is a valid con= cern, and applies equally well to using old-school DNS in such a situation. I would therefore propose to add the following warning after the phrase: "If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client." When a DNS API server returns NXDOMAIN, a client may wish to check whether another server will resolve the domain name (as this may be a local name to be resolved by a local DNS server). Doing so will, however, expose all mistyped domain to that server. >=20 >> I am going to submit a draft that specifies how a fallback DNS API ser= ver could >> be retrieved from DHCP. >=20 > That would be quite useful. If you do that, wouldn't it define the DNS = API server as trusted? No, the server retrieved via DHCP is going to an untrustworthy DNS API se= rver (as defined above) as DHCP is usually unauthenticated and prone to variou= s manipulations. >=20 > --Paul Hoffman >=20 Greetings, Mateusz Jo=C5=84czyk --------------DA344D2499C190CE0279CAD4 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------DA344D2499C190CE0279CAD4-- --0YO5hCMbyv2OtpJYYT65uAGHXqEITVSjb-- --hJDrJykKDiCfoG7uZDSJpy2ljp07dZV0y 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa3alJAAoJEPvWWrhhCv7GBIoP/2ynD12NjZ0jjM/x5pzJXhNI RlQlqx/FNKfZW01RVa3Ao9o/zBdDGdw9k1Si3kijEyPt/aaVS1rtT080zQVsamdh YCswJQRuDLTD6jUMQiCkJJcyRENv99x1+/AzLQ6roApBjAXO4w+dVJVA0+seyZkF 1FXPQ/dGzJTFoL/OGWt8vi4HE5d43hEdHRldJV8TyYMyP7oRD49zcSboP60PVpli EXCktuQ/ETM7scC+E6r4eCtBSl6CexxNg7MRgWd8nbEKlizCqS6YGO+9COfAbhyA ZBAY5MGPfWNk3Xt7+4Ge0gc3RiybLC532K6j/1siquejs/yoibLBs4vVaqwPdYwE 4yFBbAsG19fodRQ5CecsmXKDZkbDBbdiyLg/Tnouns5DXe8KRpFlkRYw1CjIuqq1 f3twhhHdvEivgYo59FVACJnwo94bCZ8Mpi0IKqwz0yoxWNOxxO7w0YrasUq/Gc+R 6t2Orz/XnsGPSbr1/lH4FRqQdpKbFNIgvkqymYA2n04J+cQyNpOFFyEpwEHxVy7K ReGeUA5yvD3F2b5hWKGUA/eUjQ9WO6OFtMN3KT45/cWjNvrJI5MuYpe11efpzHu0 H8aJh07ggtbePW1+2ur6KqkSm66nvQF+JjcavU5r6XnLu3ypbH19i+tXjfOm9zjy J3CIgDCqeBy4xKR2N8Bs =A3/8 -----END PGP SIGNATURE----- --hJDrJykKDiCfoG7uZDSJpy2ljp07dZV0y-- From nobody Mon Apr 23 05:41:03 2018 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 9A6B7127871 for ; Mon, 23 Apr 2018 05:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywU1uHpSER2f for ; Mon, 23 Apr 2018 05:41:00 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 05CED126C89 for ; Mon, 23 Apr 2018 05:41:00 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id 580E23A019 for ; Mon, 23 Apr 2018 08:40:59 -0400 (EDT) Received: by mail-ot0-f169.google.com with SMTP id y10-v6so3991552otg.10 for ; Mon, 23 Apr 2018 05:40:59 -0700 (PDT) X-Gm-Message-State: ALQs6tAk71ZF/tVVkeW/t6BVGaLIuQsWEQo6wCvDKU39ePHbauhjLgR+ 4OX3mSsXsv/wXIKLZu0ifasR5m+35QgJAGt6TeY= X-Google-Smtp-Source: AB8JxZr21y/c5/k8JkgqUZvLtF2dQHK09D8e0dv3yy9uR0+rfC3rjLGBAtBLye7Yd8W3ICvJq1xl4nXWUNE74GDkOU4= X-Received: by 2002:a9d:4181:: with SMTP id p1-v6mr9336168ote.2.1524487259088; Mon, 23 Apr 2018 05:40:59 -0700 (PDT) MIME-Version: 1.0 References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> In-Reply-To: <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> From: Patrick McManus Date: Mon, 23 Apr 2018 12:40:48 +0000 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="0000000000008aedce056a835954" Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 12:41:03 -0000 --0000000000008aedce056a835954 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I really think you are discussing discovery. The chairs have said that is out of scope for this draft but they are soliciting proposals for new work that could include it. On Mon, Apr 23, 2018, 06:04 Mateusz Jo=C5=84czyk wrote: > W dniu 22.04.2018 o 17:15, Paul Hoffman pisze: > > On Apr 22, 2018, at 6:21 AM, Mateusz Jo=C5=84czyk w= rote: > >> I think if Your interpretation of DOH is correct, that the text is > unclear there > >> and should be clarified. > >> I would suggest to add the following clarification: > >> > >> A client MAY use an untrustworthy DNS API server as a fallback. > > > > This seems horribly dangerous without a clear definition of "fallback". > > There was a definition of "fallback" in a modification I proposed several > mails > ago, but I removed it for sake of simplicity. > > So, I would propose a following addition: > A client MAY use an untrustworthy > DNS API server as a fallback, for example: when no trustworthy DNS API > server is configured, no configured DNS server works or > when the trustworthy DNS API server returned NXDOMAIN (and the client > checks whether an untrustworthy DNS API server would resolve the > address in > question). > > The client MUST use separate DNS API caches for trustworthy and > untrustworthy > DNS API servers or drop DNS caches when switching from an untrustworth= y > DNS API server to a trustworthy one. > > Ted Lemon suggested in a private e-mail that contacting an untrusworthy > DNS API > server after the trustworthy DNS API server returned NXDOMAIN exposes all > mistyped domains to the untrustworthy DNS API server. This is a valid > concern, > and applies equally well to using old-school DNS in such a situation. > > I would therefore propose to add the following warning after the phrase: > "If a client of this protocol encounters an HTTP error after > sending a > DNS query, and then falls back to a different > DNS retrieval mechanism, doing so can weaken the privacy and > authenticity expected by the user of the client." > > When a DNS API server returns NXDOMAIN, a client may wish to chec= k > whether another server will resolve the domain name (as this may = be > a local name to be resolved by a local DNS server). Doing so will= , > however, expose all mistyped domain to that server. > > > > > >> I am going to submit a draft that specifies how a fallback DNS API > server could > >> be retrieved from DHCP. > > > > That would be quite useful. If you do that, wouldn't it define the DNS > API server as trusted? > > No, the server retrieved via DHCP is going to an untrustworthy DNS API > server > (as defined above) as DHCP is usually unauthenticated and prone to variou= s > manipulations. > > > > > --Paul Hoffman > > > > Greetings, > Mateusz Jo=C5=84czyk > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000008aedce056a835954 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I really think you are discussing discovery. The chairs h= ave said that is out of scope for this draft but they are soliciting propos= als for new work that could include it.

On Mon, Apr 23, 2018, 06:04 Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> wrote:
=
W dniu 22.04.2018 o=C2=A017:15, Paul Hoffman= pisze:
> On Apr 22, 2018, at 6:21 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl= > wrote:
>> I think if Your interpretation of DOH is correct, that the text is= unclear there
>> and should be clarified.
>> I would suggest to add the following clarification:
>>
>>=C2=A0 =C2=A0 =C2=A0 A client MAY use an untrustworthy DNS API serv= er as a fallback.
>
> This seems horribly dangerous without a clear definition of "fall= back".

There was a definition of "fallback" in a modification I proposed= several mails
ago, but I removed it for sake of simplicity.

So, I would propose a following addition:
=C2=A0 =C2=A0A client MAY use an untrustworthy
=C2=A0 =C2=A0DNS API server as a fallback, for example: when no trustworthy= DNS API
=C2=A0 =C2=A0server is configured, no configured DNS server works or
=C2=A0 =C2=A0when the trustworthy DNS API server returned NXDOMAIN (and the= client
=C2=A0 =C2=A0checks whether an untrustworthy DNS API server would resolve t= he address in
=C2=A0 =C2=A0question).

=C2=A0 =C2=A0The client MUST use separate DNS API caches for trustworthy an= d untrustworthy
=C2=A0 =C2=A0DNS API servers or drop DNS caches when switching from an untr= ustworthy
=C2=A0 =C2=A0DNS API server to a trustworthy one.

Ted Lemon suggested in a private e-mail that contacting an untrusworthy DNS= API
server after the trustworthy DNS API server returned NXDOMAIN exposes all mistyped domains to the untrustworthy DNS API server. This is a valid conce= rn,
and applies equally well to using old-school DNS in such a situation.

I would therefore propose to add the following warning after the phrase: =C2=A0 =C2=A0 =C2=A0 =C2=A0 "If a client of this protocol encounters a= n HTTP error after sending a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS query, and then falls back to a different =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS retrieval mechanism, doing so can weaken th= e privacy and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticity expected by the user of the client= ."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a DNS API server returns NXDOMAIN, a clien= t may wish to check
=C2=A0 =C2=A0 =C2=A0 =C2=A0 whether another server will resolve the domain = name (as this may be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a local name to be resolved by a local DNS serv= er). Doing so will,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 however, expose all mistyped domain to that ser= ver.


>
>> I am going to submit a draft that specifies how a fallback DNS API= server could
>> be retrieved from DHCP.
>
> That would be quite useful. If you do that, wouldn't it define the= DNS API server as trusted?

No, the server retrieved via DHCP is going to an untrustworthy DNS API serv= er
(as defined above) as DHCP is usually unauthenticated and prone to various<= br> manipulations.

>
> --Paul Hoffman
>

Greetings,
Mateusz Jo=C5=84czyk
_______________________________________________
Doh mailing list
Doh@ie= tf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000008aedce056a835954-- From nobody Mon Apr 23 05:57:51 2018 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 46116124C27 for ; Mon, 23 Apr 2018 05:57:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6lnjh3Bc_yqO for ; Mon, 23 Apr 2018 05:57:42 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.175]) (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 9D6FD126C89 for ; Mon, 23 Apr 2018 05:57:41 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 16843 invoked from network); 23 Apr 2018 14:57:38 +0200 Received: from ams127.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.26.74.127]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 23 Apr 2018 14:57:38 +0200 To: Patrick McManus Cc: Paul Hoffman , DoH WG References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> Date: Mon, 23 Apr 2018 14:56:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DoGkeLOn3daz8oXuLbLrXgFYdFYKjIBA3" X-WP-MailID: 2f1d8a405395687a5b921437451af4ce X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [oWOE] Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 12:57:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DoGkeLOn3daz8oXuLbLrXgFYdFYKjIBA3 Content-Type: multipart/mixed; boundary="rSphS9YuxzdVg8xsL1oS1XB61YNa2Ol7J"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus Cc: Paul Hoffman , DoH WG Message-ID: <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> In-Reply-To: --rSphS9YuxzdVg8xsL1oS1XB61YNa2Ol7J Content-Type: multipart/mixed; boundary="------------A05A24F50B8EE782FD856E19" Content-Language: pl This is a multi-part message in MIME format. --------------A05A24F50B8EE782FD856E19 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What I am discussing here are modifications to DOH so that adding support= for discovery would be possible without modifying the future RFC. Thanks, Mateusz Jo=C5=84czyk W dniu 23.04.2018 o=C2=A014:40, Patrick McManus pisze: > I really think you are discussing discovery. The chairs have said that = is out of > scope for this draft but they are soliciting proposals for new work tha= t could > include it. >=20 > On Mon, Apr 23, 2018, 06:04 Mateusz Jo=C5=84czyk > wrote: >=20 > W dniu 22.04.2018 o=C2=A017:15, Paul Hoffman pisze: > > On Apr 22, 2018, at 6:21 AM, Mateusz Jo=C5=84czyk > wrote: > >> I think if Your interpretation of DOH is correct, that the text = is > unclear there > >> and should be clarified. > >> I would suggest to add the following clarification: > >> > >>=C2=A0 =C2=A0 =C2=A0 A client MAY use an untrustworthy DNS API se= rver as a fallback. > > > > This seems horribly dangerous without a clear definition of "fall= back". >=20 > There was a definition of "fallback" in a modification I proposed s= everal mails > ago, but I removed it for sake of simplicity. >=20 > So, I would propose a following addition: > =C2=A0 =C2=A0A client MAY use an untrustworthy > =C2=A0 =C2=A0DNS API server as a fallback, for example: when no tru= stworthy DNS API > =C2=A0 =C2=A0server is configured, no configured DNS server works o= r > =C2=A0 =C2=A0when the trustworthy DNS API server returned NXDOMAIN = (and the client > =C2=A0 =C2=A0checks whether an untrustworthy DNS API server would r= esolve the address in > =C2=A0 =C2=A0question). >=20 > =C2=A0 =C2=A0The client MUST use separate DNS API caches for trustw= orthy and untrustworthy > =C2=A0 =C2=A0DNS API servers or drop DNS caches when switching from= an untrustworthy > =C2=A0 =C2=A0DNS API server to a trustworthy one. >=20 > Ted Lemon suggested in a private e-mail that contacting an untruswo= rthy DNS API > server after the trustworthy DNS API server returned NXDOMAIN expos= es all > mistyped domains to the untrustworthy DNS API server. This is a val= id concern, > and applies equally well to using old-school DNS in such a situatio= n. >=20 > I would therefore propose to add the following warning after the ph= rase: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "If a client of this protocol encounter= s an HTTP error after sending a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS query, and then falls back to a dif= ferent > =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS retrieval mechanism, doing so can w= eaken the privacy and > =C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticity expected by the user of th= e client." >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 When a DNS API server returns NXDOMAIN,= a client may wish to check > =C2=A0 =C2=A0 =C2=A0 =C2=A0 whether another server will resolve the= domain name (as this may be > =C2=A0 =C2=A0 =C2=A0 =C2=A0 a local name to be resolved by a local = DNS server). Doing so will, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 however, expose all mistyped domain to = that server. >=20 >=20 > > > >> I am going to submit a draft that specifies how a fallback DNS A= PI server > could > >> be retrieved from DHCP. > > > > That would be quite useful. If you do that, wouldn't it define th= e DNS API > server as trusted? >=20 > No, the server retrieved via DHCP is going to an untrustworthy DNS = API server > (as defined above) as DHCP is usually unauthenticated and prone to = various > manipulations. >=20 > > > > --Paul Hoffman > > >=20 > Greetings, > Mateusz Jo=C5=84czyk > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >=20 --------------A05A24F50B8EE782FD856E19 Content-Type: application/pgp-keys; name="0x610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------A05A24F50B8EE782FD856E19-- --rSphS9YuxzdVg8xsL1oS1XB61YNa2Ol7J-- --DoGkeLOn3daz8oXuLbLrXgFYdFYKjIBA3 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.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa3dhBAAoJEPvWWrhhCv7G4T4P/Rc3U3C5WbE0H1gEaKsUGemQ 2WLYLZLtRVscDGCDbUSeSfkyelCDOIKJgw0t4ggitKR6TH5+WrS+j46lC+NKmD8b o8H5Idnsh17bjKZQjbITZVsn0SCZXN1r0XQ8GsdAo+P4eANQNGnsknv5jNEBR6/A SizHEUNj77P4L4bQhv5L3Vw0UeSF+L7LJj3fnBYjNZIdG1ZUhWrhZHk/SQZCDK// qMgZ6qpv76N5uWfSkuph6ZOk1XVtJvbgoWfY/xe0JO2NA07OYVXtScuqbT1jXijM wbcSFALkFpPm8S4Je9cOqd+OvsA9w8kfd/iMi/EoopXZWGIfzj0RYubWSf+E9/VH grExiZxCyhE9MhRhjhOuIrbdqxdSsS9tzKhc7TAJDrHgEyTZsUDDhWYrUd55MEZB cjkO8j29+X1Rr5GDMZjwlRSTpskOpHVtGZBIZQrkyUTaaRFszgBZrQe9iqJ8uRmH zebkmA3KDinp6xtfdEgawyQqcR+kUFIG+Cp7pTkA7sxuMOQ5qIEPPRzuL8QjY0ZX yUoFuwtVIpyDwAKC1vgBF+ykI3U0sCMFbALTvWhZj4MwbxoZ8/iaHD+BVWHGOkqH ImQqWz5L7X20yfxilcWcsOUTn8+BRQarsAhEzliYpICtfYHPZojp/8RaUsMQYDIa 8U8ep2UsCnYdtvaemJzg =FZi8 -----END PGP SIGNATURE----- --DoGkeLOn3daz8oXuLbLrXgFYdFYKjIBA3-- From nobody Mon Apr 23 07:11:18 2018 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 DCF95126CD6 for ; Mon, 23 Apr 2018 07:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ik10u5lvGGKQ for ; Mon, 23 Apr 2018 07:11:15 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82441201F8 for ; Mon, 23 Apr 2018 07:11:15 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 23 Apr 2018 07:11:13 -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.1178.000; Mon, 23 Apr 2018 07:11:13 -0700 From: Paul Hoffman To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= CC: DoH WG Thread-Topic: [Doh] [Ext] Fallback to untrusted DOH servers Thread-Index: AQHT1O4btV7cjbCdoU2f7xFlpQyfG6QNRTMAgAAfwgCAATO4AIAAM2sAgAAEdgCAABSvAA== Date: Mon, 23 Apr 2018 14:11:13 +0000 Message-ID: References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> In-Reply-To: <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_F0A06D2C-7FF1-4430-9722-80C3165FAEE8"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 14:11:17 -0000 --Apple-Mail=_F0A06D2C-7FF1-4430-9722-80C3165FAEE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 23, 2018, at 5:56 AM, Mateusz Jo=C5=84czyk = wrote: >=20 > What I am discussing here are modifications to DOH so that adding = support for > discovery would be possible without modifying the future RFC. Updating RFCs for reasons like this happens all the time in the IETF. = Given that we don't know when such an update will happen (and I still = believe it will take a long time to reconcile all of the DNS resolver = discovery methods), it is better to leave the wording as-is and then = update it when the complete document comes out. --Paul Hoffman --Apple-Mail=_F0A06D2C-7FF1-4430-9722-80C3165FAEE8 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----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlrd6WgACgkQsZnCoeEP RXt7SggAtlDNmGQ7Bg0h0FvIB/D9WPwXdliIbPev0LUF5Gw5/u2Rm7uDfwV1JZzd UPaS0F7yqE05WKQv3k96VVnPBdxqvgslBOIsPGrW6H69V4KG6w9kSBP7O3gwJNoM jxA3P4izF1/QDg/OvuqFWvLmVwGs7ZxEG3C730J8FJNLLqO8BlK3GroTzeHZO0ww tXjIaxO4+1C9TxiYyHPHTMQC5vghbeRMCtgmTw/WNjeWFZl4oVzQ/kQJRMV6fHpg NdKtX7o6fyDtH6xbm474r/oGMzEtc+hXAJdkqSrUN+TPIvlDaAaVdNZI8aAR8oXE tIDGx5EXfEk5jNkpyJCA1Mcutp4QQw== =uDg1 -----END PGP SIGNATURE----- --Apple-Mail=_F0A06D2C-7FF1-4430-9722-80C3165FAEE8-- From nobody Mon Apr 23 07:42:30 2018 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 4331D1270A7 for ; Mon, 23 Apr 2018 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 TCRn1ap_Njk8 for ; Mon, 23 Apr 2018 07:42:26 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 D24A0129C51 for ; Mon, 23 Apr 2018 07:42:25 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6-v6so11268189ita.2 for ; Mon, 23 Apr 2018 07:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B3JtyQCUk4PSxAyVuAKWBrINtJiB9d0aPsrybRRJvqY=; b=DcSneAH4/kPb5vJV89zCtM3ogO7W0UFLI1SetVCIdQa3bLH4060R36vWbm+mn2w9y/ OS3DLnvcrI2FeAkCswURhA4tRw4tLzzDSnFyQrftpYSzcQeaYplTiGMun0UTKeU3gU9J yiSoIkOx8OdMYHkckgUuXAyyY+G8zVWVUvD2YHWG29FTGoPwD60VoUQKxbVb1NQjgD9P fgZlJcTOwhjLXAloY+0NJ9M9ZZoFDqPeAOTtf/0NJRnRU8MwEmIA2IB6WcIGVuDic80U uxMPND7hUo5byMq17ocXAe9k2C7A24+AhTeW92HP2djU/V2dXghAvRAwqM4G/CnGCRAB ZNNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B3JtyQCUk4PSxAyVuAKWBrINtJiB9d0aPsrybRRJvqY=; b=TO53PPhhPqVRV3I6tSCiJKldeC1ZK9yOCglrJHtFONO6nnsDoUD5eesX5Jbh/Wgbt/ jxTdh6Bbd0mfrovjzsSG7EY8W098CrIpdmHWqJD/zs5A2o5FMaUQu7aeD8QPC6bvZRLO zqQhgzMd6DezFmD6hIs0AQgn5i+gFanu/C7nmHGsTE0gmshTnP/ngDFrlAYTqhUr+KLa I1B/6cYhOZ/iE4rnatl206gBXetidrJaiXlg6SF7zyWu2TUrVwAjONs84ruMN2kL9LOF oeggnD0isqbAvWnZTFqAGXFU2rpDX6uf+K8sN7r5+qeK2s77rxOBDWKxQ2dY74gFPRRA c9Fw== X-Gm-Message-State: ALQs6tDD/vni7c5X+gFvq5vHEeIQ20FCpOYms/uwTf9Zu9Xy9AIPtEw0 wdwngbVQkZeK6qWGsDMb0BHAWqjhuGeZ6AhOoPSAFg== X-Google-Smtp-Source: AIpwx49ulRqvlxA7rD++6jfXVFt7AUloWAJAB6ltQ6CrZZ8KMzgMWQkFZ6qp7X4d0zViYpSPPFRcXKZ30ATKQZN0HoE= X-Received: by 2002:a24:4e50:: with SMTP id r77-v6mr13001240ita.7.1524494544705; Mon, 23 Apr 2018 07:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.70.12 with HTTP; Mon, 23 Apr 2018 07:42:24 -0700 (PDT) In-Reply-To: References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> From: Ben Schwartz Date: Mon, 23 Apr 2018 10:42:24 -0400 Message-ID: To: Paul Hoffman Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d76133056a850b2b" Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 14:42:29 -0000 --000000000000d76133056a850b2b Content-Type: multipart/alternative; boundary="000000000000cd2a4f056a850b5c" --000000000000cd2a4f056a850b5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mateusz, I'm glad you're thinking about how to discover a DOH service via DHCP. (I would recommend including DNS-over-TLS and RDNSS too.) I don't think your goal conflicts with the existing text, so we can keep the current draft as is. The concept of trust is complex and depends on the situation; the current text is a broad warning that we can easily adjust and refine in future drafts. On Mon, Apr 23, 2018 at 10:11 AM, Paul Hoffman wrote: > On Apr 23, 2018, at 5:56 AM, Mateusz Jo=C5=84czyk wro= te: > > > > What I am discussing here are modifications to DOH so that adding > support for > > discovery would be possible without modifying the future RFC. > > Updating RFCs for reasons like this happens all the time in the IETF. > Given that we don't know when such an update will happen (and I still > believe it will take a long time to reconcile all of the DNS resolver > discovery methods), it is better to leave the wording as-is and then upda= te > it when the complete document comes out. > > --Paul Hoffman > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000cd2a4f056a850b5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mateusz, I'm glad you're thinking about how to dis= cover a DOH service via DHCP.=C2=A0 (I would recommend including DNS-over-T= LS and RDNSS too.)

I don't think your goal conflicts= with the existing text, so we can keep the current draft as is.=C2=A0 The = concept of trust is complex and depends on the situation; the current text = is a broad warning that we can easily adjust and refine in future drafts.

On Mon,= Apr 23, 2018 at 10:11 AM, Paul Hoffman <paul.hoffman@icann.org&g= t; wrote:
On Apr = 23, 2018, at 5:56 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> wrote:
>
> What I am discussing here are modifications to DOH so that adding supp= ort for
> discovery would be possible without modifying the future RFC.

Updating RFCs for reasons like this happens all the time in the IETF= . Given that we don't know when such an update will happen (and I still= believe it will take a long time to reconcile all of the DNS resolver disc= overy methods), it is better to leave the wording as-is and then update it = when the complete document comes out.

--Paul Hoffman

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


--000000000000cd2a4f056a850b5c-- --000000000000d76133056a850b2b 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCt/182YpipdJFOX1iQK0Pl WpSZJFwWC/8GxLmqwakZ0jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA0MjMxNDQyMjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAHIIS86xwDWIoEZ5Q1eN3UG8Bp53y76FB5qVJDLG4 vVaulqW3d8/5bXCVyr3ZDpmPmC+iYFVMzZ9dYrurZ0Ij1oDMrrbpWph72fwYM/iFuoMSKHjhLoiH dgb3/X23M09RiqmhGuFl+RYGWGvZSL9Y4DRQrhpzqhEPytMrSROiqxaGlIZ2oeWTTuQMSkHdnQ8m Ve7D87kPpp2/4U/1nafIYqKEh7N1coRZruvs2eoJnzOg9yXmzt2rysXyZn4vAw7q4Ye6xpax6nBH gqGYMGQ7Yy1U8+7mVH8emePiso23pmJQufxPaEeGwSMqBbN7m/S75emD6f+D9eLfrLu4LEabRQ== --000000000000d76133056a850b2b-- From nobody Mon Apr 23 08:11:20 2018 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 1AEC412D72F for ; Mon, 23 Apr 2018 08:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 IjwTogxzz1Nx for ; Mon, 23 Apr 2018 08:11:16 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 4389812D574 for ; Mon, 23 Apr 2018 08:11:16 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id a25-v6so18065220qtm.1 for ; Mon, 23 Apr 2018 08:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=THmEGsp/qvqNodEZ6dUabhfzCHtlnnfBGTsPAp/jupg=; b=szjKJZPiAFVpTiBC7NQ9ldQuhManDK20/n1xiFpyeeGqH34UUV1w0HgZoBg5dD7/+w L70aLKXwNY44mEYKe0vs5OxPGHUrui6nwep9sOQJnp38XSo18OsjwFQAVjzsTnGILnaW J8JtL3Y3BNFlmACnCph6+rMNlx0R1OR5ajJ1UUNHSwqXki5XieMCmjiVpWKa8OdwTlTS tQK9u+PMkwrbpCGVYFQoiwW4WKS5TGBzZZZstugDBW1gPSpsGWBGshs0wE3q1R4Y8mSv RmvU/Y4I1loFnvURuVsTyzy99/R//aPKyFiJ5Nku5gudOszQXFp5cfMtzCEI3DB0G9a3 QJgg== 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=THmEGsp/qvqNodEZ6dUabhfzCHtlnnfBGTsPAp/jupg=; b=OfUBu87vD04+I107ZJKkHQD2dkVkolPMjfx48trePNL6/y3p8eWnD4ZMN+v9j+zN75 lNo0skZBIujAfdt5iRsn4eJuDgKAoFGB0FkfAqGbKrFMW/PEul9f5m0bgxjc0LIvNBA8 h60OasS4P8Ikpip/Ojj8JQY19o43W4vPzthqDCKuj1VL4m5pOklQLoaiZxX4wXoQM5O/ rHN1VOyTz4Iv0jxyDjFqH44OuXJKU6h3nkt6lSOnNmoi9Hap1EjBK8+P51flxjs+XHJn as/WCznOUTkqx+FQstuQsC0WZ2Fdfs282aYUKFydRS6bqWmvV9k+24dX9I5GYzDSj8sp vqsg== X-Gm-Message-State: ALQs6tBUo/p7sSO6Rlgr2jfawJ3o1pf51QmYWLx4whDahPRX1ZrQ7hUp T8gvsVmqvKWeatov7FY7hW71gg== X-Google-Smtp-Source: AB8JxZpC6HNC+yZZeS5mHE79d+REL6yfdvXrVUlwCUozkyXqc+so3m95xKF5O7vxHf0O6qqk7hfR7w== X-Received: by 10.12.138.133 with SMTP id 5mr1881394qvv.208.1524496275394; Mon, 23 Apr 2018 08:11:15 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id r20sm9739530qke.79.2018.04.23.08.11.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 08:11:14 -0700 (PDT) From: Ted Lemon Message-Id: <3E3A7B62-BF7F-42D1-90B7-C7C7F1E5CD0E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE08D94E-8E71-4216-A26D-AF92294703E5" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 23 Apr 2018 11:11:13 -0400 In-Reply-To: <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> Cc: Patrick McManus , Paul Hoffman , DoH WG To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 15:11:18 -0000 --Apple-Mail=_BE08D94E-8E71-4216-A26D-AF92294703E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 23, 2018, at 8:56 AM, Mateusz Jo=C5=84czyk = wrote: >> Ted Lemon suggested in a private e-mail that contacting an = untrusworthy DNS API >> server after the trustworthy DNS API server returned NXDOMAIN = exposes all >> mistyped domains to the untrustworthy DNS API server. This is a = valid concern, >> and applies equally well to using old-school DNS in such a = situation. Oops, I hadn't intended that to be private. Sigh. --Apple-Mail=_BE08D94E-8E71-4216-A26D-AF92294703E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Apr 23, 2018, at 8:56 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> = wrote:
   Ted Lemon suggested = in a private e-mail that contacting an untrusworthy DNS API
   server after the trustworthy DNS API server = returned NXDOMAIN exposes all
   mistyped = domains to the untrustworthy DNS API server. This is a valid concern,
   and applies equally well to using = old-school DNS in such a = situation.

Oops, I hadn't intended that to be private. =  Sigh.

= --Apple-Mail=_BE08D94E-8E71-4216-A26D-AF92294703E5-- From nobody Mon Apr 23 12:46:12 2018 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 7B2DF12D7E4 for ; Mon, 23 Apr 2018 12:46:10 -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, HTML_MESSAGE=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 uIsku2QUKQwZ for ; Mon, 23 Apr 2018 12:46:07 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE88A126B6E for ; Mon, 23 Apr 2018 12:46:07 -0700 (PDT) Received: from [172.18.245.14] (pool-108-18-165-70.washdc.east.verizon.net [108.18.165.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id C659FE3F; Mon, 23 Apr 2018 15:45:18 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2C822F5B-D6F2-43B2-A036-73E4F7388572" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Apr 2018 15:45:59 -0400 In-Reply-To: Cc: Paul Hoffman , =?utf-8?Q?Mateusz_Jo=C5=84czyk?= , DoH WG To: Ben Schwartz References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:46:10 -0000 --Apple-Mail=_2C822F5B-D6F2-43B2-A036-73E4F7388572 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Willem Toorop and I are working on a DHCPv6 draft for discovering = DNS-over-TLS, DNS-over-DTLS, DNS-over-DoH. We have been experimenting = with different ISC DHCP options to make it as easy to introduce as = possible. Thanks, Tom > On Apr 23, 2018, at 10:42 AM, Ben Schwartz wrote: >=20 > Mateusz, I'm glad you're thinking about how to discover a DOH service = via DHCP. (I would recommend including DNS-over-TLS and RDNSS too.) >=20 > I don't think your goal conflicts with the existing text, so we can = keep the current draft as is. The concept of trust is complex and = depends on the situation; the current text is a broad warning that we = can easily adjust and refine in future drafts. >=20 > On Mon, Apr 23, 2018 at 10:11 AM, Paul Hoffman > wrote: > On Apr 23, 2018, at 5:56 AM, Mateusz Jo=C5=84czyk > wrote: > >=20 > > What I am discussing here are modifications to DOH so that adding = support for > > discovery would be possible without modifying the future RFC. >=20 > Updating RFCs for reasons like this happens all the time in the IETF.. = Given that we don't know when such an update will happen (and I still = believe it will take a long time to reconcile all of the DNS resolver = discovery methods), it is better to leave the wording as-is and then = update it when the complete document comes out. >=20 > --Paul Hoffman >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh = >=20 >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --Apple-Mail=_2C822F5B-D6F2-43B2-A036-73E4F7388572 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Willem Toorop and I are working on a DHCPv6 draft for = discovering DNS-over-TLS, DNS-over-DTLS, DNS-over-DoH. We have been = experimenting with different ISC DHCP options to make it as easy to = introduce as possible.

Thanks,
Tom


On = Apr 23, 2018, at 10:42 AM, Ben Schwartz <bemasc@google.com> = wrote:

Mateusz, I'm glad you're thinking about how to = discover a DOH service via DHCP.  (I would recommend including = DNS-over-TLS and RDNSS too.)

I don't think your goal conflicts with the existing text, so = we can keep the current draft as is.  The concept of trust is = complex and depends on the situation; the current text is a broad = warning that we can easily adjust and refine in future = drafts.

On Mon, Apr 23, 2018 at 10:11 AM, Paul Hoffman = <paul.hoffman@icann.org> = wrote:
On = Apr 23, 2018, at 5:56 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> = wrote:
>
> What I am discussing here are modifications to DOH so that adding = support for
> discovery would be possible without modifying the future RFC.

Updating RFCs for reasons like this happens all the time in the = IETF.. Given that we don't know when such an update will happen (and I = still believe it will take a long time to reconcile all of the DNS = resolver discovery methods), it is better to leave the wording as-is and = then update it when the complete document comes out.

--Paul Hoffman

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


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

= --Apple-Mail=_2C822F5B-D6F2-43B2-A036-73E4F7388572-- From nobody Mon Apr 23 13:05:37 2018 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 1165A12D945 for ; Mon, 23 Apr 2018 13:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 rrzTYQoeFYN4 for ; Mon, 23 Apr 2018 13:05:34 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 58079126B6E for ; Mon, 23 Apr 2018 13:05:34 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 23 Apr 2018 13:05:32 -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.1178.000; Mon, 23 Apr 2018 13:05:32 -0700 From: Paul Hoffman To: Tom Pusateri CC: DoH WG Thread-Topic: [Doh] [Ext] Fallback to untrusted DOH servers Thread-Index: AQHT1O4btV7cjbCdoU2f7xFlpQyfG6QNRTMAgAAfwgCAATO4AIAAM2sAgAAEdgCAABSvAIAACNUAgABU0oCAAAV1gA== Date: Mon, 23 Apr 2018 20:05:31 +0000 Message-ID: <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> In-Reply-To: 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: <540DFAC46891AF4A82DB9ED259995AAB@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:05:36 -0000 On Apr 23, 2018, at 12:45 PM, Tom Pusateri wrote: > Willem Toorop and I are working on a DHCPv6 draft for discovering DNS-ove= r-TLS, DNS-over-DTLS, DNS-over-DoH. We have been experimenting with differe= nt ISC DHCP options to make it as easy to introduce as possible. 1) Why just DHCPv6? DHCPv4 still seems relevant to many of us. :-) 2) Is there a mailing list for "DNS resolver discovery" that this is being = discussed on? --Paul Hoffman= From nobody Mon Apr 23 13:13:57 2018 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 D061D126D45 for ; Mon, 23 Apr 2018 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KD_iri-Sv5XQ for ; Mon, 23 Apr 2018 13:13:54 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F65A126B6E for ; Mon, 23 Apr 2018 13:13:54 -0700 (PDT) Received: from [172.18.245.14] (pool-108-18-165-70.washdc.east.verizon.net [108.18.165.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E9BDCE4B; Mon, 23 Apr 2018 16:13:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> Date: Mon, 23 Apr 2018 16:13:48 -0400 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:13:56 -0000 > On Apr 23, 2018, at 4:05 PM, Paul Hoffman = wrote: >=20 > On Apr 23, 2018, at 12:45 PM, Tom Pusateri wrote: >> Willem Toorop and I are working on a DHCPv6 draft for discovering = DNS-over-TLS, DNS-over-DTLS, DNS-over-DoH. We have been experimenting = with different ISC DHCP options to make it as easy to introduce as = possible. >=20 > 1) Why just DHCPv6? DHCPv4 still seems relevant to many of us. :-) >=20 We also planned to do IPv4. We started with IPv6 because the option = space was more flexible and we could come up with the optimal format. = Then we could do IPv4 and make compromises if needed to handle the = differences once we had worked out the ideal solution. > 2) Is there a mailing list for "DNS resolver discovery" that this is = being discussed on? >=20 > --Paul Hoffman Not that I know of. It=E2=80=99s just private emails between Willem and = I. We planned on submitting it to the DHC working group but copying DNS = WGs for feedback. I will report back with a forum once we finish writing = a few things down. The work is being done on github and we may be able = to just use that forum. Tom From nobody Mon Apr 23 14:32:50 2018 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 3312C12D963 for ; Mon, 23 Apr 2018 14:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 CTYJLBERc12q for ; Mon, 23 Apr 2018 14:32:47 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 BF05712D95A for ; Mon, 23 Apr 2018 14:32:46 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id w12-v6so19527538qti.4 for ; Mon, 23 Apr 2018 14:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NB6NadzNYV6MGQMCxic8LsiU2LHftyZrW8kaI1xY/Gg=; b=NJ4Dnryp0GMrOn+VYKsv6C4RpNp6T8yYzsn1AXGo2nPD5wVZATek4U2zb754RaFkoe WhMAihHR/hqDEDsGNtcRRa/KeZWT9bb1wj1vzoVCo1xRota3C2sofny2cCrOX6K+Gz9k OsNRm6a5VBZS6fXti89uwIYyRB5OewR8QgyUnHbaAhOKiX7YD+Zi995plZ53c1fpOrrE qaebU8jMX6uSWubetvebTRTrSlvt471arYElV4sK3+iOWQJWK0wq9KLQ0JggD6qk1UXv jlVwGDa2xbMtIELnehauq515I97GAUnnTklnX+Fc+ZZgDZsSYsprJxh0EnSn+Qh/xKj+ lM+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=NB6NadzNYV6MGQMCxic8LsiU2LHftyZrW8kaI1xY/Gg=; b=JtZG9KEMAo9eDZIaAt22hwaBrygAcYojkuOgHGy+ERCqvYPb+9y3+GMD1p98GQDexz XEMgx2BvccfKyu0Cba9ZLSnqjoPP7N3Cker35Dclp73/19RVLK7vGrjmvOQBlDerF4lj 3hx5LvKZPdGhU1Z9RrVazQraBdSkOb2VBf1OILPXrvV5uQNwM0zniyuC4jhg8MiyUfbe JekMcpDqakTvxjQFxhMRXXic+fWjxdHUJUxmrVFcrdMiM5n4iXvIP9U1li2SSOwL0KV4 aedE9fAkQGIls22ruFhFAKphnYe1KKg4AMHLr7cBnhonkK9CZMKW0zEOTOSYSTirJ4Nr kfuQ== X-Gm-Message-State: ALQs6tDqbQsGeYGBEyV0b04HK+0GT2zwvMQUDAYGuLulM24nVHEqnBxR QChbXqQWD/DkeTkvehEq6eXHcbUlUbI= X-Google-Smtp-Source: AIpwx4/GoCCzaLMTdi1rSTlZE0cq7zmECM01iURhMpJiBgEoi89gqSaJuZ6MqZcY7aB+lwyHyV6rvA== X-Received: by 2002:ac8:30a1:: with SMTP id v30-v6mr25098145qta.296.1524519165488; Mon, 23 Apr 2018 14:32:45 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id 6sm9676923qkj.55.2018.04.23.14.32.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 14:32:44 -0700 (PDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 23 Apr 2018 17:32:43 -0400 References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> To: DoH WG In-Reply-To: <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> Message-Id: <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 21:32:49 -0000 Tom, it might be worth calling this working group's attention to the = discussion that Cullen and I had a the DHC working group meeting a = couple of years ago where Cullen was concerned because the working group = didn't want to add certain DHCPv6 options, and the working group hadn't = clearly articulated why that was. The answer is that DHCP is good for configuring clients with options in = cases where the motivation of the network operator and the consumer of a = service or configuration provided by DHCP are in alignment, and not when = they are not. So for example you should never configure a host's SMTP = submit server using DHCP, because the network operator may have motives = other than being helpful for wanting to relay your SMTP traffic. On the other hand, the network operator doesn't really have any = motivation for sending you a wrong subnet mask, and while they may be = interested in snooping your DNS traffic, the fact is that you need a DNS = resolver to use the network unless you're going to do full recursive = resolution on the host, so you pretty much have to either trust the = network operator in this case. IIRC Cullen rather effectively bashed = me over the head with this example. My point is that the DNS resolver is actually a very chancy example of a = sensible DHCP option, and the more you think of the DNS resolver as a = trusted service and the less you think of it as network infrastructure, = the less sense it makes to configure it with DHCP (or, for that matter, = ND). Configuring a DoH server with DHCP seems to me, as I mentioned in a = previous comment, to be a pretty questionable idea. I do not support = this work, because I think that it is counter to the goals of DoH = generally. The goal of DoH is to subvert the network operator's = intentions with respect to DNS traffic. That's completely incompatible = with configuring DoH with DHCP (or RA). The inability to reach your configured, trusted DoH server from the = local network is an attack on the host. You are trusting the thing = that is attacking you to provide you with configuration information. = That just doesn't make sense. If you really want to do this, the first step is to clearly state the = threat model that you are addressing by providing DoH in this way, and = to discuss all the threat models you are _not_ addressing by doing so. = And then compare this to the threat model that DoH-without-DHCP = addresses, and see if there is actually any value added by the other = solution. It may be that there is value in automatically configuring DoH servers = using network infrastructure. If that's the case, we should try to = clearly understand what the trust model is for such a configuration = before proceeding to design the bits on the wire. :) From nobody Mon Apr 23 14:40:18 2018 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 2317812DA02 for ; Mon, 23 Apr 2018 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hdmUdKA-FaX1 for ; Mon, 23 Apr 2018 14:40:14 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8F412DA00 for ; Mon, 23 Apr 2018 14:40:13 -0700 (PDT) Received: from [172.18.245.14] (pool-108-18-165-70.washdc.east.verizon.net [108.18.165.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 08861E60; Mon, 23 Apr 2018 17:39:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> Date: Mon, 23 Apr 2018 17:40:10 -0400 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <1E705333-0A56-4557-BDCD-A89B0720C620@bangj.com> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] [Ext] Fallback to untrusted DOH servers X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 21:40:16 -0000 > On Apr 23, 2018, at 5:32 PM, Ted Lemon wrote: >=20 > Tom, it might be worth calling this working group's attention to the = discussion that Cullen and I had a the DHC working group meeting a = couple of years ago where Cullen was concerned because the working group = didn't want to add certain DHCPv6 options, and the working group hadn't = clearly articulated why that was. >=20 > The answer is that DHCP is good for configuring clients with options = in cases where the motivation of the network operator and the consumer = of a service or configuration provided by DHCP are in alignment, and not = when they are not. So for example you should never configure a host's = SMTP submit server using DHCP, because the network operator may have = motives other than being helpful for wanting to relay your SMTP traffic. >=20 > On the other hand, the network operator doesn't really have any = motivation for sending you a wrong subnet mask, and while they may be = interested in snooping your DNS traffic, the fact is that you need a DNS = resolver to use the network unless you're going to do full recursive = resolution on the host, so you pretty much have to either trust the = network operator in this case. IIRC Cullen rather effectively bashed = me over the head with this example. >=20 > My point is that the DNS resolver is actually a very chancy example of = a sensible DHCP option, and the more you think of the DNS resolver as a = trusted service and the less you think of it as network infrastructure, = the less sense it makes to configure it with DHCP (or, for that matter, = ND). >=20 > Configuring a DoH server with DHCP seems to me, as I mentioned in a = previous comment, to be a pretty questionable idea. I do not support = this work, because I think that it is counter to the goals of DoH = generally. The goal of DoH is to subvert the network operator's = intentions with respect to DNS traffic. That's completely incompatible = with configuring DoH with DHCP (or RA). >=20 > The inability to reach your configured, trusted DoH server from the = local network is an attack on the host. You are trusting the thing = that is attacking you to provide you with configuration information. = That just doesn't make sense. >=20 > If you really want to do this, the first step is to clearly state the = threat model that you are addressing by providing DoH in this way, and = to discuss all the threat models you are _not_ addressing by doing so. = And then compare this to the threat model that DoH-without-DHCP = addresses, and see if there is actually any value added by the other = solution. >=20 > It may be that there is value in automatically configuring DoH servers = using network infrastructure. If that's the case, we should try to = clearly understand what the trust model is for such a configuration = before proceeding to design the bits on the wire. :) Ted, I totally agree with your reservations and limited scope of = applicability. I think that in certain environments, it does make sense = and we should clearly state what we think can and cannot be accomplished = through these options. We will try to make a logical case for where this = is useful but will concede to the wishes of the community if they think = it is not useful. Thanks, Tom From nobody Mon Apr 23 15:20:29 2018 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 AB48512DA07 for ; Mon, 23 Apr 2018 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 M96glEyl3A6l for ; Mon, 23 Apr 2018 15:20:26 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 238EC124319 for ; Mon, 23 Apr 2018 15:20:26 -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.1178.4; Mon, 23 Apr 2018 15:20:24 -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.1178.000; Mon, 23 Apr 2018 15:20:23 -0700 From: Paul Hoffman To: Ted Lemon CC: DoH WG Thread-Topic: Goals of DOH Thread-Index: AQHT209TpHsfHiw1jEqtAWEcI7/mqA== Date: Mon, 23 Apr 2018 22:06:27 +0000 Message-ID: References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> In-Reply-To: <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Goals of DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 22:20:28 -0000 On Apr 23, 2018, at 2:32 PM, Ted Lemon wrote: > The goal of DoH is to subvert the network operator's intentions with resp= ect to DNS traffic. Can you point to the part of the draft (which is in WG Last Call) where it = says that? If so, I promise to fix it because that is not an intended goal. --Paul Hoffman= From nobody Mon Apr 23 17:27:13 2018 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 4B44412DB6B for ; Mon, 23 Apr 2018 17:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 tHvCQ0NHbfjN for ; Mon, 23 Apr 2018 17:27:10 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 4434912DA6B for ; Mon, 23 Apr 2018 17:27:10 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id v2so18009684qkh.10 for ; Mon, 23 Apr 2018 17:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/fDJv0vgJTdJahlenA8TMYQ3jPYcRLCia7SFF4Jtfzw=; b=0LfvwDclATkkh/6AIZWVP4upbW1aOuSTBgDOTW3wCNkKdF5cgYOfGJxRaHlIL+HjSo hW4y2S1ZFTQ1HxlospxoiJuOH4yYV1254POadADETdJJAKRxXBwY3Ydf5qqbNPlEwnDv JVaj4oV/+wmMtBnU4G/dftR4wHSaknWa/IbBfahKw/cMUSwLeiV5EqR9bFCoh/B8EMfS odK8el/k/C3hquunF900ldYBzyou+Ciz+ucGwXwMehRceSrHFANQNYmjnpHNi3WR8ion G85q/5WlYjlE5Zw6sHdBH8+PaQaVsG4UwRKwS4jmsRLK1q28YtOvtrkfFnGBIej1xMLQ jGfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/fDJv0vgJTdJahlenA8TMYQ3jPYcRLCia7SFF4Jtfzw=; b=mBImTJ2wO4OWlBOnN0E/AnB6wyvAT+SNpYAhAj24SjKT5jEoGFK1ahfYCVlMundX3P pEX06bdEAwmx2g8AbdTyOuRr+w8Fb2MlHuyy8lUNoOq4iW+qfSSUf6rlOdxmb3yjCFx9 ax6FhWAYy1dPVWWAt/GnpSOzJ42hUzspufu7mgxRKPxz6SJOubUf1k7EIXBCfdPGaBhq WjWMbep2owSJY+1yKL6PkUiV7fzf8yARWY877UskOEz6GnHx7hxb3hOIMEnbJZ3MnVhG ShCAwZp+jYy8xiphSPaAXBLTis6ncy3IFfrOi6BP2ruCS9noSf2/CS1Ykp+ikIT5leev 0Xjw== X-Gm-Message-State: ALQs6tCmwCdh1fYqEm385HwqraYeec22x2mXjmNBhO928aJkqsbMMpyw a3EA92EWm9B+uOgGXB2AwCC1ssDgzgo= X-Google-Smtp-Source: AIpwx49OOB+t++DutzrlP9cZmsVo5yo7U/IdIOLkgomDPlbZm5nohQTPYaGHBH2EXP5RPwWSN3qLww== X-Received: by 10.55.22.66 with SMTP id g63mr24583012qkh.294.1524529629405; Mon, 23 Apr 2018 17:27:09 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id e23-v6sm10951477qtp.6.2018.04.23.17.27.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 17:27:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Ted Lemon In-Reply-To: Date: Mon, 23 Apr 2018 20:27:07 -0400 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <88005194-4B09-4682-BE0A-0085EFF5A338@fugue.com> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] Goals of DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 00:27:12 -0000 On Apr 23, 2018, at 6:06 PM, Paul Hoffman = wrote: > Can you point to the part of the draft (which is in WG Last Call) = where it says that? If so, I promise to fix it because that is not an = intended goal. =46rom the WG Charter: The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., = operating system stub resolvers) and recursive resolvers.=20 =46rom the document's introduction: Two primary uses cases were considered during this protocol's development. They included preventing on-path devices from interfering with DNS operations and allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS) [CORS]. There are certainly other uses for this work. The first of these two use cases is to subvert the intentions of the = network operator. Providing confidentiality and connectivity is as well. = Of course, a less provoking way of saying what I said might be "to = prevent abuse by network operators," but it's kind of a toss-up. Anyway, if you think this is not the goal of the document, there may be = some kind of communication problem here to resolve... :) From nobody Mon Apr 23 17:43:17 2018 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 E630012DB6F for ; Mon, 23 Apr 2018 17:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 48SmHXCOCa68 for ; Mon, 23 Apr 2018 17:43:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B4A12DA6A for ; Mon, 23 Apr 2018 17:43:14 -0700 (PDT) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 23 Apr 2018 17:43:12 -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.1178.000; Mon, 23 Apr 2018 17:43:12 -0700 From: Paul Hoffman To: Ted Lemon CC: DoH WG Thread-Topic: [Ext] [Doh] Goals of DOH Thread-Index: AQHT22U5Jf4B9UlPbka9OJ7AkLTIlQ== Date: Tue, 24 Apr 2018 00:43:11 +0000 Message-ID: <622D86EB-C050-4E8C-8C4F-0BBE1515A706@icann.org> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> <88005194-4B09-4682-BE0A-0085EFF5A338@fugue.com> In-Reply-To: <88005194-4B09-4682-BE0A-0085EFF5A338@fugue.com> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Goals of DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 00:43:16 -0000 On Apr 23, 2018, at 5:27 PM, Ted Lemon wrote: >=20 > On Apr 23, 2018, at 6:06 PM, Paul Hoffman wrote: >> Can you point to the part of the draft (which is in WG Last Call) where = it says that? If so, I promise to fix it because that is not an intended go= al. >=20 > From the WG Charter: >=20 > The primary focus of this working group is to develop a mechanism that > provides confidentiality and connectivity between DNS clients (e.g., oper= ating > system stub resolvers) and recursive resolvers.=20 >=20 > From the document's introduction: >=20 > Two primary uses cases were considered during this protocol's > development. They included preventing on-path devices from > interfering with DNS operations and allowing web applications to > access DNS information via existing browser APIs in a safe way > consistent with Cross Origin Resource Sharing (CORS) [CORS]. There > are certainly other uses for this work. >=20 > The first of these two use cases is to subvert the intentions of the netw= ork operator. There are plenty of network operators who want to prevent on-path devices f= rom interfering with DNS operations, and there are plenty who don't want th= at.=20 > Providing confidentiality and connectivity is as well. Of course, a less= provoking way of saying what I said might be "to prevent abuse by network = operators," but it's kind of a toss-up. It's focusing on a subset of "network operators" and pretending that it is = the complete set. > Anyway, if you think this is not the goal of the document, there may be s= ome kind of communication problem here to resolve... :) So far, you're the only one to have had it, so hopefully this message fixes= it. --Paul Hoffman= From nobody Mon Apr 23 18:09:42 2018 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 57D8412DB71 for ; Mon, 23 Apr 2018 18:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Ubtx-FofbH-c for ; Mon, 23 Apr 2018 18:09:39 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 ABD14126FDC for ; Mon, 23 Apr 2018 18:09:39 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x22so271980qkb.12 for ; Mon, 23 Apr 2018 18:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZjbxhgC/gOKT4I84+PneLkslOlwE5aoUn5+kAMWt8tM=; b=OHQAT1SKifw5tqeoY2i8Wo+NC32/Gn3SDzFNd7KXL3la/wQXV9C6GMqiXnmPa2Xyck lS6XERHnal7FO2+D6UKWOpCr1PD6COM2J+jbFpabOwOOMVOtkPtNGAkUQB+VAN0RSDy8 fOSEdEtOPTNOUD+a86z+SgFfbeu3m77iCQ6irRdEg2WSuTfzDD/eXT7WOavtPG5SVLDc crvW8Jb+qSOXXh+gkSXjR/y+yosZMUNbJRCkUj6LhV+xT6cahUtadXOwG2nAA+I4JYGc o1X7G2KvYvuM2Lg4unEpAsSmMO/Y4BcxD68neKiqJLGoo98Z3TyPNlsj1ygNGzMsPaI6 /7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZjbxhgC/gOKT4I84+PneLkslOlwE5aoUn5+kAMWt8tM=; b=p4WGqyCgvxYozz6/oRdOQvNORhlWP4U4SMfjhc/CRgtfFWYOFNx7olE/l0R7qddghx 3eFb5AlbOKKWUJsRD4TsVvsBQ+hykSPZlpOyMLYoAg5qlbehGGh2naJOHDAi3hSwPCyz uKYOIn9yh6gtJ3fIdhFs6lIpujOQM2gQqDkfRm30+Q6H/X943fA58jt/I/ByzkfjUbBv MSVvxx4yV3rX6dyUy0H61UR2DfGbtpAn6VY7dkebCgjfLVJNx7dGGO47RvRtxKINXDUt n8hGOaczaVPiaooFCzGUYNUBTgnpno4fZ01/E1OstNNdnJ4E9VnojK4+4CJfZxWbXMkN F1ng== X-Gm-Message-State: ALQs6tB22fuNXdM8nOvKhD/HPmsogfCSVxjaV3DQ+57JZF3YuEeQcyjv VcQc1vTDcPAtuviGfRDkUXqL6g== X-Google-Smtp-Source: AB8JxZoKsOEzidBoJg1aFVZqNky22xxEkWoCxHOY9JBn3zFurEqMLZ1LQMG9hdqZ6jiRN3nyzuaJVw== X-Received: by 10.55.103.200 with SMTP id b191mr23852592qkc.229.1524532178693; Mon, 23 Apr 2018 18:09:38 -0700 (PDT) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id k184sm11059299qkc.11.2018.04.23.18.09.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 18:09:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Ted Lemon In-Reply-To: <622D86EB-C050-4E8C-8C4F-0BBE1515A706@icann.org> Date: Mon, 23 Apr 2018 21:09:36 -0400 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <2E34ABCC-A254-45C6-BCE7-D9C0DF70F793@fugue.com> References: <21B4DD30-46B0-4E63-833E-FDE66EF28F95@icann.org> <765e9e5a-9b8c-fa1c-85b5-da824807e609@o2.pl> <28678acd-f67d-7f95-273f-26ed1115d3ee@o2.pl> <75B0BB57-A222-4328-A155-E5C351DEB7CC@icann.org> <3457562c-5576-18ea-a764-d485d870b5ea@o2.pl> <46145a1e-99a9-405f-9f5c-4b85005feaf9@o2.pl> <302013A3-DA11-4398-A226-64939FC4DA46@icann.org> <978B235F-9700-43DB-833B-C1AA02438E52@bangj.com> <5B2F997F-E5DF-4A97-B73B-2EC699113898@fugue.com> <88005194-4B09-4682-BE0A-0085EFF5A338@fugue.com> <622D86EB-C050-4E8C-8C4F-0BBE1515A706@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Goals of DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 01:09:41 -0000 On Apr 23, 2018, at 8:43 PM, Paul Hoffman = wrote: >> Providing confidentiality and connectivity is as well. Of course, a = less provoking way of saying what I said might be "to prevent abuse by = network operators," but it's kind of a toss-up. >=20 > It's focusing on a subset of "network operators" and pretending that = it is the complete set. Argh. No. When you are examining a threat model, there is no = difference between "the network operator could be attacking me in a way = I can't detect" and "the network operator _is_ attacking me in a way I = can't detect." The point of what I was saying is not that network operators are evil. = Many of the things that they do to the DNS that DoH would prevent are = actually to the benefit of the average end user. The point also isn't that there is no use for DoH other than subverting = the intentions of operators. But very clearly, that is one of the things that it can do, and it is = very clearly stated in the charter as the primary goal. From nobody Mon Apr 30 00:24:24 2018 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 CC01612D87F for ; Mon, 30 Apr 2018 00:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bUa8s58nn1dI for ; Mon, 30 Apr 2018 00:24:20 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 F01BC126D3F for ; Mon, 30 Apr 2018 00:24:19 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id l22-v6so8513265otj.0 for ; Mon, 30 Apr 2018 00:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UjNwXaQT/vf0mbqwybs8EtCBekypjaUsfMpc8cZTULc=; b=nWbe3YrLFhBEx5db3B/Z3Okl1biDSG33/lmIQii7urO19nr9p9UGO8ZZ28e9T9i51a LbDbqcDJoB7qvEMXCgRXex/EnBZnl0fBZCk/2E6czvCs8nVPtHgoER0+N6aT/BlfrYIz bF3aAV0Wz1R90CtCzkSEhNuSpQx3PIZi8TnPDouH7r86OKtUlJuAiwch8e1wvKL3X0Mh P3dRZ8q5Q9ZNFT7/LYxgHAWCQZnjTVJIO/MfVoiUa4S2qPiEkugwbZU0wqErdqPsRUzF Gx6azhp+Cica0u13ErR6BEI1aAmGnvOhdOkW6ptWhIMPA6SA6lRRUlsReyeNfxt0rC1V 8W+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UjNwXaQT/vf0mbqwybs8EtCBekypjaUsfMpc8cZTULc=; b=HTeMLeIDo1igCe8zq7WC7UZnWupwt11Vr4F24157LTthJOq+a7yZT0dIkY4J3djaT0 1BpGfUf4bVI/59Uzlc/RtDsP7DNzpgvC3dnNZJBR7OX4ix41Xkz4YboxEj5nC5SVcaxg vfTMJW9fPYENxfZCQSrA+7x3/+CGWTK/2h0+Ibmq8bF48nLcnY+EDx9jBSSeEPN5Azi+ SkZJqntHh8/brpUiof/oy6HBk5dgxgMEMzrJdI/z1pD1k48S1QqQ8D/hyaZ3kFytuyEZ KgzGM0hBirprzNhRT3UShmBzQVKJd/kfduwjzu6Dq6Ek6NUB+JHUGrWzL2irT19TctDQ iTiw== X-Gm-Message-State: ALQs6tDFrJDWoHpeLHZYSm6lL3pvV+cchYjZWkGJZb1zka50UHKfjXEv vE61V/wX4AUTDZe6ygmhMAOHtaxVaC9ZVFQgjg1f9jNQ X-Google-Smtp-Source: AB8JxZoT6nZwkPGUs3+btTLnOlfYIMspE1YItoYlWQazHV3gc50tMju8J2W1JTcdY/reoNFbmqWS1SMtzV3rGO1rgB4= X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr7970737otg.241.1525073059265; Mon, 30 Apr 2018 00:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 00:24:18 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 30 Apr 2018 17:24:18 +1000 Message-ID: To: Ben Schwartz Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 07:24:22 -0000 Hmm, it's quiet. I don't know if that means that we all think that this is done or not. I've reviewed the draft and I think that it's almost there. I have three issues to raise with the group, shown below. The proceeds of that review can be seen on GitHub in the form of issues and pull requests. The pull requests are mostly trivial editorial matters and can be resolved on GitHub. Truncated responses https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/161 Do we still need Section 3? https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/148 Does the HTTP freshness lifetime need to match the TTL? https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 I'm happy to start threads on each of these for discussion. On Thu, Apr 19, 2018 at 5:07 AM, Ben Schwartz wrote: > All, > This message starts a two week WG Last Call on advancing: > > Title : DNS Queries over HTTPS > Author : Paul Hoffman, Patrick McManus > Filename : draft-ietf-doh-dns-over-https-07 > Pages : 17 > Date : 2018-04-11 > > as a Standards Track document. The last call will end on May 2, 2018. > All substantive comments are to be sent to the doh@ietf.org list for > discussions. Editorial comments can be sent to the document editor. > > You can find the latest version of the document here: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 > > Regards, > Ben & tale > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > From nobody Mon Apr 30 10:59:57 2018 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 D6B2C124239 for ; Mon, 30 Apr 2018 10:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 rZViELVIGUyu for ; Mon, 30 Apr 2018 10:59:51 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 2CA281201F2 for ; Mon, 30 Apr 2018 10:59:51 -0700 (PDT) Received: from [2a02:8010:6126:0:f503:bf0f:36e5:ad64] (port=56899) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fDD5X-0004Aa-I7; Mon, 30 Apr 2018 18:59:49 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_3121FA6E-9A6F-42ED-8669-1A4A00458348" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Apr 2018 18:59:44 +0100 References: Cc: DoH WG To: Ben Schwartz Message-Id: X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:59:55 -0000 --Apple-Mail=_3121FA6E-9A6F-42ED-8669-1A4A00458348 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All,=20 TL;DR but - I=E2=80=99ve read this version of the draft and have a few = comments. I=E2=80=99ve listed them here for discussion but can create = GitHub issues if that is the preferred mechanism (not sure?). 1) Section 2: Terminology. The phrase =E2=80=98regular DNS protocol=E2=80= =99 is used here but the terms =E2=80=98traditional DNS/traditional DNS = clients/traditional DNS nameserver=E2=80=99 are used in Sections 1 and = 9. It is not clear to me if these terms all mean the same thing, that = being one of a) only DNS over UDP/TCP=20 b) DNS over any of UDP/TCP or (D)TLS with any usage profile? c) DNS over any of UDP/TCP or (D)TLS with only an Opportunistic usage = profile? or are they are supposed to mean different things?=20 Section 1: Suggest s/transport suitable for both traditional DNS = clients/transport suitable for both existing DNS clients/ Section 2: Suggest s/differentiate it from a "DNS server" (one that = uses the regular DNS protocol). /differentiate it from a "DNS server=E2=80= =9D (one that only provides DNS service over one or more of the other = transport protocols standardised for DNS). / I fear the definition of a client here is possibly too simplistic in the = sense that it isn=E2=80=99t clear if it supports only DOH or other = transports (also see later)=E2=80=A6 2) Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. = Section 6 specifically says=20 =E2=80=9CDNS API clients using the DNS wire format MAY have one or more = EDNS options [RFC6891] in the request.=E2=80=9D=20 In a similar manner to the problem with truncation of responses, there = are 2 EDNS options I can think of that are transport specific, but how = to handle them isn=E2=80=99t described in this draft i.e. - EDNS(0) Padding (When RFC7830 was written only DNS-over-TLS was = standardised, but the text doesn=E2=80=99t restrict it to that it simply = says =E2=80=9CTherefore, implementations MUST NOT use this option if the = DNS transport is not encrypted.=E2=80=9D). Alexander Mayrhofer = requested a note be added about this option in his review of the -04 = draft. - EDNS(0) Keepalive (RFC7828). 3) Section 8: I=E2=80=99d suggest this is re-written somewhat to be = clearer that DOH and DNSSEC are independent mechanisms (by using similar = language to RFC7858), and to remove any confusing overload of the word = =E2=80=98trust=E2=80=99 in this document: OLD: =E2=80=9CThe HTTPS connection provides transport security for the = interaction between the DNS API server and client, but does not inherently ensure the authenticity of DNS data. A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. This capability might be affected by the response media type.=E2=80=9D SUGGESTED: =E2=80=9CThe HTTPS connection provides transport security for the = interaction between the DNS API server and client, but does not provide the _response integrity_ of DNS data provided by DNSSEC. DNSSEC and DOH=20= are independent and fully compatible protocols, each solving = different problems. =20 The use of one does not diminish the need nor the usefulness of the = other. The unique aspect of DOH is that the choice of a client to either = perform full DNSSEC validation of answers or to treat answers from a DNS API = server as=20 DNSSEC authenticated may be affected by the response media type." 4) Section 8: With regard to trusted/untrusted servers I would suggest = at least a small restructure for clarity. At the moment the first = discussion of the client trust model is in section 5.3 =E2=80=98Server = Push=E2=80=99. I would suggest adding a section before this (possibly after section 3) = called something like =E2=80=99Trust model for client queries=E2=80=99 = with the following (combining text from section 5.3 and 8): =E2=80=9CBefore using DOH response data for DNS resolution, the client = MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a client MUST only trust a DNS API server that is configured as trustworthy. A client MUST NOT trust a DNS API=20= server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party.=20 This specification does not extend DNS resolution privileges=20 to URIs that are not recognized by the client as trusted DNS API = servers.=20 As such, use of untrusted servers is out of scope of this document=20 (however Section 8 discusses some of the security risks of using = them).=E2=80=9D Section 5.3 then becomes simply: =E2=80=9CFor HTTP requests initiated by the DNS API client trust in the = DOH response=20 data is implicit in the selection of URI. For HTTP server push = ([RFC7540] Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request. =E2=80=9C=20 And Section 8 can just say: =E2=80=9CA server that is acting both as a normal web server and a DNS = API server is in a position to choose which DNS names it forces a client to resolve (through its web service) and also be the one to answer those queries (through its DNS API service). An untrusted DNS API=20 server can thus easily cause damage by poisoning a client's cache with names that the DNS API server chooses to poison. As stated in = section X, a client=20 MUST only trust a DNS API server that is configured as = trustworthy.=E2=80=9D 5) Section 8:=20 "If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client.=E2=80=9D This text brings up the biggest issue I have with the document, which is = that I would like to request that it replaces the above text with a = section that clarifies how DOH can be used in the context of a privacy = usage profile (see both RFC7858 and RFC8310 for descriptions of Strict = vs Opportunistic usage profiles for DNS-over-(D)TLS). To be clear: in = these profiles only configured servers are used (no discovery is = involved). I=E2=80=99m happy to help with text here if there is = consensus that this is in scope and beneficial to the document.=20 The big, big gain I see here is for applications such as Stubby which = would like to have a standard way to add DOH as a transport option = alongside the existing use of DNS-over-TLS when using those profiles. = In this scenario Stubby would be the =E2=80=98client=E2=80=99 in the = text above which can use either a DNS API client or a =E2=80=98traditional= ' DNS client. =20 (As an aside, I note that the above is the first and only mention of the = word =E2=80=98privacy' in the document and this document does not = currently describe the specific privacy benefits of this specification = compared to =E2=80=99other mechanisms=E2=80=99.) Two ambiguities with the current text are: - RFC8310 says a DNS client should only use a single privacy usage = profile when resolving a specific query (precisely to avoid the problem = mentioned above) but this text seems to contradict that.=20 - while it is heavily implied the document isn=E2=80=99t actually = crystal clear on whether a configured =E2=80=98trusted=E2=80=99 server = can be used if authentication of the certificate fails.=20 6) Section 9:=20 =E2=80=9CA DNS API client may face a similar bootstrapping problem when = the HTTP request needs to resolve the hostname portion of the DNS URI." =E2=80=9C...or resolving the DNS API server's hostname via traditional = DNS =E2=80=9C DNS-over(D)TLS using only a configured authentication domain name shares = many of the discovery issues that DoH has. Paragraph 4 of Section 9 = overlaps with the discussion of =E2=80=98meta-queries=E2=80=99 as = already described in more detail in RFC8310 and it would be helpful if = the language could be aligned or if RFC8310 was at least referenced = here. One of the issues discussed in that document is the potential for = denial-of-service if these meta-queries are subject to attack, which = seems worthy of note. Again, happy to help with text here. Regards Sara.=20 > Begin forwarded message: >=20 > From: Ben Schwartz > > Subject: [Doh] WGLC on draft-ietf-doh-dns-over-https > Date: 18 April 2018 at 20:07:35 BST > To: DoH WG > >=20 > All, > This message starts a two week WG Last Call on advancing: >=20 > Title : DNS Queries over HTTPS > Author : Paul Hoffman, Patrick McManus > Filename : draft-ietf-doh-dns-over-https-07 > Pages : 17 > Date : 2018-04-11 >=20 > as a Standards Track document. The last call will end on May 2, 2018. > All substantive comments are to be sent to the doh@ietf.org = list for > discussions. Editorial comments can be sent to the document editor. >=20 > You can find the latest version of the document here: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 = >=20 > Regards, > Ben & tale > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --Apple-Mail=_3121FA6E-9A6F-42ED-8669-1A4A00458348 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = All, 

TL;DR but - I=E2=80=99ve read this = version of the draft and have a few comments. I=E2=80=99ve listed them = here for discussion but can create GitHub issues if that is the = preferred mechanism (not sure?).


1)  Section 2: = Terminology. The phrase =E2=80=98regular DNS protocol=E2=80=99 is used = here but the terms =E2=80=98traditional DNS/traditional DNS = clients/traditional DNS nameserver=E2=80=99 = are used in Sections 1 and 9. It is not clear to me = if these terms all mean the same thing, that being one of
a) only DNS over UDP/TCP 
b) DNS = over any of UDP/TCP or (D)TLS with any usage profile?
c) DNS over any of UDP/TCP or (D)TLS with only an = Opportunistic usage profile?
or are they are = supposed to mean different things? 

Section 1: Suggest   s/transport = suitable for both traditional DNS clients/transport suitable for both = existing DNS clients/

Section 2: Suggest   s/differentiate = it from a "DNS server" (one that uses the regular DNS = protocol). /differentiate it from a "DNS server=E2=80=9D (one that only = provides DNS service over one or more of the other transport protocols = standardised for DNS). /

I fear the definition of a client here is possibly too = simplistic in the sense that it isn=E2=80=99t clear if it supports only = DOH or other transports (also see later)=E2=80=A6

2) = Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. Section 6 = specifically says 
=E2=80=9CDNS API clients = using the DNS wire format MAY have one or more EDNS options [RFC6891] in = the request.=E2=80=9D 

In a similar manner to the problem with truncation of = responses, there are 2 EDNS options I can think of that are transport = specific, but how to handle them isn=E2=80=99t described in this draft = i.e.
- EDNS(0) Padding (When RFC7830 was written = only DNS-over-TLS was standardised, but the text doesn=E2=80=99t = restrict it to that it simply says =E2=80=9CTherefore, implementations = MUST NOT use this option if the DNS transport is not encrypted.=E2=80=9D).=  Alexander Mayrhofer requested a note be added about this option = in his review of the -04 draft.
- EDNS(0) Keepalive = (RFC7828).

3) = Section 8: I=E2=80=99d suggest this is re-written somewhat to be clearer = that DOH and DNSSEC are independent mechanisms (by using similar = language to RFC7858), and to remove any confusing overload of the word = =E2=80=98trust=E2=80=99 in this document:

OLD:

=E2=80=9CThe HTTPS connection provides = transport security for the interaction
  =  between the DNS API server and client, but does not inherently = ensure
   the authenticity of DNS data. =  A DNS API client may also perform full
  =  DNSSEC validation of answers received from a DNS API server or it = may
   choose to trust answers from a = particular DNS API server, much as a
  =  DNS client might choose to trust answers from its recursive = DNS
   resolver.  This capability = might be affected by the response media
  =  type.=E2=80=9D

SUGGESTED:

=E2=80=9CThe HTTPS connection provides = transport security for the interaction
  =  between the DNS API server and client, but does not provide = the
   _response integrity_  of DNS = data provided by DNSSEC.  DNSSEC and DOH 
   are independent and fully compatible protocols, = each solving different problems.  
  =  The use of one does not diminish the need nor the usefulness of = the other.
   The unique aspect of DOH is = that the choice of a client to either perform full
   DNSSEC validation of answers or to treat answers = from a DNS API server as 
   DNSSEC = authenticated may be affected by the response media = type."

4) Section 8: With regard to = trusted/untrusted servers I would suggest at least a small restructure = for clarity. At the moment the first discussion of the client trust = model is in section 5.3 =E2=80=98Server Push=E2=80=99.

I would suggest adding a = section before this (possibly after section 3) called something like = =E2=80=99Trust model for client queries=E2=80=99 with the following = (combining text from section 5.3 and 8):

  =E2=80=9CBefore using DOH = response data for DNS resolution, the client MUST
   establish that the HTTP request URI is a trusted = service for the DOH
   query, in other = words, a client MUST only trust a DNS API server
   that is configured as trustworthy. A client MUST = NOT trust a DNS API 
   server = simply because it was discovered, or
   because the = client was told to trust the DNS API server by an
   untrusted party. 

   This specification does = not extend DNS resolution privileges 
  =  to URIs that are not recognized by the client as trusted DNS API = servers. 
   As such, use of = untrusted servers is out of scope of this document 
   (however Section 8 discusses some of the = security risks of using them).=E2=80=9D


Section 5.3 then becomes simply:

=E2=80=9CFor HTTP requests initiated by = the DNS API client trust in the DOH response 
data is implicit in the selection of URI. For HTTP server = push ([RFC7540] Section 8.2)
extra care must be = taken to ensure that the pushed URI
is one that the = client would have directed the same query to if the
client had initiated the request. =E2=80=9C 

And Section 8 can just = say:

=E2=80=9CA = server that is acting both as a normal web server and a DNS = API
   server is in a position to choose = which DNS names it forces a client
   to = resolve (through its web service) and also be the one to = answer
   those queries (through its DNS = API service). An untrusted DNS API 
  =  server can thus easily cause damage by poisoning a client's = cache
   with names that the DNS API server = chooses to poison.  As stated in section X, a = client 
   MUST only trust a DNS API = server that is configured as trustworthy.=E2=80=9D


5) Section = 8: 

  =  "If a client of this protocol encounters an HTTP
   error after sending a DNS query, and then falls = back to a different
   DNS retrieval = mechanism, doing so can weaken the privacy and
 =  authenticity expected by the user of the client.=E2=80=9D

This = text brings up the biggest issue I have with the document, which is that = I would like to request that it replaces the above text with a section = that clarifies how DOH can be used in the context of a privacy usage = profile (see both RFC7858 and RFC8310 for descriptions of Strict vs = Opportunistic usage profiles for DNS-over-(D)TLS).  To be clear: in = these profiles only configured servers are used (no discovery is = involved). I=E2=80=99m happy to help with text here if there is = consensus that this is in scope and beneficial to the = document. 

The big, big gain I see here is for applications such as = Stubby which would like to have a standard way to add DOH as a transport = option alongside the existing use of DNS-over-TLS when using those = profiles.  In this scenario Stubby would be the =E2=80=98client=E2=80= =99 in the text above which can use either a DNS API client or a = =E2=80=98traditional' DNS client.  

(As an aside, I note that the above is = the first and only mention of the word =E2=80=98privacy' in the document = and this document does not currently describe the specific privacy = benefits of this specification compared to =E2=80=99other = mechanisms=E2=80=99.)

Two ambiguities with the current text are:
- RFC8310 says a DNS client should only use a single privacy = usage profile when resolving a specific query (precisely to avoid the = problem mentioned above) but this text seems to contradict = that. 
- while it is heavily implied the = document isn=E2=80=99t actually crystal clear on whether a configured = =E2=80=98trusted=E2=80=99 server can be used if authentication of the = certificate fails. 


6) Section 9: 

=E2=80=9CA DNS API = client may face a similar bootstrapping problem when the
 HTTP request needs to resolve the hostname portion of = the DNS URI."

=E2=80=9C...or resolving the DNS API server's hostname via = traditional DNS =E2=80=9C

DNS-over(D)TLS using only a configured = authentication domain name shares many of the discovery issues that DoH = has. Paragraph 4 of Section 9 overlaps with the discussion of = =E2=80=98meta-queries=E2=80=99 as already described in more detail in = RFC8310 and it would be helpful if the language could be aligned or if = RFC8310 was at least referenced here. One of the issues discussed in = that document is the potential for denial-of-service if these = meta-queries are subject to attack, which seems worthy of note. Again, = happy to help with text here.

Regards

Sara. 




Begin forwarded = message:

From: Ben Schwartz <bemasc@google.com>
Subject: [Doh] WGLC on draft-ietf-doh-dns-over-https
Date: 18 April 2018 at 20:07:35 BST
To: DoH WG <doh@ietf.org>

All,
This message starts a two week WG = Last Call on advancing:

  Title      =      : DNS Queries over HTTPS
  Author      =     : Paul Hoffman, Patrick McManus
  Filename      =   : draft-ietf-doh-dns-over-https-07
  Pages      =      : 17
  Date      =       : 2018-04-11

as a Standards Track document. The = last call will end on May = 2, 2018.
All substantive comments are to be = sent to the doh@ietf.org list = for
discussions. Editorial comments can = be sent to the document editor.

You can find the latest version of the = document here:
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07

Regards,
Ben & tale
_______________________________________________
Doh = mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


= --Apple-Mail=_3121FA6E-9A6F-42ED-8669-1A4A00458348-- From nobody Mon Apr 30 20:22:47 2018 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 010E612E741 for ; Mon, 30 Apr 2018 20:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wgq-4EgIenUH for ; Mon, 30 Apr 2018 20:22:44 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.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 29C05126CF6 for ; Mon, 30 Apr 2018 20:22: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.1178.4; Mon, 30 Apr 2018 20:22: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.1178.000; Mon, 30 Apr 2018 20:22:41 -0700 From: Paul Hoffman To: Sara Dickinson CC: DoH WG Thread-Topic: [Ext] [Doh] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4PuppTVfCOcsY0mFJGQqcUqHOg== Date: Tue, 1 May 2018 03:22:40 +0000 Message-ID: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> References: In-Reply-To: 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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 03:22:46 -0000 VGhhbmtzLCBTYXJhISBJIGhhdmUgb3BlbmVkIHB1bGwgcmVxdWVzdHMgZm9yICMxLCAjMywgYW5k ICM0LiBPZiB0aGUgcmVtYWluaW5nOg0KDQo+IDIpIFNlY3Rpb25zIDMsIDQuMiBhbmQgNiBtZW50 aW9uIHRoZSBwcmVzZW5jZSBvZiBFRE5TKDApIG9wdGlvbnMuIFNlY3Rpb24gNiBzcGVjaWZpY2Fs bHkgc2F5cyANCj4g4oCcRE5TIEFQSSBjbGllbnRzIHVzaW5nIHRoZSBETlMgd2lyZSBmb3JtYXQg TUFZIGhhdmUgb25lIG9yIG1vcmUgRUROUyBvcHRpb25zIFtSRkM2ODkxXSBpbiB0aGUgcmVxdWVz dC7igJ0gDQo+IA0KPiBJbiBhIHNpbWlsYXIgbWFubmVyIHRvIHRoZSBwcm9ibGVtIHdpdGggdHJ1 bmNhdGlvbiBvZiByZXNwb25zZXMsIHRoZXJlIGFyZSAyIEVETlMgb3B0aW9ucyBJIGNhbiB0aGlu ayBvZiB0aGF0IGFyZSB0cmFuc3BvcnQgc3BlY2lmaWMsIGJ1dCBob3cgdG8gaGFuZGxlIHRoZW0g aXNu4oCZdCBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBpLmUuDQo+IC0gRUROUygwKSBQYWRkaW5n IChXaGVuIFJGQzc4MzAgd2FzIHdyaXR0ZW4gb25seSBETlMtb3Zlci1UTFMgd2FzIHN0YW5kYXJk aXNlZCwgYnV0IHRoZSB0ZXh0IGRvZXNu4oCZdCByZXN0cmljdCBpdCB0byB0aGF0IGl0IHNpbXBs eSBzYXlzIOKAnFRoZXJlZm9yZSwgaW1wbGVtZW50YXRpb25zIE1VU1QgTk9UIHVzZSB0aGlzIG9w dGlvbiBpZiB0aGUgRE5TIHRyYW5zcG9ydCBpcyBub3QgZW5jcnlwdGVkLuKAnSkuICBBbGV4YW5k ZXIgTWF5cmhvZmVyIHJlcXVlc3RlZCBhIG5vdGUgYmUgYWRkZWQgYWJvdXQgdGhpcyBvcHRpb24g aW4gaGlzIHJldmlldyBvZiB0aGUgLTA0IGRyYWZ0Lg0KPiAtIEVETlMoMCkgS2VlcGFsaXZlIChS RkM3ODI4KS4NCg0KSSdtIG5vdCBzdXJlIHdoeSB0aGVyZSBhcmUgInByb2JsZW1zIiB3aXRoIHRo ZXNlLiBGb3IgcGFkZGluZywgdGhlIHNlcnZlciBjYW4gdXNlIGl0IG9yIG5vdC4gRm9yIGtlZXBh bGl2ZSwgaXQgbWFrZXMgbm8gc2Vuc2UgZm9yIGl0IHRvIHN1cHBvcnQgaXQuIEp1c3QgbGlrZSBh bnkgdHJhZGl0aW9uYWwgRE5TIHNlcnZlciwgYSBET0ggc2VydmVyIGhhcyB0byB1bmRlcnN0YW5k IGl0cyBjb250ZXh0IHdoZW4gZGVjaWRpbmcgaG93IHRvIGFuc3dlciBxdWVyaWVzIHdpdGggRURO UyBvcHRpb25zLg0KDQoNCj4gNSkgU2VjdGlvbiA4OiANCj4gDQo+ICAgICJJZiBhIGNsaWVudCBv ZiB0aGlzIHByb3RvY29sIGVuY291bnRlcnMgYW4gSFRUUA0KPiAgICBlcnJvciBhZnRlciBzZW5k aW5nIGEgRE5TIHF1ZXJ5LCBhbmQgdGhlbiBmYWxscyBiYWNrIHRvIGEgZGlmZmVyZW50DQo+ICAg IEROUyByZXRyaWV2YWwgbWVjaGFuaXNtLCBkb2luZyBzbyBjYW4gd2Vha2VuIHRoZSBwcml2YWN5 IGFuZA0KPiAgICBhdXRoZW50aWNpdHkgZXhwZWN0ZWQgYnkgdGhlIHVzZXIgb2YgdGhlIGNsaWVu dC7igJ0NCj4gDQo+IFRoaXMgdGV4dCBicmluZ3MgdXAgdGhlIGJpZ2dlc3QgaXNzdWUgSSBoYXZl IHdpdGggdGhlIGRvY3VtZW50LCB3aGljaCBpcyB0aGF0IEkgd291bGQgbGlrZSB0byByZXF1ZXN0 IHRoYXQgaXQgcmVwbGFjZXMgdGhlIGFib3ZlIHRleHQgd2l0aCBhIHNlY3Rpb24gdGhhdCBjbGFy aWZpZXMgaG93IERPSCBjYW4gYmUgdXNlZCBpbiB0aGUgY29udGV4dCBvZiBhIHByaXZhY3kgdXNh Z2UgcHJvZmlsZSAoc2VlIGJvdGggUkZDNzg1OCBhbmQgUkZDODMxMCBmb3IgZGVzY3JpcHRpb25z IG9mIFN0cmljdCB2cyBPcHBvcnR1bmlzdGljIHVzYWdlIHByb2ZpbGVzIGZvciBETlMtb3Zlci0o RClUTFMpLiAgVG8gYmUgY2xlYXI6IGluIHRoZXNlIHByb2ZpbGVzIG9ubHkgY29uZmlndXJlZCBz ZXJ2ZXJzIGFyZSB1c2VkIChubyBkaXNjb3ZlcnkgaXMgaW52b2x2ZWQpLiBJ4oCZbSBoYXBweSB0 byBoZWxwIHdpdGggdGV4dCBoZXJlIGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IHRoaXMgaXMg aW4gc2NvcGUgYW5kIGJlbmVmaWNpYWwgdG8gdGhlIGRvY3VtZW50LiANCj4gDQo+IFRoZSBiaWcs IGJpZyBnYWluIEkgc2VlIGhlcmUgaXMgZm9yIGFwcGxpY2F0aW9ucyBzdWNoIGFzIFN0dWJieSB3 aGljaCB3b3VsZCBsaWtlIHRvIGhhdmUgYSBzdGFuZGFyZCB3YXkgdG8gYWRkIERPSCBhcyBhIHRy YW5zcG9ydCBvcHRpb24gYWxvbmdzaWRlIHRoZSBleGlzdGluZyB1c2Ugb2YgRE5TLW92ZXItVExT IHdoZW4gdXNpbmcgdGhvc2UgcHJvZmlsZXMuICBJbiB0aGlzIHNjZW5hcmlvIFN0dWJieSB3b3Vs ZCBiZSB0aGUg4oCYY2xpZW504oCZIGluIHRoZSB0ZXh0IGFib3ZlIHdoaWNoIGNhbiB1c2UgZWl0 aGVyIGEgRE5TIEFQSSBjbGllbnQgb3IgYSDigJh0cmFkaXRpb25hbCcgRE5TIGNsaWVudC4gIA0K PiANCj4gKEFzIGFuIGFzaWRlLCBJIG5vdGUgdGhhdCB0aGUgYWJvdmUgaXMgdGhlIGZpcnN0IGFu ZCBvbmx5IG1lbnRpb24gb2YgdGhlIHdvcmQg4oCYcHJpdmFjeScgaW4gdGhlIGRvY3VtZW50IGFu ZCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGN1cnJlbnRseSBkZXNjcmliZSB0aGUgc3BlY2lmaWMg cHJpdmFjeSBiZW5lZml0cyBvZiB0aGlzIHNwZWNpZmljYXRpb24gY29tcGFyZWQgdG8g4oCZb3Ro ZXIgbWVjaGFuaXNtc+KAmS4pDQo+IA0KPiBUd28gYW1iaWd1aXRpZXMgd2l0aCB0aGUgY3VycmVu dCB0ZXh0IGFyZToNCj4gLSBSRkM4MzEwIHNheXMgYSBETlMgY2xpZW50IHNob3VsZCBvbmx5IHVz ZSBhIHNpbmdsZSBwcml2YWN5IHVzYWdlIHByb2ZpbGUgd2hlbiByZXNvbHZpbmcgYSBzcGVjaWZp YyBxdWVyeSAocHJlY2lzZWx5IHRvIGF2b2lkIHRoZSBwcm9ibGVtIG1lbnRpb25lZCBhYm92ZSkg YnV0IHRoaXMgdGV4dCBzZWVtcyB0byBjb250cmFkaWN0IHRoYXQuIA0KPiAtIHdoaWxlIGl0IGlz IGhlYXZpbHkgaW1wbGllZCB0aGUgZG9jdW1lbnQgaXNu4oCZdCBhY3R1YWxseSBjcnlzdGFsIGNs ZWFyIG9uIHdoZXRoZXIgYSBjb25maWd1cmVkIOKAmHRydXN0ZWTigJkgc2VydmVyIGNhbiBiZSB1 c2VkIGlmIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjZXJ0aWZpY2F0ZSBmYWlscy4gDQoNClBsZWFz ZSwgbm8uIE9yIGF0IGxlYXN0LCBub3QgaGVyZS4gVGhlIGNvbXBsaWNhdGVkIEROUy1vdmVyLVRM UyB1c2FnZSBwb2xpY2llcyBhcmUgb25lIG9mIHRoZSByZWFzb25zIHdlIGhhdmUgc28gbGl0dGxl IGltcGxlbWVudGF0aW9uIG9mIEROUy1vdmVyLVRMUy4gKE90aGVycyBtYXkgZGlzYWdyZWUgd2l0 aCB0aGlzIHN0YXRlbWVudC4pDQoNCkl0IHdvdWxkIGJlIGxvdmVseSBpZiBTdHViYnkgY291bGQg YWRkIERPSCBhcyBhIHRyYW5zcG9ydCB0aGF0IGlzIHBhcmFsbGVsIHRvIEROUy1vdmVyLVRMUywg YW5kIGZvciB0aGF0IHRoZXJlIGhhcyB0byBiZSBzb21lIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9m IHByaXZhY3kgYW5kIHRydXN0IGxldmVscy4gRHVwbGljYXRpbmcgdG8gdHdpc3R5IG1hemVzIGZy b20gRE5TLW92ZXItVExTIHVzYWdlIHBvbGljaWVzIGlzIG5vdCBnb2luZyB0byBoZWxwLiBJbnN0 ZWFkLCBhIG5ldyBkb2N1bWVudCB0aGF0IGNvdmVycyBETlMtb3Zlci1UTFMsIERPSCwgYW5kIHRo ZSBsaWtlbHkgZnV0dXJlIEROUy1vdmVyLVFVSUMgbmVlZHMgdG8gZGVhbCB3aXRoIHRoaXMsIGFu ZCBtb3JlIGNsZWFybHkuDQoNCkknbSBhYm91dCB0byBwcm9wb3NlIGEgbm9uLVdHLWZvcm1pbmcg Qm9GIGluIE1vbnRyw6lhbCBmb3IgZm9sa3Mgd2hvIHdhbnQgdG8gdGFsayBhYm91dCBzdWNoIHdv cmsuIEJ1dCBJIGRvbid0IHRoaW5rIGl0IHNob3VsZCBzdG9wIERPSDsgaWYgaXQgZG9lcywgd2Un cmUgcHJvYmFibHkgdGFsa2luZyBhdCBsZWFzdCBzaXggbW9udGhzIHRvIGhvcGUgZm9yIGNvbnNl bnN1cy4gKEFuZCB0aGUgY29uc2Vuc3VzIG9uIHBvbGljeSBpbiBEUFJJVkUgd2FzIG1vcmUgZnJv bSBleGhhdXN0aW9uIHRoYW4gYWdyZWVtZW50LikNCg0KPiA2KSBTZWN0aW9uIDk6IA0KPiANCj4g 4oCcQSBETlMgQVBJIGNsaWVudCBtYXkgZmFjZSBhIHNpbWlsYXIgYm9vdHN0cmFwcGluZyBwcm9i bGVtIHdoZW4gdGhlDQo+ICBIVFRQIHJlcXVlc3QgbmVlZHMgdG8gcmVzb2x2ZSB0aGUgaG9zdG5h bWUgcG9ydGlvbiBvZiB0aGUgRE5TIFVSSS4iDQo+IA0KPiDigJwuLi5vciByZXNvbHZpbmcgdGhl IEROUyBBUEkgc2VydmVyJ3MgaG9zdG5hbWUgdmlhIHRyYWRpdGlvbmFsIEROUyDigJwNCj4gDQo+ IEROUy1vdmVyKEQpVExTIHVzaW5nIG9ubHkgYSBjb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uIGRv bWFpbiBuYW1lIHNoYXJlcyBtYW55IG9mIHRoZSBkaXNjb3ZlcnkgaXNzdWVzIHRoYXQgRG9IIGhh cy4gUGFyYWdyYXBoIDQgb2YgU2VjdGlvbiA5IG92ZXJsYXBzIHdpdGggdGhlIGRpc2N1c3Npb24g b2Yg4oCYbWV0YS1xdWVyaWVz4oCZIGFzIGFscmVhZHkgZGVzY3JpYmVkIGluIG1vcmUgZGV0YWls IGluIFJGQzgzMTAgYW5kIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgdGhlIGxhbmd1YWdlIGNvdWxk IGJlIGFsaWduZWQgb3IgaWYgUkZDODMxMCB3YXMgYXQgbGVhc3QgcmVmZXJlbmNlZCBoZXJlLiBP bmUgb2YgdGhlIGlzc3VlcyBkaXNjdXNzZWQgaW4gdGhhdCBkb2N1bWVudCBpcyB0aGUgcG90ZW50 aWFsIGZvciBkZW5pYWwtb2Ytc2VydmljZSBpZiB0aGVzZSBtZXRhLXF1ZXJpZXMgYXJlIHN1Ympl Y3QgdG8gYXR0YWNrLCB3aGljaCBzZWVtcyB3b3J0aHkgb2Ygbm90ZS4gQWdhaW4sIGhhcHB5IHRv IGhlbHAgd2l0aCB0ZXh0IGhlcmUuDQoNClRoZSBCb0Ygd291bGQgY292ZXIgdGhlc2UgYXMgd2Vs bC4gRE9IIGhhcyBzaW1pbGFyIGlzc3VlcyBhcyBETlMtb3Zlci1UTFMgaGFzIGhlcmUuDQoNCi0t UGF1bCBIb2ZmbWFuDQoNCg== From nobody Mon Apr 30 22:04:56 2018 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 B7FA912E86E for ; Mon, 30 Apr 2018 22:04:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 FsWagwdCeNTC for ; Mon, 30 Apr 2018 22:04:53 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 046C312E880 for ; Mon, 30 Apr 2018 22:04:53 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id l12-v6so11993615oth.6 for ; Mon, 30 Apr 2018 22:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uOeOVE74JWHEhxNRbn0posCc2e1qKJ9KMJYM0589eD4=; b=e1H7XH40YosTkAvKhpUO2DonSccvvnedBOHsgg0F2aoJQm8rolMIV0te5EfVTvpFyD LVq7UJDIE3MStxuW3uRtiHgHHifXWh5gV2kwp9xVrpFaX/0fgk8/LvsgjyArpuKv26vu ib4bA38emjV6vl8kar0WpAyM4prmDtBYKVK40UL/sMYGe6d8dC4nPRWW0/pK1h9wN8Ol LzoAuJZd1jGEZ24E7MjBQZUPWHjvQr/B6MJ9UjM/pdLTS1LAGnJ8b3JbTP4I6AoJv9I6 rwXCKyYAmt9IC4ULAnbCd7fS3Bos8i7BnGla7a/ZjvJI2k/whT5UyuYnkN9tCo5TOG5D CUCA== 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=uOeOVE74JWHEhxNRbn0posCc2e1qKJ9KMJYM0589eD4=; b=aNvVqnkHC5WT6f3llZAe2RBX2KgeysLLIvcU8VnHLM77XdbRvY0A6wdLvzROPMb6+9 f9n4J+jS/bkWRc7i+9HeYlM0ciW//FhtVxlXOoU1IGcLtSZ/FFDPHfsZRec7IgPIWsmP spk7pEfVmoHMpXqfE5E200wr6MzqHQyfkL1Ho1rl/KuiAaD88ppWvLObw0u5/jikkf16 nwVz9Cy0xoap16c+JH14LmEjps2pWNPCz2iZnr71lodAp9u65grzcjak+iSpnvpdpblC y72zcfSwZz81+hfU6TLb5hXbDW/MJ71rOZvNIbVubzfuq3nrVLcQNlTGTaVO5VwNSrVl MhsA== X-Gm-Message-State: ALQs6tDFGuoe2qrvWVB6efkXA2cNQcb7EYcLYMRs/B7twxVCNTjbyEk1 3PmB6xSfuzIZtoX8e0i5QItA5zTBGKCLoJLfzrU= X-Google-Smtp-Source: AB8JxZrBfvaGOURs3c+6xY8cnPJa5axJ+/gTbw02CYEw+/asJiChNpuh7WIRC4B7cHhIMDh+qDhuft/rRJHV0BY6HwE= X-Received: by 2002:a9d:39e2:: with SMTP id y89-v6mr9660742otb.394.1525151092327; Mon, 30 Apr 2018 22:04:52 -0700 (PDT) MIME-Version: 1.0 References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> In-Reply-To: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> From: Martin Thomson Date: Tue, 01 May 2018 05:04:41 +0000 Message-ID: To: Paul Hoffman Cc: sara@sinodun.com, DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 05:04:55 -0000 On Tue, May 1, 2018 at 1:22 PM Paul Hoffman wrote: > > - EDNS(0) Keepalive (RFC7828). > I'm not sure why there are "problems" with these. For padding, the server can use it or not. For keepalive, it makes no sense for it to support it. Just like any traditional DNS server, a DOH server has to understand its context when deciding how to answer queries with EDNS options. Sara's request for text regarding 7828 is reasonable. Generic text might suffice along the lines of "extensions to DNS that are specific to the choice of transport, such as RFC 7828, are not applicable to DOH". FWIW, HTTP/2 has its own keepalive mechanisms. I agree with Paul here regarding padding though. Padding with EDNS(0) seems like a reasonable choice especially if padding at the HTTP or TLS layers is not used. EDNS(0) padding might be more accessible. > The complicated DNS-over-TLS usage policies are one of the reasons we have so little implementation of DNS-over-TLS. (Others may disagree with this statement.) I agree with Paul - the profile in RFC 8310 overlaps considerably with text in HTTP RFCs. For instance, HTTP/2 already mandates TLS 1.2 or greater without compression (it also goes further to require PFS). 8310 also misses a few things that DOH covers, such as the OCSP/AIA deadlock. The true advantage of DOH is that it just uses HTTP. And that means relying on HTTP mechanisms for ensuring integrity, confidentiality, and authentication. I think that those are broadly adequate. Separately, I'd suggest that the 8310 profile requirements are unrealistic. I'm not aware of many implementations that do raw public keys or cached info. I also don't see any particular value in mandating tickets and false start - they each provide ample motivation on their own without needing a MUST. From nobody Mon Apr 30 22:29:06 2018 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 8597212D871 for ; Mon, 30 Apr 2018 22:29:05 -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=mUjnKYoV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jZ1M4yhB 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 b2JkUcFYIYAn for ; Mon, 30 Apr 2018 22:29:02 -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 C263E1241FC for ; Mon, 30 Apr 2018 22:29:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E53AC225CF; Tue, 1 May 2018 01:29:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 01 May 2018 01:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=wgtGUhayK8HM0TKQbgtlHSqYH8K+1 62EVeT/b5GoFTk=; b=mUjnKYoVxzP/he6Zv/u0jAO+VPM4WUvPtcDTAcdx/WGou 8mt9q8wZoqTUuuANAC9Giyat4JTaiaezOZpEwi3EmTaK/GFbvLxWUFyzSKRVUd4i IFBqMvefbHmNR+xXVODCeBxSIDV2nWymcXenu6aj4A0IA/VkGJFtExfVoeesZ+P9 luwSbPgH7ZwJrPrKTc2k40uXjJK81ocgcClIUpn3iDAm4BI+hCcdWPDzOZjiekOW KoFlHW+BSweAbcrLS4qz0w9rcYNlWg/Be8gL7H5D7u1RPgA8s92xBFNr51Aq+1Zf KwpNFz2zzgcJTRg1H3HgrXcjUsnkpBhyN7Rhs0TEQ== 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wgtGUh ayK8HM0TKQbgtlHSqYH8K+162EVeT/b5GoFTk=; b=jZ1M4yhBtP9Guw3qfIpts/ JIkPGOj0lpiUxOBvZWZszYc5jN3kETJh1nOSATbiWy2qb/R1j62UhO98b72CvPr1 FV+OuiZoqoA7MugCT8/Xx+nJJfFs+8ULIdUlA0RkF2a9qKKclrrIh5bf0sTMY72U BNKd0PLXRnzHZlGuqDzSKIG5t3c6NJTKsP6phCViOHFtymGhHCVJm3uY7nQ2EfhS RWewuWnmbu68OTA9OAf/j0maYzXBfnAQ19wXt/uHbtigPt1P6WgNpZL42itFn6qY ezgCrGb/ZPFaiAumfZB8Q/0KTWXq5sCytt57uMiRVs6org8YfbA9jr4RgejWjJ4w == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 8FF841032B; Tue, 1 May 2018 01:29:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: Date: Tue, 1 May 2018 15:28:57 +1000 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Schwartz X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 05:29:05 -0000 Hi, Overall, this looks good. One issue: "The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]." SHOULD is too strong here, and "used by DOH" is ambiguous. Suggest: "DNS API clients and servers should support, but not require, the use of = HTTP/2 [RFC7540]." Cheers, > On 19 Apr 2018, at 5:07 am, Ben Schwartz wrote: >=20 > All, > This message starts a two week WG Last Call on advancing: >=20 > Title : DNS Queries over HTTPS > Author : Paul Hoffman, Patrick McManus > Filename : draft-ietf-doh-dns-over-https-07 > Pages : 17 > Date : 2018-04-11 >=20 > as a Standards Track document. The last call will end on May 2, 2018. > All substantive comments are to be sent to the doh@ietf.org list for > discussions. Editorial comments can be sent to the document editor. >=20 > You can find the latest version of the document here: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 >=20 > Regards, > Ben & tale > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/