From nobody Wed Oct 3 10:37: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 D7839127133 for ; Wed, 3 Oct 2018 10:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Taw8rtDUNXTf for ; Wed, 3 Oct 2018 10:36:58 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 86EE8124D68 for ; Wed, 3 Oct 2018 10:36:58 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id i76-v6so10112934ita.3 for ; Wed, 03 Oct 2018 10:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qb8PSTms1jgMunk8Ul6L73q6b87lVMM9KNAU/+y/qgk=; b=RUW19qovTDlBjUWC0oltLuuMY0Cl+86Fp+wj85CfSzUK5ca3vlcAMhS/Ank8ghZBUm wdtndaKX0b2qa+HDRWJ/zimJz01M/BbfAyOcH9x1df64H8YyPe/ZRCexKXTjs55e1YKE fwAXYHUK2dLMJE5W6qGDMKf2tF5Xu2HGR4QpQM4nE5gsu68Jme8PuIs4LUtHges/bFKy wBGFkPVTnRdeoyF5WX7NXP+eGMrFHXG/lUSbI2Y1xegELQ12sS3UDokg2nvRnWuytkAk d2oWrr1+HtKE0lle7CRTBUtQbRhOnILLu55tpaI5MsC/vHnPFYHELqK4knBOTGgA1Al+ Sqbw== 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:cc; bh=qb8PSTms1jgMunk8Ul6L73q6b87lVMM9KNAU/+y/qgk=; b=SIM1HsZ24LHWjc0NT5j0kTkACexPnmofHbtlpZo56sBjNhdqiwY2TdbPuMQDlTJA2o I1v4Nb9sJHyHoxlc6AzohffkPkuOTulqCvwDTTrI+oiPn7S/eKJAZyywif66sJcQxXmk 4FVFydxw3PjCafSDaBridyscObqG4WsyEEWoius/51AsMLjf1ZSs6VQwy6/dD3wewjp+ zgi/zQxFE0VKW6WpU4MYWf3vdD/kfipqDgLJbc3alfMS5tXUK/ghwe0Roq5fyhOXARny T4s+CI1tS1jMcHJ/uDZ4r2NY61MuwSpnzU1D2j5uKf0ckmTTwdl5VkmqakzvJpVmHqKz x4/A== X-Gm-Message-State: ABuFfohfrfyNz2GFnlIinIh7aMbZSCE89lIV3EQrvE8KTu2HzbM61a38 NBd6LRIXQh7qIQiKyHHTwaFl+xbVnBTh3BaNGsD2f2Z6uk4= X-Google-Smtp-Source: ACcGV62hGO/eo3OaMtyfxP4r+vfatqgDeJ04XgHeGPqic38V2BZ0fAkpEO/whLXt+YGSpKS5yg/9hud27kqHajfudRI= X-Received: by 2002:a24:7f87:: with SMTP id r129-v6mr2120185itc.107.1538588217532; Wed, 03 Oct 2018 10:36:57 -0700 (PDT) MIME-Version: 1.0 From: manu tman Date: Wed, 3 Oct 2018 10:36:46 -0700 Message-ID: To: DoH WG Cc: Ben Schwartz Content-Type: multipart/alternative; boundary="00000000000029666e0577567c87" Archived-At: Subject: [Doh] Google's (Jigsaw) Intra app X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 17:37:00 -0000 --00000000000029666e0577567c87 Content-Type: text/plain; charset="UTF-8" Hi all, I suppose people here have seen this in the tech news today: https://techcrunch.com/2018/10/03/googles-cyber-unit-jigsaw-introduces-intra-a-security-app-dedicated-to-busting-censorship/ >From https://github.com/Jigsaw-Code/Intra/blob/master/README.md , this is a DoH stub for Android. Props to Ben Schwartz whom is all over the git history. Manu --00000000000029666e0577567c87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=


Props to Ben Schwartz whom is all over= the git history.

Manu
--00000000000029666e0577567c87-- From nobody Fri Oct 19 11:53:07 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 5D6B51310AF; Fri, 19 Oct 2018 11:52:53 -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 FJ0gYYSmrjjt; Fri, 19 Oct 2018 11:52:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455731310AC; Fri, 19 Oct 2018 11:52:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4881AB8028C; Fri, 19 Oct 2018 11:52:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, doh@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20181019185223.4881AB8028C@rfc-editor.org> Date: Fri, 19 Oct 2018 11:52:23 -0700 (PDT) Archived-At: Subject: [Doh] =?utf-8?q?RFC_8484_on_DNS_Queries_over_HTTPS_=28DoH=29?= X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:52:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8484 Title: DNS Queries over HTTPS (DoH) Author: P. Hoffman, P. McManus Status: Standards Track Stream: IETF Date: October 2018 Mailbox: paul.hoffman@icann.org, mcmanus@ducksong.com Pages: 21 Characters: 46879 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-doh-dns-over-https-14.txt URL: https://www.rfc-editor.org/info/rfc8484 DOI: 10.17487/RFC8484 This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document is a product of the DNS Over HTTPS Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Oct 23 13:15: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 0E906128D0C for ; Tue, 23 Oct 2018 13:15: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, 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 0dpbH9xncxmk for ; Tue, 23 Oct 2018 13:15:42 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E881277C8 for ; Tue, 23 Oct 2018 13:15:42 -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.1367.3; Tue, 23 Oct 2018 13:15:40 -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.1367.000; Tue, 23 Oct 2018 13:15:40 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Associating a DoH server with a resolver Thread-Index: AQHUaw0qmaDMo9mkR0G5BSKkl0jQpQ== Date: Tue, 23 Oct 2018 20:15:39 +0000 Message-ID: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_73DA4EB4-FE7F-4E98-A208-61CD6EE4B2A8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 20:15:44 -0000 --Apple-Mail=_73DA4EB4-FE7F-4E98-A208-61CD6EE4B2A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Post-RFC-publication greetings. One of the topics that has been active = in the DNS community since the standardization of DoH is how a browser = or web application could use the resolver that the operating system on = which it is running as a DoH server, or at least to use a DoH server = associated with that resolver. I have taken a few stabs at designing a = protocol to make it possible to fulfill that need; the result is the = draft below. The draft is still in a very early stage. In fact, I've changed the = underlying mechanism three times already because I forgot what browsers = and operating systems could not do. I *think* the current draft is = possible, but would not be surprised if someone pointed out that even = this attempt is wrong. Regardless, the desire for such functionality = seems strong. Also note the Security Considerations section of the draft. In short: = all this gives you is opportunistic encryption because (I believe) we = can't get any better now. I would be happy to be wrong about that, of = course. Thoughts? --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Associating a DoH Server with a Resolver Author : Paul Hoffman Filename : draft-hoffman-resolver-associated-doh-04.txt Pages : 8 Date : 2018-10-23 Abstract: Browsers and web applications may want to know if there are one or more DoH servers associated with the DNS recursive resolver that the operating system is already using. This would allow them to get DNS responses from a resolver that the user (or, more likely, the user's network administrator) has already chosen. This document describes a protocol for a resolver to tell a client what its associated DoH servers are. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-04 = https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-do= h-04 A diff from the previous version is available at: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hoffman-resolver-associated-doh-= 04 --Apple-Mail=_73DA4EB4-FE7F-4E98-A208-61CD6EE4B2A8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyMzIwMTU0MFowIwYJKoZIhvcNAQkEMRYEFLAYW1yjpDavVzO2LmUtiBXTsPfGMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBKIn8aDj907Bb5cy7uGNrEaVfXT599f46UOZ/Rh/i6kw7fLeLisViGJ0v9/wVVgiPSAs9g ogyMloeIq5p8vpl4KEhSjG7nzR/XhbE7hS1kr51TwzCvzlUkAhyepEykTsa9WC4aG4ELh2485Phe TBac48WudPyFiCfI+cahx/gZike5BENnfBx6Qr9ehlzi4G9v6E9V5tJHimrvIz8HXUbIV9Fdhc9m 6RkyLjNXNBoHDAA5kpb9B7Q3fXHzHKVGEX2bWA9VODuuWWBqzRIqNu/GQ/OVFLrCKiaamoJ+gfiU 8mONHxLp+km4PAG5+WCll3oh3WLEXOxPagVu3Fy5z0UvAAAAAAAA --Apple-Mail=_73DA4EB4-FE7F-4E98-A208-61CD6EE4B2A8-- From nobody Tue Oct 23 13:28: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 D039C130DBE for ; Tue, 23 Oct 2018 13:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EdJf6HfXCiDI for ; Tue, 23 Oct 2018 13:28:07 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 6C8161294D7 for ; Tue, 23 Oct 2018 13:28:07 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9NKRi6J029739; Tue, 23 Oct 2018 21:27:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=55n09dScs5mmXMpucUHOTRKdNeWGq+QHedDpUyECbz8=; b=IHEhtYtq+J2w5WIShnk8m4JO7DrpR9y1J0dZdU6HHXrZ78d61rcDWcYmIuagrOr+1o10 3rG/PN7mklYxG++l2RsZUKhD+9j37G6YeePo9hUFpWVEVDByo3MpCqP0PjW9GPOpEtrr 6+gfFqN4yaSCcB1BFSZ4ke0t/rY/pnuY8SHlBO5Pvi7gK15yDDdw2EXHgpQr6CFehduu V9XBLQd60Z4n60LfewdocdDyJmdh4rBXVOgsNar6YfYQCHuMLs2+4KMY5PXZ1q5M+zxb 811ymvjtBPHChTgxD4ETRuYqgqxivpjiXCLdaoyDxXx177kuAWqYjtlw72v1l05XFxyD BQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2n9xnaaqg4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 21:27:46 +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 w9NKKTtk027442; Tue, 23 Oct 2018 16:27:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 2n7ypv5ux0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 16:27:42 -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; Tue, 23 Oct 2018 16:27:44 -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; Tue, 23 Oct 2018 16:27:44 -0400 From: "Hewitt, Rory" To: Paul Hoffman , DoH WG Thread-Topic: Associating a DoH server with a resolver Thread-Index: AQHUaw0qmaDMo9mkR0G5BSKkl0jQpaUtRl6g Date: Tue, 23 Oct 2018 20:27:43 +0000 Message-ID: <93a83d3ab32e4954bf6a21b92ac2ba16@usma1ex-dag1mb3.msg.corp.akamai.com> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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.118.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CB_01D46AD4.2D2A60B0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_06:, , 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-1807170000 definitions=main-1810230166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_06:, , 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-1807170000 definitions=main-1810230167 Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 20:28:09 -0000 ------=_NextPart_000_00CB_01D46AD4.2D2A60B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very nice - this was indeed the topic of MUCH discussion! I'm inclined to think that it might be better to be DNS-variant-agnostic - rather than this: /.well-known/doh-servers-associated/ use this: /.well-known/dns-servers-associated/ or even just /.well-known/dns-servers/ where the URI Template response would indicate the type of DNS server (DoH, DoT, Do53 etc.). It also allows for expansion if/when further DNS servers are defined... Rory -----Original Message----- From: Paul Hoffman Sent: Tuesday, October 23, 2018 1:16 PM To: DoH WG Subject: [Doh] Associating a DoH server with a resolver Post-RFC-publication greetings. One of the topics that has been active in the DNS community since the standardization of DoH is how a browser or web application could use the resolver that the operating system on which it is running as a DoH server, or at least to use a DoH server associated with that resolver. I have taken a few stabs at designing a protocol to make it possible to fulfill that need; the result is the draft below. The draft is still in a very early stage. In fact, I've changed the underlying mechanism three times already because I forgot what browsers and operating systems could not do. I *think* the current draft is possible, but would not be surprised if someone pointed out that even this attempt is wrong. Regardless, the desire for such functionality seems strong. Also note the Security Considerations section of the draft. In short: all this gives you is opportunistic encryption because (I believe) we can't get any better now. I would be happy to be wrong about that, of course. Thoughts? --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Associating a DoH Server with a Resolver Author : Paul Hoffman Filename : draft-hoffman-resolver-associated-doh-04.txt Pages : 8 Date : 2018-10-23 Abstract: Browsers and web applications may want to know if there are one or more DoH servers associated with the DNS recursive resolver that the operating system is already using. This would allow them to get DNS responses from a resolver that the user (or, more likely, the user's network administrator) has already chosen. This document describes a protocol for a resolver to tell a client what its associated DoH servers are. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-04 https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh- 04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hoffman-resolver-associated-doh-04 ------=_NextPart_000_00CB_01D46AD4.2D2A60B0 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/aADAgECAgp1UX8XAAIACpWTMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE4MTAw OTE1MzUzMVoXDTE5MDYwMzEzMjYyMVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyCIuTFZ3 C/eh8AzRqXz3JoW0m1tnKKYMcOyUQ73e//WdTHLMKUsDJrAMvHpj65GjdOsZkaFZz2jL3r5uqtZ8 jnpzpwa6ND0xcQ6RShMr0WbyUrhut1dPfts3aMES5BCMZvFwn9+kt4tn71qkz3k/moJdjPfDVyGW I4I3bUF8Y2zeX22cOjdAbEjcEpwyW0bg54BSVy8vvMNUyxcEkWkTUz6/4A3Je4Frac+bJKpzSiN5 4onzqTBtKgbdyTK752+8yxna0K+tRFkt9tNRSULsNb762lVDurMAHbMUZFvwaSm5aPaUvG+Cs2ci sdJ0nuS0x9VE83FVIlyhL1rKykDa7QIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQUyQhB157dDXrkacz6jcU+mea6T2EwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAFaEq0f7piYjdLGv0iQ6uKPe/TAqaZt1Ve4KcqdSYNaSsv0qFZ6I kXYEesqfozVvrMdypJ+jSjjLdYiA3elEGffaoAy29B/4uhTES/Vv7yYhxapyliOFqX+ohDkjc1c+ Rq9mIUj+2ikt3hF680/jUAkxxVUAwxHFf1kZIcShs1phk0G3IEU6FrqERgAa8cqhB4tegtpXBnoK OgoxI8YWK0DTutqcsO47W3mCjuaH3agASQhWuTvEv+JuBdS3YlQrUQ8CHPaP3Ach5t2hLN4JWJaj Kdoq+zs5twRWbN5wBnbOotYNHRb2BvfrCZVMzw3ggrLBNFMKkSdLxuDVOyyZH5UxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgp1UX8XAAIACpWTMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyMzIwMjc0MlowIwYJKoZIhvcNAQkEMRYEFF4pLsGcyVTTeLzO9bjYyIrI6Jj5MHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCCnVRfxcAAgAK lZMwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgp1UX8XAAIACpWTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAH2vSZna4MJ0SEMZN3iGgmdtXSK1AfIU9dUv9YJmOZ85b1NazYJtrkJi55T9 U+u/Wrxi5twsFPpbU0PX9PelnSn5O8F5/Wagdy24Mx9AnEouP4nnQG4i3dghNwv3bxPsr0A7QOIR oc8Y1tukMuRarhCdFiZO5wzberyBQX5Hmp5xwdcyOP18kct/D6JuRVdamO2XirUJC9xqMOXDMnoN rpgjqQCk4eWb4hXckLEM6TsKWHh1isZkfGUtdJf4YyFnVFUwTnJHejB1QTZR8iVhZQ/VoT560TDL oF0CgCJjr4XawA/Walkx0pfONgt+u3+PONaFe01aeLYzPYvvjyizqGcAAAAAAAA= ------=_NextPart_000_00CB_01D46AD4.2D2A60B0-- From nobody Tue Oct 23 14:05: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 EF766130E8B for ; Tue, 23 Oct 2018 14:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vp_NP6nKieI for ; Tue, 23 Oct 2018 14:05:30 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 D677C130F5B for ; Tue, 23 Oct 2018 14:05:29 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id q70-v6so3619633itb.3 for ; Tue, 23 Oct 2018 14:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MbWeBOOhRl0h6nxKkB76EPP6osljfYJw4QeZiAhke14=; b=FNLvg8ite0vgd23SzQaXljhlpp5pYWTb9KdAl7vPoWY6zKRFKpYKFzU2ZvXQ95yI1o wfxJy3ld7tGyHEraZBwRoi1sORTiRkCxqckVgx2lYPqxcMHkVg5Zky23LbOiRlAAZe2m CWHGZlAqGmsj0vtza/0I+N1O6WEOYhIC4SGcLmaECjdd9ht8Y7bPDyY5JUpcDfTo3CfH OmbtRIsAnTN3ExoQ6Gzs2sHSywKqD5Zz0gWOrNJ9lWrdOTPBKujgxn2G44z7GVK50S/G z+MVcy2qaKHCbXgY1/fcg4NEsBqrzOkSE1MT6zXrw42ZDqFGfKWn9dBR608lTY2hyWMo x/GA== 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=MbWeBOOhRl0h6nxKkB76EPP6osljfYJw4QeZiAhke14=; b=MZjR1zEUN27XUlwpyk0L1GV2R++ShM+RGSiCGahGjyirnuVh+IgKwCBzGHAXzx3GHL fRR/q4xz9DbVStRR6UmCovCLBo+5N+C+0MJ6RowAfHsqnNNOoC5GQ0AV/BYZhIclU1Bd RCeSfjoTcza1/dBUBNCD4zuMHo0aG2s/Ny77VS+ROXPCLHK/e5PDh66E2U+YIxsqq0mm WbNglT2+jMsiJXK9s1plCVsLdYn4PidoA40iVsfTbCtY/cQ4H1fu6eUIb/aMLU5wA49f fWyOYTH7Z3WzmW3kVBeoJ+jl9HpcVtDrPjt9MNjpOytpu2DZ40CNp2rGzqDJnpDiAkFF Zoyw== X-Gm-Message-State: AGRZ1gJyajyBsbW5JZNOGbhJ9Sx52hQ1oxYm/3IEJ3Th5bV1xhcCXeD1 h8SPrY4pckeQzwMewJNkMDcyhed0/vfhTwbh8vK0Og== X-Google-Smtp-Source: AJdET5fCBbNBr3wIz3myBwTJ0g3HpyY34fybHtAnPKSIZC9nYXs7X2Z4sIAQJi8pFuU75BXmRd1o/JgpgeieR9FDXg4= X-Received: by 2002:a05:660c:284:: with SMTP id s4mr851559itl.162.1540328728522; Tue, 23 Oct 2018 14:05:28 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> From: Ben Schwartz Date: Tue, 23 Oct 2018 17:05:17 -0400 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000bcf87a0578ebbafa" Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 21:05:36 -0000 --000000000000bcf87a0578ebbafa Content-Type: multipart/alternative; boundary="000000000000b3f7530578ebbad2" --000000000000b3f7530578ebbad2 Content-Type: text/plain; charset="UTF-8" Hi Paul, thanks for the continuing work on this topic. Two related questions: 1. Does the resolver have to return its own IP in the RR for resolver-addresses.arpa, or can it return some other IP addresses? 2. If a client has some OS-specific way to enumerate the DNS server IPs for the default network interface, is it still required to perform "Step 1"? (Most OSes do have some enumeration mechanism like this.) Other minor comments: On Section 4, User Interface: I don't see the need for a user interface here. In my view, opportunistic security generally shouldn't require user action and shouldn't produce a user-visible change. I think interaction with DoT is worth discussing here, even though it's probably trivial. If I can probe for DoT and (with this draft) DoH, which one do I probe first, and which should I prefer if both succeed? --Ben On Tue, Oct 23, 2018 at 4:15 PM Paul Hoffman wrote: > Post-RFC-publication greetings. One of the topics that has been active in > the DNS community since the standardization of DoH is how a browser or web > application could use the resolver that the operating system on which it is > running as a DoH server, or at least to use a DoH server associated with > that resolver. I have taken a few stabs at designing a protocol to make it > possible to fulfill that need; the result is the draft below. > > The draft is still in a very early stage. In fact, I've changed the > underlying mechanism three times already because I forgot what browsers and > operating systems could not do. I *think* the current draft is possible, > but would not be surprised if someone pointed out that even this attempt is > wrong. Regardless, the desire for such functionality seems strong. > > Also note the Security Considerations section of the draft. In short: all > this gives you is opportunistic encryption because (I believe) we can't get > any better now. I would be happy to be wrong about that, of course. > > Thoughts? > > --Paul Hoffman > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Associating a DoH Server with a Resolver > Author : Paul Hoffman > Filename : draft-hoffman-resolver-associated-doh-04.txt > Pages : 8 > Date : 2018-10-23 > > Abstract: > Browsers and web applications may want to know if there are one or > more DoH servers associated with the DNS recursive resolver that the > operating system is already using. This would allow them to get DNS > responses from a resolver that the user (or, more likely, the user's > network administrator) has already chosen. This document describes a > protocol for a resolver to tell a client what its associated DoH > servers are. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-04 > > https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-hoffman-resolver-associated-doh-04 > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000b3f7530578ebbad2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul, thanks for the continuing work on this topic.
Two related questions:
1. Does the resolver have = to return its own IP in the RR for resolver-addresses.arpa, or can it retur= n some other IP addresses?
2. If a client has some OS-specific wa= y to enumerate the DNS server IPs for the default network interface, is it = still required to perform "Step 1"?=C2=A0 (Most OSes do have some= enumeration mechanism like this.)

Other minor com= ments:
On Section 4, User Interface: I don't see the need for= a user interface here.=C2=A0 In my view, opportunistic security generally = shouldn't require user action and shouldn't produce a user-visible = change.

I think interaction with DoT is worth disc= ussing here, even though it's probably trivial.=C2=A0 If I can probe fo= r DoT and (with this draft) DoH, which one do I probe first, and which shou= ld I prefer if both succeed?

--Ben

=
On Tue, Oct 23, 2018 at 4:15 PM= Paul Hoffman <paul.hoffman@ic= ann.org> wrote:
Post-RFC-pub= lication greetings. One of the topics that has been active in the DNS commu= nity since the standardization of DoH is how a browser or web application c= ould use the resolver that the operating system on which it is running as a= DoH server, or at least to use a DoH server associated with that resolver.= I have taken a few stabs at designing a protocol to make it possible to fu= lfill that need; the result is the draft below.

The draft is still in a very early stage. In fact, I've changed the und= erlying mechanism three times already because I forgot what browsers and op= erating systems could not do. I *think* the current draft is possible, but = would not be surprised if someone pointed out that even this attempt is wro= ng. Regardless, the desire for such functionality seems strong.

Also note the Security Considerations section of the draft. In short: all t= his gives you is opportunistic encryption because (I believe) we can't = get any better now. I would be happy to be wrong about that, of course.

Thoughts?

--Paul Hoffman

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Associating a DoH Server with a Resolver
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Paul= Hoffman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hof= fman-resolver-associated-doh-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-23

Abstract:
=C2=A0 =C2=A0Browsers and web applications may want to know if there are on= e or
=C2=A0 =C2=A0more DoH servers associated with the DNS recursive resolver th= at the
=C2=A0 =C2=A0operating system is already using.=C2=A0 This would allow them= to get DNS
=C2=A0 =C2=A0responses from a resolver that the user (or, more likely, the = user's
=C2=A0 =C2=A0network administrator) has already chosen.=C2=A0 This document= describes a
=C2=A0 =C2=A0protocol for a resolver to tell a client what its associated D= oH
=C2=A0 =C2=A0servers are.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/= doc/draft-hoffman-resolver-associated-doh/

There are also htmlized versions available at:
https://tools.ietf.org/html/draf= t-hoffman-resolver-associated-doh-04
https://datatracker.ie= tf.org/doc/html/draft-hoffman-resolver-associated-doh-04

A diff from the previous version is available at:
https://www.ietf.org/rfc= diff?url2=3Ddraft-hoffman-resolver-associated-doh-04

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000b3f7530578ebbad2-- --000000000000bcf87a0578ebbafa 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYJWDwudxwNjwu8B4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MTAxNDA4MjIxMloXDTE5MDQx MjA4MjIxMlowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCjAFK2jxl2SbwdLgmpNj92zrqk75pYCWjsHhvdBpOYu7YqUel7 tZEj5mGxVhKL8jbTW9bEM/iB1XBfK+JjPXV+WADiV+9+yRRDRugD0oy5iTiEFNVATSd4G5Su+lfw aCM7aa4opbbXPkehb7Gkx3zks54gj2F5KH7dvmvMdAVZuH6Ff4TnUkzolgu/llEzjYArUXHDaAR4 WE02VO3FbyLV97Y68Z3gtHbzsyAOXK6hjLiVwGBTaWaApt9i+d0jR0SDWClPDyK3Vq3QhLVpewN8 bRR1rb72UKt2an3n95SrvbhD639vfyy/cHR09HxDXXlTfyugAk0kYIQiqwS1X74zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFDPcHr72CmAhHX2sPCeQbgmPbXZWMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQATQwVzUhwG45UvRH44 Ls0IDXKJb9GVoZurKcd19M1EtjywGT6ZfFDW1DenoGaf/gizTDc0dHMLV79yXlj6yLtsDkP6rb7f zOyczFMqHbXRXT9YDJlPcOrtp3E2wA/HHph+nimVhrmfcGMndO5AV2DzTD2oOQe5C/mh9RUT5z6/ CrUQ0dAaBZweRC8agj/PQ4Jnen/kqDBE/TgK0ChQ7Q44MkuENG0dp2bPuHG7ZPKkqZ2V5LGhrba4 c4MtQvK9dyNE8urDPL70ogUS3pwBvfui1H1gbHJwe3npqkBvuqswxS7IvDmW88A1wGeWt/02LLQP ysd6YM+XWMe3rBB1zzJDMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYJWDwudx wNjwu8B4MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB8WYYrWUoIMTq+Y9H/DwV+ QDf2/XFJefRoAXI6Q5BkrjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODEwMjMyMTA1MjlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAkwDXU2wXU/SBbOxQiu8TopnOXQGqR6uckfaIi/Fu i/+AFj89cAUFVPhmvGS9cI+SaBIor3JZaDn/SRmNB65ofGY63jn725d04Tb2WqzDauyP7d+1w/Te u+ot03W2dQGh74r5pvWZ5Omzoy5LcCOXQlQhAXcA2P+uhIzNs4OtNxuGoqUg6F//k62u6VCKPOaP 1F1whOnqScBMwXQszlM5hQCH+JlXxjyu/4VH+UQM9k8XQKqmjeUosRCULclUjsBsBfHCSUKE3kSj edvWUOwbyTNNI2qaGH3q2qidAAuMmGd3Goc5VbzONaxwwjIxmKeZDjvQ42EAdV0UJuJiwwPSKA== --000000000000bcf87a0578ebbafa-- From nobody Tue Oct 23 18:08: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 11A0412D4EA for ; Tue, 23 Oct 2018 18:08:45 -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 yiV8TyEWgi8H for ; Tue, 23 Oct 2018 18:08:43 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 2BECB128CE4 for ; Tue, 23 Oct 2018 18:08:43 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id k64-v6so2703310oia.13 for ; Tue, 23 Oct 2018 18:08:43 -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:content-transfer-encoding; bh=52arPFwH3u+tUbPGkMH5NlcOsV/qzZgx9lBNLk//yS0=; b=CBFbfZ+QgV8rqQ6jDfYaQB23+2xlCvqAf1M/vZoBo9M/jXz3XT/Y8GaKMqtH5NhsId yM3Ytp2zAUkem0hB8sHlkdYjxbdrDzeGSARN2FgAc/pnmnAikIkB35LOFFW3/qtpxNI8 /kW9oMFqPyX6s5x7A/OgOKABxhdWyo4pQOAobWPjY9D5N8hQv3hNzdH9VgkANVX97LTE tSzbEytKkxUKGEVke5xvfng/YmoIskgAogkPDzV+3pq7Ohvy1JsW67TADrzKCnPNfwQF SEga+6sojzR6QuiJ/4M48BedJIPnuUXe8pSCVx66wnMh7qoA0Te6rE7KOyR8EwGiBHVU p3mw== 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:content-transfer-encoding; bh=52arPFwH3u+tUbPGkMH5NlcOsV/qzZgx9lBNLk//yS0=; b=Mv3WzPNbp2j/mQtK5CP1iQ6drxRVMjATlai0KqtO6jO8FEmcnelaZDkUhqoiO+EdiX caTBFV4Z0w9rewNrZskf+Hr5RkvqG3aBi3VEh/q69ibrGzLDOyOZmGT1jnIqZt43A2DK B76KRmFWYxZtopjrrKuBFCoahZjmOCdshl4MxHdg3INZgZ/bhUQ/SA2n37VH0gqQ/hq/ nED4drxIW5xK+F7mAYibIkP8I/M1zkqx+k/3Iq7k8sRafgCsXmL18iy5Er+fadl6NOuq BpyVPEnv7eK9xsjFQil+kf19lWKyP3S8Slfl0zkZMOIww9yi359r9jgz/0QrbA8dV+Ok mP9w== X-Gm-Message-State: AGRZ1gIzJQYAAoYhAZCkflAWxiTD1OR0yKGoc1Pn3VHS2pqkJYozPgir sgnoyrxaHFDKUxwOGXXCd/q/UNa0DAt73e6cTME= X-Google-Smtp-Source: AJdET5fDPVYb9acEsE4XInBLxMBNNQ9V04FLG8roXAJUfVvakPktwRS0wKiNZ/h8y0qguQkGkEhVyaDak+umUUq++8k= X-Received: by 2002:aca:fd89:: with SMTP id b131-v6mr299677oii.30.1540343321011; Tue, 23 Oct 2018 18:08:41 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> From: Martin Thomson Date: Wed, 24 Oct 2018 12:08:31 +1100 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:08:45 -0000 Why do the IP-based spelunking? It requires that the resolver (which might not be a DoH server) do HTTP as well. Can't you define a record that could be placed at the resolver-addresses.arpa name? I hesitate to say TXT, but I can't think of a good reason not to use that in this case. Multiple such records could identify different DNS-over-foo variants. On Wed, Oct 24, 2018 at 7:15 AM Paul Hoffman wrote= : > > Post-RFC-publication greetings. One of the topics that has been active in= the DNS community since the standardization of DoH is how a browser or web= application could use the resolver that the operating system on which it i= s running as a DoH server, or at least to use a DoH server associated with = that resolver. I have taken a few stabs at designing a protocol to make it = possible to fulfill that need; the result is the draft below. > > The draft is still in a very early stage. In fact, I've changed the under= lying mechanism three times already because I forgot what browsers and oper= ating systems could not do. I *think* the current draft is possible, but wo= uld not be surprised if someone pointed out that even this attempt is wrong= . Regardless, the desire for such functionality seems strong. > > Also note the Security Considerations section of the draft. In short: all= this gives you is opportunistic encryption because (I believe) we can't ge= t any better now. I would be happy to be wrong about that, of course. > > Thoughts? > > --Paul Hoffman > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Associating a DoH Server with a Resolver > Author : Paul Hoffman > Filename : draft-hoffman-resolver-associated-doh-04.txt > Pages : 8 > Date : 2018-10-23 > > Abstract: > Browsers and web applications may want to know if there are one or > more DoH servers associated with the DNS recursive resolver that the > operating system is already using. This would allow them to get DNS > responses from a resolver that the user (or, more likely, the user's > network administrator) has already chosen. This document describes a > protocol for a resolver to tell a client what its associated DoH > servers are. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-04 > https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-d= oh-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hoffman-resolver-associated-doh= -04 > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Tue Oct 23 18:10: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 5A6B412D4EA for ; Tue, 23 Oct 2018 18:10:42 -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 G3YytgqlIB_l for ; Tue, 23 Oct 2018 18:10:40 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 C6DDF128CE4 for ; Tue, 23 Oct 2018 18:10:40 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id c32so3354510otb.8 for ; Tue, 23 Oct 2018 18:10:40 -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=J/yB21EMW45jl7LTiP002CnbI27/hrQ3Jgp5DamDGjc=; b=s+iM0atnpiJ5VTGTkXb68IhW2RrNQ2JO8Yww/ffUxXuxBWB8n+S8eJQmLn3SXdyTY4 MEol0WN9jHycCXsS6grjOXG2uDdzYYMdDKHnEI3a2zrUfbtq3Pohgo4qI9ikuLKUz71Y bYVz9lxKfOZ9rLj8KL44vVGVjQBtb6z7Sq7qDzNP47+mrx345uNou4pmrqsQh3Fa3qWX apMW0/UYOzixqWHldd0dEGuBQ+hB5cALrOnYiO49JYFH0tEzqiclEPk84ZQMH0s4hGdK CKjHOA6xEfJdtzB3cRWSkn2w0x/ODpYiL9vHrHGm2CbqLvU1on2/jBVRgPWLLfX42rAW jtTg== 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=J/yB21EMW45jl7LTiP002CnbI27/hrQ3Jgp5DamDGjc=; b=OL8y3uTdIi5qxR4Mj6P2EKef0uOJ117juq7mnzgAW2yj/9OPwsQnPqtCVNZ5PdCGms g6PZa71YhlEASRxX5kTlrXJj3sJjrv2mM1jAbJ/ZMP8iH1asC9dEeqRkJwl6PFNtDCzL bog6T4bzcEM8BSQoiUTwdfDwpW1FT77xobix9hKInpVuhS1WtZaYI0oiPqw+kfPDhz0M gWsCEssU713d/RAI2mpERWRG1vk2eXVgqf9Xh+Ru3F/COF5+rXIfWmATwwkasPDuOnTv /9/D3B2eDvBu+5SNpZ49X7nTGeRM2m94PINkYWhy13d3+IFvgtuQmTNDwl5wNwyhpkAv FzKg== X-Gm-Message-State: AGRZ1gKuLn5xxI6/c20zr9vaIUpPO+u8/yZ3CfYDLljJmcMvecv55SwL Jy1M6GnwoUrOsczIUeT8IrVcYJqRcNku7t9wMJdj4wpDbmo= X-Google-Smtp-Source: AJdET5cX2QjErjMiynxIGTGKOvOX8/Es4E/PaUdjiqeRisKUCEb+NzejJQv1oyNoz0K0QQwk8pAC/vEBi1Qzc+em+h8= X-Received: by 2002:a9d:7602:: with SMTP id k2mr357261otl.299.1540343440096; Tue, 23 Oct 2018 18:10:40 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: From: Martin Thomson Date: Wed, 24 Oct 2018 12:10:31 +1100 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:10:42 -0000 On Wed, Oct 24, 2018 at 12:08 PM Martin Thomson wrote: > Why do the IP-based spelunking? It requires that the resolver (which > might not be a DoH server) do HTTP as well. Can't you define a record > that could be placed at the resolver-addresses.arpa name? I hesitate > to say TXT, but I can't think of a good reason not to use that in this > case. Multiple such records could identify different DNS-over-foo > variants. Oh, I forgot. IP-based certificates complicate things considerably, and will make this impossible to deploy in many cases (think of the many resolvers with 1918 addresses, for example). From nobody Tue Oct 23 18:12: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 07ACF12DD85 for ; Tue, 23 Oct 2018 18:12:15 -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 53jNq2NkKNtl for ; Tue, 23 Oct 2018 18:12:12 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E23128CE4 for ; Tue, 23 Oct 2018 18:12:12 -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.1367.3; Tue, 23 Oct 2018 18:12:10 -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.1367.000; Tue, 23 Oct 2018 18:12:10 -0700 From: Paul Hoffman To: Martin Thomson CC: DoH WG Thread-Topic: [Ext] Re: [Doh] Associating a DoH server with a resolver Thread-Index: AQHUaw0rsD7rsPjFwE2sWEnE1v4NXKUuC2aAgAABBIA= Date: Wed, 24 Oct 2018 01:12:09 +0000 Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_7990F306-232F-4355-8762-86E295481BB2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:12:15 -0000 --Apple-Mail=_7990F306-232F-4355-8762-86E295481BB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 6:08 PM, Martin Thomson = wrote: >=20 > Why do the IP-based spelunking? It requires that the resolver (which > might not be a DoH server) do HTTP as well. Can't you define a record > that could be placed at the resolver-addresses.arpa name? I hesitate > to say TXT, but I can't think of a good reason not to use that in this > case. Multiple such records could identify different DNS-over-foo > variants. Given the offline comments I'm getting similar to this one, I did not = emphasize this enough in the draft. There is no way for an application like a browser to send a query = through the OS for anything other than address records. That is, = gethostbyname() and its equivalents only pass back address records. Even = if an application had its own DNS stack to make queries for other = RRtypes, it doesn't have any way to know where to send them to. If I'm wrong about the above, that's great, because we could certainly = simplify the way that Martin suggests above or that I had in earlier = versions of the draft. --Paul Hoffman= --Apple-Mail=_7990F306-232F-4355-8762-86E295481BB2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDAxMTIxMFowIwYJKoZIhvcNAQkEMRYEFGNtHAXfJfD86Fkw6S9etpOHaCeXMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAMSuwX0kF8zFsuBA91qX0eofgNhoBelkJaLUavf+KkjufC2uxH8lUqEGi/WA0JCXFF07wk NSs8pNELxuQFmqfZ2EtpkrZ9Fb/OwAEVxn8Pykjhljli0AMDLhgm/dojPnC+mk/ykc/v0nZWV9+k JjcAWzUUJQoaY6I4WFWZUK9jCI/RkXEfeEobIH0GoMt8g8CHzddUEVbym+6oOhrgJdDwaIBJUy9I qo+aGbE6/BDiwwLMm/+cOQO3dyXLJkKizV7s2cMkVeTHNMwsGMu/c8DP8Oigki4KARAZuoa6SnqA u6331XGiI4SmMyX5erg3HyJlMq3Wcayxm8L2zxsXxf62AAAAAAAA --Apple-Mail=_7990F306-232F-4355-8762-86E295481BB2-- From nobody Tue Oct 23 18:14: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 695D012F1A6 for ; Tue, 23 Oct 2018 18:14: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 B9cNoicoPrdC for ; Tue, 23 Oct 2018 18:14:32 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.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 A4095128CE4 for ; Tue, 23 Oct 2018 18:14:32 -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.1367.3; Tue, 23 Oct 2018 18:14: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.1367.000; Tue, 23 Oct 2018 18:14:30 -0700 From: Paul Hoffman To: Martin Thomson CC: DoH WG Thread-Topic: [Ext] [Doh] Associating a DoH server with a resolver Thread-Index: AQHUazbp6g+71tYZa0yY1+d/fYrLTw== Date: Wed, 24 Oct 2018 01:14:29 +0000 Message-ID: <67726F45-C947-48ED-B6ED-ABE2BD547AB1@icann.org> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_3BD67A41-64F2-400A-8CD1-7504A337BA18"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:14:34 -0000 --Apple-Mail=_3BD67A41-64F2-400A-8CD1-7504A337BA18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 6:10 PM, Martin Thomson = wrote: >=20 > On Wed, Oct 24, 2018 at 12:08 PM Martin Thomson > wrote: >> Why do the IP-based spelunking? It requires that the resolver (which >> might not be a DoH server) do HTTP as well. Can't you define a = record >> that could be placed at the resolver-addresses.arpa name? I hesitate >> to say TXT, but I can't think of a good reason not to use that in = this >> case. Multiple such records could identify different DNS-over-foo >> variants. >=20 > Oh, I forgot. IP-based certificates complicate things considerably, > and will make this impossible to deploy in many cases (think of the > many resolvers with 1918 addresses, for example). They don't make it "impossible" by a long shot. Plenty of resolvers, = even corporate resolvers, have public addresses. --Paul Hoffman= --Apple-Mail=_3BD67A41-64F2-400A-8CD1-7504A337BA18 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDAxMTQzMFowIwYJKoZIhvcNAQkEMRYEFBjPs2wUmEAN9TeaZPTKhJHrb3RYMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAZ4DGt79E75Br69yzyHv4dKRzCXDjokvpAeJRf8OQ4wKw00zABhLTL0XWZ/Nc7lUeqEZn/ V2NUuhQEBmxo2grwj6OhXE/6MfjewrcJZqyMlHwMHw0KteiWIKto9peCYVVpVOcmxWfYRSl3JHGx Ky53M/5DV0MgixY0bhNIMozTPNv9OcLCZcQ7BrP3HQ/8scvHe4OQV3ZLfva39NnlU5cyqfzahQru kiLD5nplBqtkUNRrmbqUZ981OMm3qdx7pm3KFEeW5DwLXVLEr4G3ljfSvVyhq5cG+NKhe2c5lo5u BQX84R0AYkSKdstC2eYd1duyX/48hMx0jI2DbvzidR2dAAAAAAAA --Apple-Mail=_3BD67A41-64F2-400A-8CD1-7504A337BA18-- From nobody Tue Oct 23 18:22:26 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 9B4E1128CE4 for ; Tue, 23 Oct 2018 18:22:24 -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 FXH7M1L7qBhw for ; Tue, 23 Oct 2018 18:22:23 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::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 CAA12128CB7 for ; Tue, 23 Oct 2018 18:22:22 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id 20-v6so2753915oip.1 for ; Tue, 23 Oct 2018 18:22:22 -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:content-transfer-encoding; bh=0nUsPyRqv5246YyKIQTNeUgrHYwuSIsFMctgEU0tTzU=; b=i1LrbormNCnEWQW6ES4n5THh3OzIhsdVCZg/C5Mm2T2aUfTw0cNU97G5VnKS5DtdIP pS34nr0MRkuj+/VldCMQ7tvPWqzneEThMw1o1iboouRU6VOkA4NvFdN1j6jlOFqn5Wvw ntyrHMVqxwe70by5HlJu8F+vKL7wAFx4clCzLHSdrbV91Bq0UOFWmzAaiVvNbRaGw96P ALcgUlizDNjlR9TxAlfN8AahzaoE6fy6j4sxCA2iDOn7NAWoWoWRK3m5P1UNRQf4UwJm a619znrwFZDOHZh+Fm6xPD1H9nrB7uhfixvgLmAYbudHtN6n5AHPW4WFJNyw8QFfIppf bGfg== 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:content-transfer-encoding; bh=0nUsPyRqv5246YyKIQTNeUgrHYwuSIsFMctgEU0tTzU=; b=AB+QABkM/X51FxkcVSN3ShJ35jnETzg+thkocriavcygtQ5+W8W+p5HSkbG+vU40ST 55iAq2nXUpp1ncsZ4fBozXPahWhrNlpK6QCdcwVeFAvhW/7WchPvGuT43361NPI+0yRj AiYFGrUFKIywGJnUlcwfv8FCgW9WSP/057jAc7tVlzIVSVYDdgq3TOXz5aDfvImIFYby ZDqZ1MqkTnM0cuAQYKiyxkLlAHtYVqqnXmVR6UugX03/jZ5q3zzMr1YA0kLNUUtvHTuZ o5Jf/knjuo8il2F9/5D1u4QKytLNXlXA7SQ3EqrvwcHBpMA76ULwQeHx0LHM5L6m2kdM K1DA== X-Gm-Message-State: AGRZ1gKljcNfXTQZsrL1eEqjgiJ3kjQ3kpN7L0PpQ9DeEx8AmrdUCEDx rFT9j8PFf/Q/aBI6mS1VZ4x+7CZbktMRWPiaQZnT1UYdIkE= X-Google-Smtp-Source: AJdET5cy5MmHd+dWM5keB+zTYXUiug20OFrYZTgakBWs1xHL8TJsiyYs+hWT0J4HyFcDIecZRPWxqE4gRpBthfAQnFs= X-Received: by 2002:aca:5452:: with SMTP id i79-v6mr321011oib.344.1540344142066; Tue, 23 Oct 2018 18:22:22 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: From: Martin Thomson Date: Wed, 24 Oct 2018 12:22:13 +1100 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 01:22:25 -0000 On Wed, Oct 24, 2018 at 12:12 PM Paul Hoffman wrot= e: > There is no way for an application like a browser to send a query through= the OS for anything other than address records. That is, gethostbyname() a= nd its equivalents only pass back address records. Even if an application h= ad its own DNS stack to make queries for other RRtypes, it doesn't have any= way to know where to send them to. Well, resolver-addresses.arpa./IN/A(AAA) might still be useful for that then. That's not ideal, but I believe that there are ways to make queries for other record types that are more available now than perhaps there were in the past (see https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsqu= ery_a for example). >> IP-based certificates [...] impossible to deploy in many cases (think of= the many resolvers with 1918 addresses, for example). > > They don't make it "impossible" by a long shot. Plenty of resolvers, even= corporate resolvers, have public addresses. True, it is probably still possible, but it's not like you can just use ACME to get the certificate. That's "possible" in theory, but I'm looking for practicable. From nobody Tue Oct 23 20:19: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 8D1C9130DFD for ; Tue, 23 Oct 2018 20:19:18 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 BNwzu9srXWWN for ; Tue, 23 Oct 2018 20:19:16 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 47314130DDA for ; Tue, 23 Oct 2018 20:19:13 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id x24-v6so2783257lfe.5 for ; Tue, 23 Oct 2018 20:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLHv2SvNYTFn3aU2IkhXp6K+4olFG8qvj+gz7uEnZjA=; b=iZzM8hyJX8Xoi/IzLQ/labpM7+1p4IO3+AYntnERVknxYH7wKurJjpOnR8k1pbjA54 fC78Zm1Sf+o8mbd1aSky+0jkINXcs4Yftrg8+BEr5wKdeBGLLyTeiULDfO7DXPQULg+F 0TVVEpJMkfysNU/cD2YRMl9Ly3OgCe7Xwl4B6E3gJvCOmNuton6nKtMy9OKaIWEoG/eH f1wI9IXn8OWJeMya3u5dyfMCEVjv1AyFAfkVga0z49pPVnXTwybRSPHrki6LrrgKgQiQ 4kShUIpmieRebiehtTjxjtvqznGDKxsXKAjcVAFhfzic8l7hSZQ9Pro6KfCzJ8EbuhB6 BQ4Q== 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=MLHv2SvNYTFn3aU2IkhXp6K+4olFG8qvj+gz7uEnZjA=; b=KVOoiaOtTMvXs1ClaYFkpfjxzG2BkErEDkkYE1GkYv8bvXz4ZZE8dwZZpr9B2C0fLZ vxSZdEB+RqanfTNOvNny3MQcxEzVBbV/oHWXEy4EZR3oXINKBBtAuoYb7KQqSEsbtbeI FZH/zO/+A4FTbl/gWotVFxmy7Cq/G5ak9ggW015wv/Quxlwr32GKf3VfTC7/Y5t27YWD iViys/SmFdDNqlwwEOyZwYFKB1UAZNWUR9fI/GQVpfqUWH0k5GTM9C2mNUtgiHxc3GT3 q2hLAPB4wOtCmuITFo2GsZXKUVoVA5nNg8DzjJwJDWkm7dIOvOrrLVw7PpIMbVGwLknz Y/+Q== X-Gm-Message-State: ABuFfoh4FrfG7v5WADnYUvvOv47wNcp6Cj8eSOcqeqst84LXFnMPlAtM k4vOrGRo8CtVmQlVApc3BZ43dU8cn1iIf9hGUJNXZg== X-Google-Smtp-Source: ACcGV60zkS5JR/FtwVqNRPetGRIhug/GradmNex2pAnGAgrFLiyXrdcagkYZOzJm7FOmvmjsdYht6zKxEN4ctsEB4iU= X-Received: by 2002:a19:ca51:: with SMTP id h17mr4638562lfj.126.1540351151395; Tue, 23 Oct 2018 20:19:11 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: From: Eric Rescorla Date: Tue, 23 Oct 2018 20:18:32 -0700 Message-ID: To: Martin Thomson Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="0000000000003569730578f0f319" Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 03:19:19 -0000 --0000000000003569730578f0f319 Content-Type: text/plain; charset="UTF-8" Several points here: 1. As a matter of aesthetics, I agree with Martin that domain names would be better. 2. Martin sent a link to a method for resolving TXT records on Windows. MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc . So, this doesn't seem prohibitive to me. 3. It seems like in the use case for which this draft is specified, the whole thing is pretty opportunistic, so IP address certs wouldn't be required. 4. There are other uses cases for which it might be nice to have real domain names, in which case the IP address cert thing is a pain. For these reasons, I think a domain name in TXT or the like would be better. -Ekr On Tue, Oct 23, 2018 at 6:22 PM Martin Thomson wrote: > On Wed, Oct 24, 2018 at 12:12 PM Paul Hoffman > wrote: > > There is no way for an application like a browser to send a query > through the OS for anything other than address records. That is, > gethostbyname() and its equivalents only pass back address records. Even if > an application had its own DNS stack to make queries for other RRtypes, it > doesn't have any way to know where to send them to. > > Well, resolver-addresses.arpa./IN/A(AAA) might still be useful for > that then. That's not ideal, but I believe that there are ways to > make queries for other record types that are more available now than > perhaps there were in the past (see > > https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsquery_a > for example). > > >> IP-based certificates [...] impossible to deploy in many cases (think > of the many resolvers with 1918 addresses, for example). > > > > They don't make it "impossible" by a long shot. Plenty of resolvers, > even corporate resolvers, have public addresses. > > True, it is probably still possible, but it's not like you can just > use ACME to get the certificate. That's "possible" in theory, but I'm > looking for practicable. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000003569730578f0f319 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Several points here:

<= /div>
1. As a matter of aesthetics, I agree with Martin that domain nam= es would be better.
2. Martin sent a link to a method for resolvi= ng TXT records on Windows. MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsserviceque= ryrecord?language=3Dobjc.
So, this doesn't seem prohibiti= ve to me.
3. It seems like in the use case for which this draft i= s specified, the whole thing is pretty opportunistic, so IP address certs w= ouldn't be required.
4. There are other uses cases for which = it might be nice to have real domain names, in which case the IP address ce= rt thing is a pain.

For these reasons, I think a d= omain name in TXT or the like would be better.

-Ek= r


On Tue, Oct 23, 2018 at 6:22 PM Martin Thomson <martin.thomson@gmail.com= > wrote:
On Wed, Oct 24, 2018 at= 12:12 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
> There is no way for an application like a browser to send a query thro= ugh the OS for anything other than address records. That is, gethostbyname(= ) and its equivalents only pass back address records. Even if an applicatio= n had its own DNS stack to make queries for other RRtypes, it doesn't h= ave any way to know where to send them to.

Well, resolver-addresses.arpa./IN/A(AAA) might still be useful for
that then.=C2=A0 That's not ideal, but I believe that there are ways to=
make queries for other record types that are more available now than
perhaps there were in the past (see
https://docs.microso= ft.com/en-us/windows/desktop/api/windns/nf-windns-dnsquery_a
for example).

>> IP-based certificates [...] impossible to deploy in many cases (th= ink of the many resolvers with 1918 addresses, for example).
>
> They don't make it "impossible" by a long shot. Plenty o= f resolvers, even corporate resolvers, have public addresses.

True, it is probably still possible, but it's not like you can just
use ACME to get the certificate.=C2=A0 That's "possible" in t= heory, but I'm
looking for practicable.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000003569730578f0f319-- From nobody Tue Oct 23 20:40: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 15486130DDA for ; Tue, 23 Oct 2018 20:40:21 -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 vhUThWYThMKS for ; Tue, 23 Oct 2018 20:40:17 -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 46C06130DE5 for ; Tue, 23 Oct 2018 20:40:15 -0700 (PDT) Received: from Svantevit.attlocal.net (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 w9O3dp9n095790 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Oct 2018 22:39:52 -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 Svantevit.attlocal.net To: Eric Rescorla , Martin Thomson Cc: Paul Hoffman , DoH WG References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> From: Adam Roach Message-ID: <2695a0e8-8373-8d33-7951-cfc5555ed254@nostrum.com> Date: Tue, 23 Oct 2018 22:39:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 03:40:21 -0000 On 10/23/18 10:18 PM, Eric Rescorla wrote: > Several points here: > > 1. As a matter of aesthetics, I agree with Martin that domain names > would be better. > 2. Martin sent a link to a method for resolving TXT records on > Windows. MacOS has its own API: > https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc. > So, this doesn't seem prohibitive to me. > 3. It seems like in the use case for which this draft is specified, > the whole thing is pretty opportunistic, so IP address certs wouldn't > be required. > 4. There are other uses cases for which it might be nice to have real > domain names, in which case the IP address cert thing is a pain. > > For these reasons, I think a domain name in TXT or the like would be > better. If we are going for non-A/AAAA record types, then I would suggest that we use the record to directly indicate the URI instead of having to synthesize one using a .well-known path. I would also point out that we already have a resource record type for converting desired services into URIs (RFC 7553). So, e.g., interested clients would query for a URI record of type _doh._tcp.resolvers.arpa, and get back a full HTTPS URL as a response. /a From nobody Wed Oct 24 02:38: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 BC334130DDB for ; Wed, 24 Oct 2018 02:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu 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 JvY0HgbzWSwd for ; Wed, 24 Oct 2018 02:37:56 -0700 (PDT) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C329E12958B for ; Wed, 24 Oct 2018 02:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=SRe0FswqNkK4l+Dn/OKZ1MRYXB7qVyIjRcH/4RZjykY=; b=H4CTv5prOpAhlIcgtODreVe0zpHIm2NtjCaNnHCJGmgIgOOswEBHotEZdVGyjXoFFkQkM6owUu BgDJXEqV7r+cCLcV1DuCVEntCf7lmovhtkujYCcy2+fjDWJFwlugsq2iB5uWe2LuDHUzsFaAGa2d7 uGEW4w8z0uhrERD90dUs=; Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebastian-desktop with esmtp (Exim 4.89) (envelope-from ) id 1gFFbt-0001r4-Rk for doh@ietf.org; Wed, 24 Oct 2018 11:37:53 +0200 Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by sebastian-desktop with esmtpa (Exim 4.89) (envelope-from ) id 1gFFbt-0001r0-HN for doh@ietf.org; Wed, 24 Oct 2018 11:37:53 +0200 From: "Sebastian Nielsen" To: Message-ID: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_302_1260088417.1540373873826" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdRreubztp4DjNfDSaWzm+WB9IGnuw== Date: Wed, 24 Oct 2018 11:37:53 +0200 Archived-At: Subject: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 09:37:59 -0000 ------=_Part_302_1260088417.1540373873826 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D46B8E.016C7480" Content-Language: sv This is a multipart message in MIME format. ------=_NextPart_000_0019_01D46B8E.016C7480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have a suggestion for extending the DoH specification: The final endpoint, should be able to act as a authorative and sometimes recursive DoH resolver if it has support for the DoH protocol, during the normal HTTPS connection. This could mean that once you reach a WWW server, theres no need for looking up domains like static.example.org and such since the result of such domains could be returned by the original HTTPS server over the same connection as the website traffic goes over. If the HTTPS server has other domains for example ads.thirdparty-example.org as links it could return those aswell but only if they are DNSSEC signed, and for security, a DoH client should only accept results for a third-party domain if the result is DNSSEC signed. To avoid abuse, a WWW server supporting this extension should only allow queries for its own domain and subdomains, and also queries for any resources it has been configured to resolve (and this type of configuration could be done automatically by for example a script on the web server that adds all external links to its ACL) This would mean an WWW server serving content for itself and also have links to ads.thirdparty-example.org could have those 2 domains cached in its internal DoH resolver and resolve for those, thus once you reach a webpage's server, you no longer need to talk to your recursive DoH serverl, which also increases privacy. This could lead to much faster response times aswell, as the WWW server would have the information about all its linked hosts permanently cached and updated regularly. Think like OCSP stapling but for DNS responses instead. Best regard, Sebastian Nielsen ------=_NextPart_000_0019_01D46B8E.016C7480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a suggestion for extending = the DoH specification:

 

The final endpoint, should be able to act as a authorative = and sometimes recursive DoH resolver if it has support for the DoH = protocol, during the normal HTTPS connection.

 

This could mean that once you reach = a WWW server, theres no need for looking up domains like = static.example.org and such since the result of such domains could be = returned by the original HTTPS server over the same connection as the = website traffic goes over.

If the HTTPS server has other = domains for example ads.thirdparty-example.org as links it could return = those aswell but only if they are DNSSEC signed, and for security, a DoH = client should only accept results for a third-party domain if the result = is DNSSEC signed.

 

To avoid abuse, a WWW server supporting this extension = should only allow queries for its own domain and subdomains, and also = queries for any resources it has been configured to resolve (and this = type of configuration could be done automatically by for example a = script on the web server that adds all external links to its = ACL)

 

This would mean an WWW server serving content for itself = and also have links to ads.thirdparty-example.org could have those 2 = domains cached in its internal DoH resolver and resolve for those, thus = once you reach a webpage’s server, you no longer need to talk to = your recursive DoH serverl, which also increases = privacy.

 

This could lead to much faster response times aswell, as = the WWW server would have the information about all its linked hosts = permanently cached and updated regularly.

Think like OCSP stapling but for = DNS responses instead.

 

 

Best regard, Sebastian = Nielsen

------=_NextPart_000_0019_01D46B8E.016C7480-- ------=_Part_302_1260088417.1540373873826 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIF RTCCBC2gAwIBAgIIY1z1sUcn5kYwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAklUMQ8wDQYD VQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMz NTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcxMB4X DTE3MTExMTAzMzM0OFoXDTE4MTExMTAzMzM0OFowHTEbMBkGA1UEAwwSc2ViYXN0aWFuQHNlYmJl LmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmT1KZ1G4QWcvDCHONMbBynyMsN4A F+8IXSCqu2rpPith70w/KqdILvVDP2denK2tIATLkUPQ7SG2lYzhm1874LDq4Rh2M/dB83sAblGW n1qIFSuYnMFe3jO5XCoN0je0iv/3ASGCQcymhPeeFefGsqpr5btDLKwdZcfZrjqBDLD5hjeqX+f1 Zo5xkPKK0kj9wlBgWzn72IZwZvs0l+bdjVS1bmZFe0+i9R/sgUlNs1/JlfVsXYgPD6ncq7bJCcYN +jFNqR/bQ2sV3rKZXcltiIYROSGnJQ2SOGv/lVQ0wD8OVYqyUuOqMvJBR4sqauclLVRfGKZ1tufR 9qVaQmPsYQIDAQABo4ICITCCAh0wSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8v Y2FjZXJ0LmFjdGFsaXMuaXQvY2VydHMvYWN0YWxpcy1hdXRjbGlnMTAdBgNVHQ4EFgQUzHTxBzTo 9ekiseKvYUaxJVzkzSgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+z dCk79TBHBgNVHSAEQDA+MDwGBiuBHwEYATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3Rh bGlzLml0L2FyZWEtZG93bmxvYWQwgegGA1UdHwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFw MDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENB JTIwRzEsbyUzZEFjdGFsaXMlMjBTLnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBv c2l0b3J5L0FVVEhDTC1HMS9nZXRMYXN0Q1JMMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0RBBYwFIESc2ViYXN0aWFuQHNlYmJlLmV1MA0GCSqGSIb3 DQEBCwUAA4IBAQCyqAPE4i4dsEsMY/Ukxs+ZILWn6t3LXZm8WBsFV4IAZxaS/GW1VhyxJpFbubdN dfaHxxd4ragdfRyjLw+67sz3Av8U0y/jpEjcKWnAzh5Jitd7obF3qzQUaU0r+JVJ4o3gVzEWTmOS ZLUEiFpMtk5rB0BiNaFh0y6RgK7dt7o7VCWle7+pQG2sMrD6cBl9DOLwY1Wqqjj7crzIm2ST7Cfu O/IUy9mFxm4mECcqpehqTA5NKtS3GXGHy1XpU1WhF4BVHakYt3oNZYw9pnzSLLPuEgf72zpbrgN2 j7QfYH0N0eZ4NBi/dBCJ+MXKobPo8OKmRb999p0pTj7cYacRyeI4MIIGRzCCBC+gAwIBAgIILNSK 07EeD4kwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYD VQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50 aWNhdGlvbiBSb290IENBMB4XDTE1MDUxNDA3MTQxNVoXDTMwMDUxNDA3MTQxNVowgYIxCzAJBgNV BAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxp cyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIENBIEcxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwPzBiVbZiOL0BGW/zQk1 qygpMP4MyvcnqxwR7oY9XeT1bES2DFczlZfeiIqNLanbkyqTxydXZ+kxoS9071qWsZ6zS+pxSqXL s+RTvndEaWx5hdHZcKNWGzhy5FiO4GZvGlFInFEiaY+dOEpjjWvSeXpvcDpnYw6M9AXuHo4JhjC3 P/OK//5QFXnztTa4iU66RpLteOTgCtiRCwZNKx8EFeqqfTpYvfEb4H91E7n+Y61jm0d2E8fJ2wGT aSSwjc8nTI2ApXujoczukb2kHqwaGP3q5UuedWcnRZc65XUhK/Z6K32KvrQuNP32F/5MxkvEDnJp Unnt9iMExvEzn31zDQIDAQABo4IB1TCCAdEwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVo dHRwOi8vb2NzcDA1LmFjdGFsaXMuaXQvVkEvQVVUSC1ST09UMB0GA1UdDgQWBBR+YPz4bKc9Pdeu k6F5Ao+zdCk79TAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkC AjbQMEUGA1UdIAQ+MDwwOgYEVR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3RhbGlz Lml0L2FyZWEtZG93bmxvYWQwgeMGA1UdHwSB2zCB2DCBlqCBk6CBkIaBjWxkYXA6Ly9sZGFwMDUu YWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBBdXRoZW50aWNhdGlvbiUyMFJvb3QlMjBDQSxvJTNk QWN0YWxpcyUyMFMucC5BLiUyZjAzMzU4NTIwOTY3LGMlM2RJVD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0O2JpbmFyeTA9oDugOYY3aHR0cDovL2NybDA1LmFjdGFsaXMuaXQvUmVwb3NpdG9yeS9B VVRILVJPT1QvZ2V0TGFzdENSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBAE2T ztUkvkEbShZYc19lifLZej5YjLzLxA/lWxZnssFLpDPySfzMmndz3F06S51ltwDe+blTwcpdzUl3 M2alKH3bOr855ku9Rr6uedya+HGQUT0OhqDo2K2CAE9nBcfANxifjfT8XzCoC3ctf9ux3og1WuE8 WTcLZKgCMuNRBmJte9C4Ug0w3iXqPzq8KuRRobNKqddPjk3EiK+QA+EFCCka1xOLh/7cPGTJMNta 1/0u5oLiXaOAHeALt/nqeZ2kZ+lizK8oTv4in5avIf3ela3oL6vrwpTca7TZxTX90e805dZQN4qR VPdPbrBlWtNozH7SdLeLrcoN8l2EXO6190GAJYdynTc2E6EyrLVGcDKUX91VmCSRrqEppZ7W05Tb WRLi6+wPjAzmTq2XSmKfajq7juTKgkkw7FFJByixa0NdSZosdQb3VkLqG8EOYOamZLqH+v7ua0+u lg7FOviFbeZ7YR9eRO81O8FC1uLgutlyGD2+GLjgQnsvneDsbNAWfkory+qqAxvVzX5PSaQp2pJ5 2AaIH1MN1i2/geRSP83TRMrFkwuIMzDhXxKFQvpspNc19vcTryzjtwP4xq0WNS4YWPS4U+9mW+U0 Cgnsgx9fMiJNbLflf5qSb53j3AGHnjK/qJzPa39wFTXLXB648F3w1Qf9R7eZeTRJfCQY/fJUMIIF uzCCA6OgAwIBAgIIVwoRl0LE48wwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNV BAcMBU1pbGFuMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwwe QWN0YWxpcyBBdXRoZW50aWNhdGlvbiBSb290IENBMB4XDTExMDkyMjExMjIwMloXDTMwMDkyMjEx MjIwMlowazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYDVQQKDBpBY3RhbGlzIFMu cC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50aWNhdGlvbiBSb290IENB MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAp8bEpSmkLO/lGMWwUKNvUTufClrJwkg4 CsIcoBh/kbWHuUA/3R1oHwiD1S0eiKD4j1aPbZkCkpAW1V8IbInX4ay8IMKx4INRimlNAJZaby/A RH6jDuSRzVju3PvHHkVH3Se5CAGfpiEd9UEtL0z9KK3giq0itFZljoZUj5NDKd45RnijMCO6zfB9 E1fAXdKDa0hMxKufgFpbOr3JpyI/gCczWw63igxdBzcIy2zSekciRDXFzMwujt0q7bd9Zg1fYVEi VRvjRuPjPdA1YprbrxTIW6HMiRvhMCb8oJsfgadHHwTrozmSBp+Z07/T6k9QnBn+locePGX2oxgk g4YQ51Q+qDp2JE+BIcXjDwL4k5RHILv+1A7TaLndxHqEguNTVHnd25zS8gebLra8Pu2Fbe8lEfKX GkJh90qX6IuxEAf6ZYGyojnP9zz/GPvG8VqLWeICrHuS0E4UT1lF9gxeKF+w6D9Fz8+vm2/7hNN3 WpVvrJSEnu68wEqPSpP4RCHiMUVhUE4Q2OM1fEwZtN4Fv6MGn8i1zeQf1xcGDXqVdFUNaBr8EBti ZJ1t4JWgw5QHVw0U5r0F+7if5t+L4sbnfpb2U8WANFAoWPASUHEXMLrmeGO89LKtmyuy/uE5jF66 CyCU3nuDuP/jVo23Eek7jPKxwV2dpAtMK9myGPW1n0sCAwEAAaNjMGEwHQYDVR0OBBYEFFLYiDrI n3hm7YnzezhwlMkCAjbQMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiIOsifeGbtifN7 OHCUyQICNtAwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQALe3KHwGCmSUyIWOYd iPcUZEim2FgKDk8TNd81HdTtBjHIgT5q1d07GjLukD0R0i70jsNjLiNmsGe+b7bAEzlgqqI0JZN1 Ut6nna0Oh4lScWoWPBkdg/iaKWW+9D+a2fDzWochcYBNy+A4mz+7+uAwTc+G02UQGRjRlwKxK3JC aKygvU5a2hi/a5iB0P2avl4VSM0RFbnAKVy06Ij3Pjaut2L9HmLecHgQHEhb2rykOLpn7VU+Xlff 1ANATIGk0k9jpwlCCRT8AKnCgHNPLsBA2RF7SOp6AsDT6ygBJlh0wcBzIm2Tlf05fbsq4/aC4yyX X04fkZT6/iyj2HYauE2yOE+b+h1IYHkm4vP9qdCa6HCPSXrW5b0KDtst842/6+OkfcvHlXHo2qN8 xcL4dJIEG4aspCJTQLas/kx2z/uUMsA1n3Y/buWQbqCmJqK4LL7RK4X9p2jIugErsWx0Hbhzlefu t8cl8ABMALJ+tguLHPPAUJ4lueAI3jZm/zel0btUZCzJJ7VLkn5l/9Mt4blOvH+kQSGQQXemOR/q nuOf0GZvBeyqdn6/axag67XH/JJULysRJyU3eExRarDzzFhdFPFqSBX/wge2sY0PjlxQRrM9vwGY T7JZVEc+NHt4bVaTLnPqZih4zR0Uv6CPLy64Lo7yFIrM6bV8+2ydDKXhlgAAMYIC+DCCAvQCAQEw gY8wgYIxCzAJBgNVBAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEG A1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIENBIEcxAghjXPWxRyfmRjANBglghkgBZQMEAgEFAKCCATkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMDI0MDkzNzUzWjAtBgkqhkiG 9w0BCTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCAT jSOFJ33fUGzdbiqWEKfFB0xY5fRPl1SWLxU71+1VKjCBngYJKoZIhvcNAQkPMYGQMIGNMAsGCWCG SAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEEMA0GCyqDCIyaSz0BAQEDMA0GCyqD CIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBCwUABIIBAHpY3BNdJb294ceK3surLaS4 0JTUjOFtYg8rMF68guflMZP5BhTsUktsir6ZmfGpe9sSiiIKHpdSVgD6KoZHjigXdvfi3/Svq8Ov mBJt1crf7q2r0HAyD2J5icbFknxcT/jrNgB9kjYFobSwjS0XC3oHU6IOpySW7QKMBLh+L7w+EEzM m1/AypCSkkXriuRTfepcsSJRWx8u+bqqhnHqRLm6e1LogGnt/5BrbBvrp3Kuz7+vN4NOyJDRs+aV QqkUB7WRDsLuYl2oorKkMsdlG/fW4O43JgAuNLot441YH3sngKFtaCGALN/K6F1UArMrjqDzXHve Cu+gG9RL47vMGkIAAAAAAAA= ------=_Part_302_1260088417.1540373873826-- From nobody Wed Oct 24 02:54:15 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 C2BB2127148 for ; Wed, 24 Oct 2018 02:54:13 -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, 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=wisser.se 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 ZZFKZFBjb1uX for ; Wed, 24 Oct 2018 02:54:11 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 B79CB130E70 for ; Wed, 24 Oct 2018 02:54:10 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id y128-v6so1094779vky.4 for ; Wed, 24 Oct 2018 02:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisser.se; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aD/qc4atSF3pHCy7VUb8qZyMs8sI14BukJfGEUK/IWY=; b=M/rSMHxUGsD+g1f+er2FLyXH6gBLuZV3CadScAnfAgbN/d52hLXEwf2VJcLSEhbo+p K0tbfRrUZyGIkv5gdVT9u+pK2um8/nUC+rcYf0HlVUxB7Gp+5wl5DBDg/d+3FtZRPNRB LY4JLy6VDtxszYZNzigA4DR+3ivTkcAt67i4lxBJ93uJLM+FBGyGbw5BAhnHT5DQkU3A d2EvRpc6N9LXCTgj3c08w5mCK6vodoRYAdaDB/h3rldKsyne7wdzHry55qsmHNn6QPh8 qbheLFgz4mnqnqE31zoKeshLn7yYVXLOWam8qNeQ3Z89CboESLtKKqpReX3llFrGtUIZ iUug== 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=aD/qc4atSF3pHCy7VUb8qZyMs8sI14BukJfGEUK/IWY=; b=OI7WNTOA5xsUuxod+J+A0Tttsgm2edwK/f35Kdnm8Eyb6mafu1/1g+n1FjD5AFVRJT spZLoCkvY1s7GerKjROsh0aPHRL8YOTF/YeqMLnah/SXaOeLAI0elVLHtIMnbSi7dwrc Hkjr9n7SLoGKnwmG3/TQJr37r2QnPpnwrrkL9GSIOkMfd07rmPixxzktAAErhMfoqktG /jCmSt0A2l/WvhUd/8PUWvaMkR3Q5wWyFn9ryXueRE/Hc/qCnaeZ+8AtfijL3+V+xKXK vkTnrUnu7ykYo8c6VNs4w+CJpR5jIQC2zbgGCZrsbNYmobuoUxpD64Aj/SAI57asl8Nb fVgA== X-Gm-Message-State: AGRZ1gJIyxHno3SQ82X2d5UqqzNFtMwkhJZmGuib23UTP0zjGlXzOj1a Q4vwISNs5hsmOKWPmtWvFO601r6NLCrouj7DQWyMbA== X-Google-Smtp-Source: AJdET5e+QIyRV/wH4BN2Y8x50SAh1+9DDWFoJoYl0ZQI7xOy/dpZ9DZ7ygrIDJip5wmRfnfY6qthlFUjfB1OQdh4ssg= X-Received: by 2002:a1f:710:: with SMTP id 16mr224723vkh.42.1540374849548; Wed, 24 Oct 2018 02:54:09 -0700 (PDT) MIME-Version: 1.0 References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> In-Reply-To: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> From: Ulrich Wisser Date: Wed, 24 Oct 2018 11:53:57 +0200 Message-ID: To: Sebastian Nielsen Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba8f270578f677aa" Archived-At: Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 09:54:14 -0000 --000000000000ba8f270578f677aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can see the reason behind this but would like to point out a few details. - clients would have to do dnssec validation - servers would need to not only provide answers to queries, but also the dnssec chain for the validation - what should happen with not dnssec signed answers? Dropped? How will the client get an answer in that case? Additionally, I think it should be made clearer that an endpoint should only answer for a known list of domains, as to not get abused by clients. - what should a server do if a not dnssec signed domain is configured in it's list? /Ulrich Sebastian Nielsen schrieb am Mi., 2= 4. Okt. 2018 um 11:38 Uhr: > I have a suggestion for extending the DoH specification: > > > > The final endpoint, should be able to act as a authorative and sometimes > recursive DoH resolver if it has support for the DoH protocol, during the > normal HTTPS connection. > > > > This could mean that once you reach a WWW server, theres no need for > looking up domains like static.example.org and such since the result of > such domains could be returned by the original HTTPS server over the same > connection as the website traffic goes over. > > If the HTTPS server has other domains for example > ads.thirdparty-example.org as links it could return those aswell but only > if they are DNSSEC signed, and for security, a DoH client should only > accept results for a third-party domain if the result is DNSSEC signed. > > > > To avoid abuse, a WWW server supporting this extension should only allow > queries for its own domain and subdomains, and also queries for any > resources it has been configured to resolve (and this type of configurati= on > could be done automatically by for example a script on the web server tha= t > adds all external links to its ACL) > > > > This would mean an WWW server serving content for itself and also have > links to ads.thirdparty-example.org could have those 2 domains cached in > its internal DoH resolver and resolve for those, thus once you reach a > webpage=E2=80=99s server, you no longer need to talk to your recursive Do= H serverl, > which also increases privacy. > > > > This could lead to much faster response times aswell, as the WWW server > would have the information about all its linked hosts permanently cached > and updated regularly. > > Think like OCSP stapling but for DNS responses instead. > > > > > > Best regard, Sebastian Nielsen > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 Ulrich Wisser ulrich@wisser.se --000000000000ba8f270578f677aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can see the reason behind this but would like to point o= ut a few details.

- clients would have to do dnssec vali= dation
- servers would need to not only provide answers to querie= s, but also the dnssec=C2=A0chain for the validation
- what shoul= d happen with not=C2=A0dnssec=C2=A0signed answers? Dropped? How will the cl= ient get an answer in that case?

Additionally,= I think it should be made clearer that an endpoint should only answer for = a known list of domains, as to not get abused by clients.
- what = should a server do if a not dnssec=C2=A0signed domain is configured in it&#= 39;s list?
=C2=A0
/Ulrich

Sebastian Nielsen <sebastian=3D40sebbe.eu@dmarc.ietf.org> schrieb= am Mi., 24. Okt. 2018 um 11:38=C2=A0Uhr:

I have a suggestion for extending the DoH specification:

=C2=A0

The final endpoint, sho= uld be able to act as a authorative and sometimes recursive DoH resolver if= it has support for the DoH protocol, during the normal HTTPS connection.

= =C2=A0

This co= uld mean that once you reach a WWW server, theres no need for looking up do= mains like static.e= xample.org and such since the result of such domains could be returned = by the original HTTPS server over the same connection as the website traffi= c goes over.

If the HTTPS server has other domains for example ads.thirdparty-example.org= as links it could return those aswell but only if they are DNSSEC signed, = and for security, a DoH client should only accept results for a third-party= domain if the result is DNSSEC signed.

=C2=A0

To avoid abuse, a WWW server supporting th= is extension should only allow queries for its own domain and subdomains, a= nd also queries for any resources it has been configured to resolve (and th= is type of configuration could be done automatically by for example a scrip= t on the web server that adds all external links to its ACL)<= /span>

=C2=A0<= /span>

This would mean an WW= W server serving content for itself and also have links to ads.thirdparty-example.org<= /a> could have those 2 domains cached in its internal DoH resolver and reso= lve for those, thus once you reach a webpage=E2=80=99s server, you no longe= r need to talk to your recursive DoH serverl, which also increases privacy.=

=C2=A0

This c= ould lead to much faster response times aswell, as the WWW server would hav= e the information about all its linked hosts permanently cached and updated= regularly.

Think like OCSP stapling but for DNS responses instead.<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

Best regard, Sebastia= n Nielsen

_____________________________= __________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--
Ulrich Wisser
--000000000000ba8f270578f677aa-- From nobody Wed Oct 24 03:06: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 D1311130EE2 for ; Wed, 24 Oct 2018 03:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu 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 DEh5XVyeGqAO for ; Wed, 24 Oct 2018 03:06:18 -0700 (PDT) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB8A130E86 for ; Wed, 24 Oct 2018 03:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:Cc:To:From; bh=yveUXWVc+lUk6Vu2IiXTN+4tLB1eTxkxODAZzzoVqHo=; b=AZpME09H4zMrswd0acy/rNB8tpoEIr/UoIoBFZ8FsTdowufmEUEmAldXcVpadmvg7xxbKYlldt q4G/y25p9OnmyMClEBXzTr5fjRWPItlqAFx8aT45Pdnrss0Nshgg+nn7PT0+vImTp8q6HtD50u1E8 j1QpihrXxi6Y9Fnf3EuQ=; Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebastian-desktop with esmtp (Exim 4.89) (envelope-from ) id 1gFG3L-0001uU-Fn; Wed, 24 Oct 2018 12:06:15 +0200 Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by sebastian-desktop with esmtpa (Exim 4.89) (envelope-from ) id 1gFG3L-0001uQ-2o; Wed, 24 Oct 2018 12:06:15 +0200 From: "Sebastian Nielsen" To: "'Ulrich Wisser'" , "'Sebastian Nielsen'" Cc: Message-ID: <003601d46b81$341b13d0$9c513b70$@sebbe.eu> In-Reply-To: References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_308_1124527970.1540375575445" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJsIUaNuBL0KKV8fbIZoMpu0AyRxwI3K8v2o+0EZHA= Date: Wed, 24 Oct 2018 12:06:15 +0200 Archived-At: Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 10:06:24 -0000 ------=_Part_308_1124527970.1540375575445 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01D46B91.F7A4CE30" Content-Language: sv This is a multipart message in MIME format. ------=_NextPart_000_0037_01D46B91.F7A4CE30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1: Yes, but the server should supply the whole chain to the root, thus = the client only need to do root validation. 2: yes. 3: The reason to require DNSSEC signature for third-party domains is so = not a hostile WWW server can replace answers to third party domains, for = example loading paypal.com in a frame and then pointing paypal.com to = themselves. =20 4: The server should point this out to the administrator during = configuration. The thing is that the client should refuse to accept = non-DNSSEC signed responses for reason 3. The server could just refuse = queries for domains not DNSSEC signed, like for domains not in the ACL, = but the server should of course keep the domain in the ACL in case it = selects to start DNSSEC signing in the future, but for such domains = cache updating could be done less often, for example weekly. =20 During configuration of the ACL, or startup of the server software, and = if it doesn=E2=80=99t have any cache data written, the server could = simply =E2=80=9Cprime=E2=80=9D the cache by doing one request for all = domains in the ACL, for all record types. =20 Fr=C3=A5n: Doh F=C3=B6r Ulrich Wisser Skickat: den 24 oktober 2018 11:54 Till: Sebastian Nielsen Kopia: doh@ietf.org =C3=84mne: Re: [Doh] Suggestion: The final endpoint should be able to = temporarly act as a recursive DoH resolver =20 I can see the reason behind this but would like to point out a few = details. =20 - clients would have to do dnssec validation - servers would need to not only provide answers to queries, but also = the dnssec chain for the validation - what should happen with not dnssec signed answers? Dropped? How will = the client get an answer in that case? =20 Additionally, I think it should be made clearer that an endpoint should = only answer for a known list of domains, as to not get abused by = clients. - what should a server do if a not dnssec signed domain is configured in = it's list? =20 /Ulrich =20 Sebastian Nielsen > schrieb am Mi., 24. Okt. 2018 um = 11:38 Uhr: I have a suggestion for extending the DoH specification: =20 The final endpoint, should be able to act as a authorative and sometimes = recursive DoH resolver if it has support for the DoH protocol, during = the normal HTTPS connection. =20 This could mean that once you reach a WWW server, theres no need for = looking up domains like static.example.org = and such since the result of such domains could be returned by the = original HTTPS server over the same connection as the website traffic = goes over. If the HTTPS server has other domains for example = ads.thirdparty-example.org as links = it could return those aswell but only if they are DNSSEC signed, and for = security, a DoH client should only accept results for a third-party = domain if the result is DNSSEC signed. =20 To avoid abuse, a WWW server supporting this extension should only allow = queries for its own domain and subdomains, and also queries for any = resources it has been configured to resolve (and this type of = configuration could be done automatically by for example a script on the = web server that adds all external links to its ACL) =20 This would mean an WWW server serving content for itself and also have = links to ads.thirdparty-example.org = could have those 2 domains cached in its internal DoH resolver and = resolve for those, thus once you reach a webpage=E2=80=99s server, you = no longer need to talk to your recursive DoH serverl, which also = increases privacy. =20 This could lead to much faster response times aswell, as the WWW server = would have the information about all its linked hosts permanently cached = and updated regularly. Think like OCSP stapling but for DNS responses instead. =20 =20 Best regard, Sebastian Nielsen _______________________________________________ Doh mailing list Doh@ietf.org =20 https://www.ietf.org/mailman/listinfo/doh --=20 Ulrich Wisser ulrich@wisser.se =20 ------=_NextPart_000_0037_01D46B91.F7A4CE30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

1: Yes, but the server = should supply the whole chain to the root, thus the client only need to = do root validation.

2: = yes.

3: The reason to require DNSSEC = signature for third-party domains is so not a hostile WWW server can = replace answers to third party domains, for example loading paypal.com = in a frame and then pointing paypal.com to = themselves.

 

4: The server should point this out = to the administrator during configuration. The thing is that the client = should refuse to accept non-DNSSEC signed responses for reason 3. The = server could just refuse queries for domains not DNSSEC signed, like for = domains not in the ACL, but the server should of course keep the domain = in the ACL in case it selects to start DNSSEC signing in the future, but = for such domains cache updating could be done less often, for example = weekly.

 

During configuration of the ACL, or = startup of the server software, and if it doesn=E2=80=99t have any cache = data written, the server could simply =E2=80=9Cprime=E2=80=9D the cache = by doing one request for all domains in the ACL, for all record = types.

 

Fr=C3=A5n: Doh <doh-bounces@ietf.org> = F=C3=B6r Ulrich Wisser
Skickat: den 24 oktober 2018 = 11:54
Till: Sebastian Nielsen = <sebastian=3D40sebbe.eu@dmarc.ietf.org>
Kopia: = doh@ietf.org
=C3=84mne: Re: [Doh] Suggestion: The final = endpoint should be able to temporarly act as a recursive DoH = resolver

 

I can see the reason behind this but would like to = point out a few details.

 

- = clients would have to do dnssec validation

- servers would need to not only provide answers to = queries, but also the dnssec chain for the = validation

- what should = happen with not dnssec signed answers? Dropped? How will the = client get an answer in that case?

 

Additionally, I think it should be made clearer that = an endpoint should only answer for a known list of domains, as to not = get abused by clients.

- = what should a server do if a not dnssec signed domain is configured = in it's list?

 

/Ulrich

 

Sebastian Nielsen <sebastian=3D40sebbe.eu@dmarc.ietf.org&g= t; schrieb am Mi., 24. Okt. 2018 um = 11:38 Uhr:

I have a suggestion for extending the DoH = specification:

 

The final endpoint, should be able to act as a authorative = and sometimes recursive DoH resolver if it has support for the DoH = protocol, during the normal HTTPS connection.

 

This could mean that once you reach a WWW server, theres no = need for looking up domains like static.example.org and such since the result of = such domains could be returned by the original HTTPS server over the = same connection as the website traffic goes = over.

If the HTTPS server has other domains for example ads.thirdparty-example.org as links it could = return those aswell but only if they are DNSSEC signed, and for = security, a DoH client should only accept results for a third-party = domain if the result is DNSSEC signed.

 

To avoid abuse, a WWW server supporting this extension = should only allow queries for its own domain and subdomains, and also = queries for any resources it has been configured to resolve (and this = type of configuration could be done automatically by for example a = script on the web server that adds all external links to its = ACL)

 

This would mean an WWW server serving content for itself = and also have links to ads.thirdparty-example.org could have those 2 = domains cached in its internal DoH resolver and resolve for those, thus = once you reach a webpage=E2=80=99s server, you no longer need to talk to = your recursive DoH serverl, which also increases = privacy.

 

This could lead to much faster response times aswell, as = the WWW server would have the information about all its linked hosts = permanently cached and updated regularly.

Think like OCSP stapling but for DNS responses = instead.

 

 

Best regard, Sebastian = Nielsen

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

-- =

Ulrich = Wisser

------=_NextPart_000_0037_01D46B91.F7A4CE30-- ------=_Part_308_1124527970.1540375575445 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIF RTCCBC2gAwIBAgIIY1z1sUcn5kYwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAklUMQ8wDQYD VQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMz NTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcxMB4X DTE3MTExMTAzMzM0OFoXDTE4MTExMTAzMzM0OFowHTEbMBkGA1UEAwwSc2ViYXN0aWFuQHNlYmJl LmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmT1KZ1G4QWcvDCHONMbBynyMsN4A F+8IXSCqu2rpPith70w/KqdILvVDP2denK2tIATLkUPQ7SG2lYzhm1874LDq4Rh2M/dB83sAblGW n1qIFSuYnMFe3jO5XCoN0je0iv/3ASGCQcymhPeeFefGsqpr5btDLKwdZcfZrjqBDLD5hjeqX+f1 Zo5xkPKK0kj9wlBgWzn72IZwZvs0l+bdjVS1bmZFe0+i9R/sgUlNs1/JlfVsXYgPD6ncq7bJCcYN +jFNqR/bQ2sV3rKZXcltiIYROSGnJQ2SOGv/lVQ0wD8OVYqyUuOqMvJBR4sqauclLVRfGKZ1tufR 9qVaQmPsYQIDAQABo4ICITCCAh0wSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8v Y2FjZXJ0LmFjdGFsaXMuaXQvY2VydHMvYWN0YWxpcy1hdXRjbGlnMTAdBgNVHQ4EFgQUzHTxBzTo 9ekiseKvYUaxJVzkzSgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+z dCk79TBHBgNVHSAEQDA+MDwGBiuBHwEYATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3Rh bGlzLml0L2FyZWEtZG93bmxvYWQwgegGA1UdHwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFw MDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENB JTIwRzEsbyUzZEFjdGFsaXMlMjBTLnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBv c2l0b3J5L0FVVEhDTC1HMS9nZXRMYXN0Q1JMMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0RBBYwFIESc2ViYXN0aWFuQHNlYmJlLmV1MA0GCSqGSIb3 DQEBCwUAA4IBAQCyqAPE4i4dsEsMY/Ukxs+ZILWn6t3LXZm8WBsFV4IAZxaS/GW1VhyxJpFbubdN dfaHxxd4ragdfRyjLw+67sz3Av8U0y/jpEjcKWnAzh5Jitd7obF3qzQUaU0r+JVJ4o3gVzEWTmOS ZLUEiFpMtk5rB0BiNaFh0y6RgK7dt7o7VCWle7+pQG2sMrD6cBl9DOLwY1Wqqjj7crzIm2ST7Cfu O/IUy9mFxm4mECcqpehqTA5NKtS3GXGHy1XpU1WhF4BVHakYt3oNZYw9pnzSLLPuEgf72zpbrgN2 j7QfYH0N0eZ4NBi/dBCJ+MXKobPo8OKmRb999p0pTj7cYacRyeI4MIIGRzCCBC+gAwIBAgIILNSK 07EeD4kwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYD VQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50 aWNhdGlvbiBSb290IENBMB4XDTE1MDUxNDA3MTQxNVoXDTMwMDUxNDA3MTQxNVowgYIxCzAJBgNV BAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxp cyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIENBIEcxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwPzBiVbZiOL0BGW/zQk1 qygpMP4MyvcnqxwR7oY9XeT1bES2DFczlZfeiIqNLanbkyqTxydXZ+kxoS9071qWsZ6zS+pxSqXL s+RTvndEaWx5hdHZcKNWGzhy5FiO4GZvGlFInFEiaY+dOEpjjWvSeXpvcDpnYw6M9AXuHo4JhjC3 P/OK//5QFXnztTa4iU66RpLteOTgCtiRCwZNKx8EFeqqfTpYvfEb4H91E7n+Y61jm0d2E8fJ2wGT aSSwjc8nTI2ApXujoczukb2kHqwaGP3q5UuedWcnRZc65XUhK/Z6K32KvrQuNP32F/5MxkvEDnJp Unnt9iMExvEzn31zDQIDAQABo4IB1TCCAdEwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVo dHRwOi8vb2NzcDA1LmFjdGFsaXMuaXQvVkEvQVVUSC1ST09UMB0GA1UdDgQWBBR+YPz4bKc9Pdeu k6F5Ao+zdCk79TAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkC AjbQMEUGA1UdIAQ+MDwwOgYEVR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3RhbGlz Lml0L2FyZWEtZG93bmxvYWQwgeMGA1UdHwSB2zCB2DCBlqCBk6CBkIaBjWxkYXA6Ly9sZGFwMDUu YWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBBdXRoZW50aWNhdGlvbiUyMFJvb3QlMjBDQSxvJTNk QWN0YWxpcyUyMFMucC5BLiUyZjAzMzU4NTIwOTY3LGMlM2RJVD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0O2JpbmFyeTA9oDugOYY3aHR0cDovL2NybDA1LmFjdGFsaXMuaXQvUmVwb3NpdG9yeS9B VVRILVJPT1QvZ2V0TGFzdENSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBAE2T ztUkvkEbShZYc19lifLZej5YjLzLxA/lWxZnssFLpDPySfzMmndz3F06S51ltwDe+blTwcpdzUl3 M2alKH3bOr855ku9Rr6uedya+HGQUT0OhqDo2K2CAE9nBcfANxifjfT8XzCoC3ctf9ux3og1WuE8 WTcLZKgCMuNRBmJte9C4Ug0w3iXqPzq8KuRRobNKqddPjk3EiK+QA+EFCCka1xOLh/7cPGTJMNta 1/0u5oLiXaOAHeALt/nqeZ2kZ+lizK8oTv4in5avIf3ela3oL6vrwpTca7TZxTX90e805dZQN4qR VPdPbrBlWtNozH7SdLeLrcoN8l2EXO6190GAJYdynTc2E6EyrLVGcDKUX91VmCSRrqEppZ7W05Tb WRLi6+wPjAzmTq2XSmKfajq7juTKgkkw7FFJByixa0NdSZosdQb3VkLqG8EOYOamZLqH+v7ua0+u lg7FOviFbeZ7YR9eRO81O8FC1uLgutlyGD2+GLjgQnsvneDsbNAWfkory+qqAxvVzX5PSaQp2pJ5 2AaIH1MN1i2/geRSP83TRMrFkwuIMzDhXxKFQvpspNc19vcTryzjtwP4xq0WNS4YWPS4U+9mW+U0 Cgnsgx9fMiJNbLflf5qSb53j3AGHnjK/qJzPa39wFTXLXB648F3w1Qf9R7eZeTRJfCQY/fJUMIIF uzCCA6OgAwIBAgIIVwoRl0LE48wwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNV BAcMBU1pbGFuMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwwe QWN0YWxpcyBBdXRoZW50aWNhdGlvbiBSb290IENBMB4XDTExMDkyMjExMjIwMloXDTMwMDkyMjEx MjIwMlowazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYDVQQKDBpBY3RhbGlzIFMu cC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50aWNhdGlvbiBSb290IENB MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAp8bEpSmkLO/lGMWwUKNvUTufClrJwkg4 CsIcoBh/kbWHuUA/3R1oHwiD1S0eiKD4j1aPbZkCkpAW1V8IbInX4ay8IMKx4INRimlNAJZaby/A RH6jDuSRzVju3PvHHkVH3Se5CAGfpiEd9UEtL0z9KK3giq0itFZljoZUj5NDKd45RnijMCO6zfB9 E1fAXdKDa0hMxKufgFpbOr3JpyI/gCczWw63igxdBzcIy2zSekciRDXFzMwujt0q7bd9Zg1fYVEi VRvjRuPjPdA1YprbrxTIW6HMiRvhMCb8oJsfgadHHwTrozmSBp+Z07/T6k9QnBn+locePGX2oxgk g4YQ51Q+qDp2JE+BIcXjDwL4k5RHILv+1A7TaLndxHqEguNTVHnd25zS8gebLra8Pu2Fbe8lEfKX GkJh90qX6IuxEAf6ZYGyojnP9zz/GPvG8VqLWeICrHuS0E4UT1lF9gxeKF+w6D9Fz8+vm2/7hNN3 WpVvrJSEnu68wEqPSpP4RCHiMUVhUE4Q2OM1fEwZtN4Fv6MGn8i1zeQf1xcGDXqVdFUNaBr8EBti ZJ1t4JWgw5QHVw0U5r0F+7if5t+L4sbnfpb2U8WANFAoWPASUHEXMLrmeGO89LKtmyuy/uE5jF66 CyCU3nuDuP/jVo23Eek7jPKxwV2dpAtMK9myGPW1n0sCAwEAAaNjMGEwHQYDVR0OBBYEFFLYiDrI n3hm7YnzezhwlMkCAjbQMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiIOsifeGbtifN7 OHCUyQICNtAwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQALe3KHwGCmSUyIWOYd iPcUZEim2FgKDk8TNd81HdTtBjHIgT5q1d07GjLukD0R0i70jsNjLiNmsGe+b7bAEzlgqqI0JZN1 Ut6nna0Oh4lScWoWPBkdg/iaKWW+9D+a2fDzWochcYBNy+A4mz+7+uAwTc+G02UQGRjRlwKxK3JC aKygvU5a2hi/a5iB0P2avl4VSM0RFbnAKVy06Ij3Pjaut2L9HmLecHgQHEhb2rykOLpn7VU+Xlff 1ANATIGk0k9jpwlCCRT8AKnCgHNPLsBA2RF7SOp6AsDT6ygBJlh0wcBzIm2Tlf05fbsq4/aC4yyX X04fkZT6/iyj2HYauE2yOE+b+h1IYHkm4vP9qdCa6HCPSXrW5b0KDtst842/6+OkfcvHlXHo2qN8 xcL4dJIEG4aspCJTQLas/kx2z/uUMsA1n3Y/buWQbqCmJqK4LL7RK4X9p2jIugErsWx0Hbhzlefu t8cl8ABMALJ+tguLHPPAUJ4lueAI3jZm/zel0btUZCzJJ7VLkn5l/9Mt4blOvH+kQSGQQXemOR/q nuOf0GZvBeyqdn6/axag67XH/JJULysRJyU3eExRarDzzFhdFPFqSBX/wge2sY0PjlxQRrM9vwGY T7JZVEc+NHt4bVaTLnPqZih4zR0Uv6CPLy64Lo7yFIrM6bV8+2ydDKXhlgAAMYIC+DCCAvQCAQEw gY8wgYIxCzAJBgNVBAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEG A1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIENBIEcxAghjXPWxRyfmRjANBglghkgBZQMEAgEFAKCCATkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMDI0MTAwNjE1WjAtBgkqhkiG 9w0BCTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBp hooRyJycXUZvenOGRH8Dz9fLqBiLgy+fzBZ/ALIT3DCBngYJKoZIhvcNAQkPMYGQMIGNMAsGCWCG SAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEEMA0GCyqDCIyaSz0BAQEDMA0GCyqD CIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBCwUABIIBAGQEJNgloWL3YN+yGXp+oYBt YpOnnf1Rl6LjGj/ER4lqOsOCESXKUpcvb+Q+BzsWxC0dkwyQkd/FL+3wUSkIFL9new4EaQzSd1Ld biJOGYB9bz4svF78sEu1D3NOvO2loffkI6iuf20ZsZYicS+TPy5iqx+48WtDzkFvIEd4VHV5Tn9O 6NQv4j6baT7T/Jpw4FggoZlty6wcbkcEEet/bRwGmol+MNxIonWTCQghGJyv8jtsvaKlVeaJXg0t up/hWXmANxLmvMjIOpDh+GuxebbDAnXV8Tyu8wsO6yUf6Ufdnitf+RvZOlacj9tHWo1GPkBwKOY2 l/eMbk+XCURy+5EAAAAAAAA= ------=_Part_308_1124527970.1540375575445-- From nobody Wed Oct 24 04:24: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 091B0130DF3 for ; Wed, 24 Oct 2018 04:24: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] 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 nIOy0MUisWVd for ; Wed, 24 Oct 2018 04:24:41 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 6AB76130DF5 for ; Wed, 24 Oct 2018 04:24:41 -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]:54242) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gFHH2-000BJv-1y (Exim 4.91) (return-path ); Wed, 24 Oct 2018 12:24:37 +0100 Date: Wed, 24 Oct 2018 12:24:28 +0100 From: Tony Finch To: Paul Hoffman cc: Martin Thomson , DoH WG In-Reply-To: <67726F45-C947-48ED-B6ED-ABE2BD547AB1@icann.org> Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <67726F45-C947-48ED-B6ED-ABE2BD547AB1@icann.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 11:24:45 -0000 Paul Hoffman wrote: > On Oct 23, 2018, at 6:10 PM, Martin Thomson wrote: > > > > Oh, I forgot. IP-based certificates complicate things considerably, > > and will make this impossible to deploy in many cases (think of the > > many resolvers with 1918 addresses, for example). > > They don't make it "impossible" by a long shot. Plenty of resolvers, > even corporate resolvers, have public addresses. Both of our CAs will not give us iPAddress certificates. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: West 5 to 7, occasionally gale 8 until later. Rough or very rough. Occasional rain. Good occasionally poor. From nobody Wed Oct 24 09:10: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 90498130E16 for ; Wed, 24 Oct 2018 09:09:59 -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, 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 (1024-bit key) header.d=ducksong.com header.b=enkm19t2; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=C0cuCk/l 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 tnmoAVQruxk8 for ; Wed, 24 Oct 2018 09:09:57 -0700 (PDT) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 12ED31286E7 for ; Wed, 24 Oct 2018 09:09:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540397395; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=kbxoPrqM2x7kUH9lQDbT2T9EWXUOSS+9+GAa0Cz5Q+qvOE1vMdej9CpUWigxIP7Ox61FUiy9yFVcc 532ncw6CFCD0yZtuXisN/csFT+Z0SrdxR0RsfMn0oQXv8ubsEfvegQyx3ZZfbYJONR+CCjUMCdKjZ9 tyjpt0zrnW0Al9Fg8xZvQ1zPpJoEksmq+R0CJOMrAlz51klrp5e+ERkBk5s43mJJLx7eGDKL+QToXB HbUO/MlgcVZMxFpSP6G2+iE57N7qnMr1FxKJNCDwijwxqC1HM2k9MhUHNIt0gIWIXX/gBW/gzR3uTX PHgtCl2WZe+R7hvICDXjZTsa9DW4+BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=/KLfHK2pkOAzCgJQbpGfnDtZ0qoqmzOrJAYVMsPMW+c=; b=qVGg+RyUTxivXGLQUcT/NBDAuUjxeIAcDOUx8YWQsM3z5rZiQG6QRhT7iuaf3jdAaJM/tYPbn36Oq YKtoL+lTPAARSGWfAQssdozaI+FXUP++JpUTLxaBdvZ6b8gMKat4dQnvKQ+5qhJLc5Op/XeOLM8Rgt bw9rxgz66Mz3UfbumspwEdyxEU4J0kHTVi93Fc93v63jQsuIsjrKAFlhREYc7DZv/X0dFLVJIxfbTJ 8MlGetqhGBdkWi3pTq2i8IKqluogurGSMF90Dw8SkssZCs/snn47ex8wSK9I79xLlHke/1SiCS376y ua4zPKhe1c5J7ZY8YDqmMY+DDYyqFag== ARC-Authentication-Results: i=1; outbound1.eu.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.179; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=/KLfHK2pkOAzCgJQbpGfnDtZ0qoqmzOrJAYVMsPMW+c=; b=enkm19t2JjImYf+rT0nNz3b9j6wQlUm7zC+9jptEawLyQ9zE3rSFbwsJGx//Pchtt2KGT7+e2NeJ8 ABuZnB1HidlBBH5BByeG1XFVXp55/oJm0sK1m97zbcBSHQglb/cYhalh3a3EKHPUGOOE2BxnL1liN4 +qKmWNP5QgyyDsl4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=/KLfHK2pkOAzCgJQbpGfnDtZ0qoqmzOrJAYVMsPMW+c=; b=C0cuCk/lgM0QBZjwYlQumV5RE4LjUyQFFLj5vdaoS7sj6TQ7b9eYTT5mq8nxGvBhZlqnv4loXwh+4 7v4v2DFTL/73BnEFQvO2qALJN7vZRVpDEnUY0DU24ibjAJ8CrWQ0eIELKbG0W/PEIkMwykSS2fWXL1 anxP1z4uOgh1xwnB8w/wk21X4yqOPJI17d3Evmq3m1CWBETpind12wtCIHWsL6eNDxmQJQTY0yC8Sw glpHenPa0WmsBoGVi1qjAAePTp9oY0FqgkNy8UciY4+r57c+AlcpG21nGuQqbnEz1LZpXQq42QIZ5z 1Zc+Q7+f2U+ON2mZbjJoCoQTGCS92Gg== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 3c0d3105-d7a7-11e8-9048-075f73944867 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.179 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f179.google.com (unknown [209.85.167.179]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 3c0d3105-d7a7-11e8-9048-075f73944867; Wed, 24 Oct 2018 16:09:52 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id j68-v6so4533344oib.7 for ; Wed, 24 Oct 2018 09:09:51 -0700 (PDT) X-Gm-Message-State: AGRZ1gKnvWRt5QfwnHVboI375j6g6p0B8tcnsaLDltRAdM8IMS2ZFVbh p4PTidAdHlJK6+DXjvQ3tC/xvSFyrcvTZMmzXwo= X-Google-Smtp-Source: AJdET5dGJWOEs2DOoDX5imorGgFi+i+wi2z5ErJJTYeC+IYNvk0ZrWdZ09AQkykEg15/aBdP4rVN9Uys3LLgmmd01Wc= X-Received: by 2002:aca:1c6:: with SMTP id 189-v6mr1821931oib.325.1540397389869; Wed, 24 Oct 2018 09:09:49 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: From: Patrick McManus Date: Wed, 24 Oct 2018 12:09:38 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Martin Thomson , DoH WG Content-Type: multipart/alternative; boundary="0000000000003c7a100578fbb7e6" Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:10:00 -0000 --0000000000003c7a100578fbb7e6 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 23, 2018 at 9:12 PM Paul Hoffman wrote: > > There is no way for an application like a browser to send a query through > the OS for anything other than address records. That is, gethostbyname() > and its equivalents only pass back address records good news - that's not true. The concern is that other APIs often are DNS only (and therefore break compatibility with other naming systems like netbios, whatever).. however in the case that you're specifically looking for DNS resolvers, that doesn't seem like a problem. However I disagree with the premise of the work - browsers I have spoken with do not seek to find a DoH version of a resolver that was discovered from a broadcast address over a network that wasn't authenticated in the first place and has an unknown trust relationship with the user in the second case. --0000000000003c7a100578fbb7e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 23= , 2018 at 9:12 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

There is no way for an application like a browser to send a query through t= he OS for anything other than address records. That is, gethostbyname() and= its equivalents only pass back address records

=
good news - that's not true. The concern is that other APIs often = are DNS only (and therefore break compatibility with other naming systems l= ike netbios, whatever).. however in the case that you're specifically l= ooking for DNS resolvers, that doesn't seem like a problem.
<= br>
However I disagree with the premise of the work - browsers I = have spoken with do not seek to find a DoH version of a resolver that was d= iscovered from a broadcast address over a network that wasn't authentic= ated in the first place and has an unknown trust relationship with the user= in the second case.

--0000000000003c7a100578fbb7e6-- From nobody Wed Oct 24 09:11: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 7722412F18C for ; Wed, 24 Oct 2018 09: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 kp38upT_eW4Q for ; Wed, 24 Oct 2018 09:11:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.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 68A721286E7 for ; Wed, 24 Oct 2018 09:11:14 -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.1367.3; Wed, 24 Oct 2018 09:11: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.1367.000; Wed, 24 Oct 2018 09:11:11 -0700 From: Paul Hoffman To: Martin Thomson CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUazgJ4S1vkhYJeE6Wms1zHwXRAqUvB0MA Date: Wed, 24 Oct 2018 16:11:10 +0000 Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_6C60B534-4781-4BD3-A545-0A6D72E597AA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:11:16 -0000 --Apple-Mail=_6C60B534-4781-4BD3-A545-0A6D72E597AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 6:22 PM, Martin Thomson = wrote: >=20 > On Wed, Oct 24, 2018 at 12:12 PM Paul Hoffman = wrote: >> There is no way for an application like a browser to send a query = through the OS for anything other than address records. That is, = gethostbyname() and its equivalents only pass back address records. Even = if an application had its own DNS stack to make queries for other = RRtypes, it doesn't have any way to know where to send them to. >=20 > Well, resolver-addresses.arpa./IN/A(AAA) might still be useful for > that then. That's not ideal, but I believe that there are ways to > make queries for other record types that are more available now than > perhaps there were in the past (see > = https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsq= uery_a > for example). I certainly don't want to preclude one-step ways of getting the = associated URI templates in a single step, but I also don't want to only = have the ability to get associated DoH servers be limited to browsers = (because web applications can't call OS APIs), nor limited to browsers = that are running on OSes that support sending TXT (or TXT-like) queries.=20= >=20 >>> IP-based certificates [...] impossible to deploy in many cases = (think of the many resolvers with 1918 addresses, for example). >>=20 >> They don't make it "impossible" by a long shot. Plenty of resolvers, = even corporate resolvers, have public addresses. >=20 > True, it is probably still possible, but it's not like you can just > use ACME to get the certificate. That's "possible" in theory, but I'm > looking for practicable. You should be able to use ACME in the future to get an IP-based = certificate. draft-ietf-acme-ip has been submitted to the IESG for = publication. --Paul Hoffman= --Apple-Mail=_6C60B534-4781-4BD3-A545-0A6D72E597AA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE2MTExMVowIwYJKoZIhvcNAQkEMRYEFN1OGhFvH99ENrSIR2UlNi98CfC3MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQBLaW7hfLwvnwS0qHVT1LfLFv9AsTZH9KlYA/g8kRcdEQRJWjBL3tWw8RC2KPfTjqIeU5yD 2zT3d5+f8L7HcNeqeqgTGXV2PVAJ7/Bj+ELXFG2bsMbbe3tiDFjPiPqMxo/ECdgzcLTYUznBwmMP 4FstKAK0hqLSWpcyRasMpdj7hKxs+lpESfB/+iD9I6uQ7O8SwmEyQk/eavhJU22oRyF4HHiIR7wK wBHMz77OiRSlkU/NhsI68fcHj8skg0LgwS+tpPe9htL1hvsUrg3hVZ/mVSpyOrxEuFF8IbCb0hIU BcEHNUOHEdVi177eGFZO/EsZ5kYuoUGrbeKTgX7TaBL3AAAAAAAA --Apple-Mail=_6C60B534-4781-4BD3-A545-0A6D72E597AA-- From nobody Wed Oct 24 09:11:31 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 B8AFA130934 for ; Wed, 24 Oct 2018 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 xf_syUVlRNQe for ; Wed, 24 Oct 2018 09:11:28 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.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 EF5C21286E7 for ; Wed, 24 Oct 2018 09:11:27 -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.1367.3; Wed, 24 Oct 2018 09:11: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.1367.000; Wed, 24 Oct 2018 09:11:26 -0700 From: Paul Hoffman To: Eric Rescorla CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUa0hXLZIOUPksW0KFptJhvlWHNqUvBzSA Date: Wed, 24 Oct 2018 16:11:25 +0000 Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_376C0DBE-12CB-4B81-A2E6-475BE2254F70"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:11:30 -0000 --Apple-Mail=_376C0DBE-12CB-4B81-A2E6-475BE2254F70 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB828B3C-C0B8-446A-8E81-2570D9EB3CAE" --Apple-Mail=_FB828B3C-C0B8-446A-8E81-2570D9EB3CAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 8:18 PM, Eric Rescorla wrote: > Several points here: >=20 > 1. As a matter of aesthetics, I agree with Martin that domain names = would be better. If we can get non-address records back, I would prefer to go all the way = to "here are the URI templates of the DoH servers". No need to cause = another round-trip. > 2. Martin sent a link to a method for resolving TXT records on = Windows. MacOS has its own API: = https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrec= ord?language=3Dobjc [developer.apple.com] = . > So, this doesn't seem prohibitive to me. I thought this only worked for DNSSD, not DNS. Does it work for both? Or = is there a similar-flavored Mac call for DNS? > 3. It seems like in the use case for which this draft is specified, = the whole thing is pretty opportunistic, so IP address certs wouldn't be = required. Agree. In the future, when an application can know that the OS's = connection to the DNS resolver is authenticated, then IP address certs = could be used for fully-authenticated communication. That doesn't seem = likely any time soon, however, given the results of the discussions at = the DRIU BoF at the last IETF meeting. > 4. There are other uses cases for which it might be nice to have real = domain names, in which case the IP address cert thing is a pain. >=20 > For these reasons, I think a domain name in TXT or the like would be = better. Do you see a use case for domain names other than "here's a way to get = to a well-known URI on the resolver"? If so, we could add that as well = as "here are the URI templates for the associated DoH server. --Paul Hoffman= --Apple-Mail=_FB828B3C-C0B8-446A-8E81-2570D9EB3CAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 23, 2018, at 8:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Several points here:

1. As a = matter of aesthetics, I agree with Martin that domain names would be = better.

If we can get = non-address records back, I would prefer to go all the way to "here are = the URI templates of the DoH servers". No need to cause another = round-trip.

2. Martin sent a = link to a method for resolving TXT records on Windows. MacOS has its own = API: https://developer.apple.com/documentation/dnssd/1804747-dnsserv= icequeryrecord?language=3Dobjc [developer.apple.com].
So, this doesn't seem prohibitive to = me.

I thought this only worked for DNSSD, not DNS. Does it = work for both? Or is there a similar-flavored Mac call for = DNS?

3. It = seems like in the use case for which this draft is specified, the whole = thing is pretty opportunistic, so IP address certs wouldn't be = required.

Agree. In the future, when an = application can know that the OS's connection to the DNS resolver is = authenticated, then IP address certs could be used for = fully-authenticated communication. That doesn't seem likely any time = soon, however, given the results of the discussions at the DRIU BoF at = the last IETF meeting.

4. = There are other uses cases for which it might be nice to have real = domain names, in which case the IP address cert thing is a = pain.

For = these reasons, I think a domain name in TXT or the like would be = better.

Do you see a use case for domain names = other than "here's a way to get to a well-known URI on the resolver"? If = so, we could add that as well as "here are the URI templates for the = associated DoH server.

--Paul Hoffman
= --Apple-Mail=_FB828B3C-C0B8-446A-8E81-2570D9EB3CAE-- --Apple-Mail=_376C0DBE-12CB-4B81-A2E6-475BE2254F70 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE2MTEyNVowIwYJKoZIhvcNAQkEMRYEFKHk/XcV99jXp6RCA8cU0uL0Ua4UMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQCOkPjMHC4mq7DYwvjD3pTKC7ITtWkmFWQOGpTpKsAHZLyCwBQlp53G5G+cXk8O1y7bkOby C1agHrBiG8YNhpQvTHnLbGimIsTUJEnJOpoC3IhfyHy8FyYYMoVSWnWwWlNImrw7BG8aF8u06Mta EE+keTbufXtA65Zhd4YIR9vaJCY6mPplBq/Hij6+fRQQiv2Au4hDsJD8W1A8rpWQMW2T9QiheNP5 HLFqXfyrX1DARCUoqY8uwji0wRyN1eZqH/yHSjj5PByHMVK9bvSc1a0qd6gwFXKFlQ7EfFs8a02l GUWD5nOVQ+dYwakthiFSbrCzi0xWQ0ao4X657l+ld4LfAAAAAAAA --Apple-Mail=_376C0DBE-12CB-4B81-A2E6-475BE2254F70-- From nobody Wed Oct 24 09:18: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 ECC9C130DC9 for ; Wed, 24 Oct 2018 09:18:20 -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 rD63fLzS3Dat for ; Wed, 24 Oct 2018 09:18:19 -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 83A5D130934 for ; Wed, 24 Oct 2018 09:18:19 -0700 (PDT) Received: from Svantevit.attlocal.net (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 w9OGHu9V025883 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Oct 2018 11:17:57 -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 Svantevit.attlocal.net To: Paul Hoffman , Martin Thomson Cc: DoH WG References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> From: Adam Roach Message-ID: Date: Wed, 24 Oct 2018 11:17:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:18:21 -0000 On 10/24/18 11:11 AM, Paul Hoffman wrote: > You should be able to use ACME in the future to get an IP-based certificate. draft-ietf-acme-ip has been submitted to the IESG for publication. And CAB forum rules have allowed issuance of such certs for quite a while now. The issue isn't technology or permission -- it's CA policies. I think you'd need to find CAs willing to issue such certs before you feel comfortable predicating a technology on them. /a From nobody Wed Oct 24 09:19: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 8ED6C130DFF for ; Wed, 24 Oct 2018 09:19:18 -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 veq0dg0Tw7oZ for ; Wed, 24 Oct 2018 09:19:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A3E130DF0 for ; Wed, 24 Oct 2018 09:19:16 -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.1367.3; Wed, 24 Oct 2018 09:19:14 -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.1367.000; Wed, 24 Oct 2018 09:19:14 -0700 From: Paul Hoffman To: Adam Roach CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUa0hXLZIOUPksW0KFptJhvlWHNqUuNTGAgADUMgA= Date: Wed, 24 Oct 2018 16:19:14 +0000 Message-ID: <9C56CE46-C0CF-4CB0-A7B6-7287661AE2B4@icann.org> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <2695a0e8-8373-8d33-7951-cfc5555ed254@nostrum.com> In-Reply-To: <2695a0e8-8373-8d33-7951-cfc5555ed254@nostrum.com> 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=_E25CBEFE-2A86-434D-8A9F-8B62CD0D8DC2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:19:19 -0000 --Apple-Mail=_E25CBEFE-2A86-434D-8A9F-8B62CD0D8DC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 23, 2018, at 8:39 PM, Adam Roach wrote: > If we are going for non-A/AAAA record types, then I would suggest that = we use the record to directly indicate the URI instead of having to = synthesize one using a .well-known path. I would also point out that we = already have a resource record type for converting desired services into = URIs (RFC 7553). >=20 > So, e.g., interested clients would query for a URI record of type = _doh._tcp.resolvers.arpa, and get back a full HTTPS URL as a response. Using the URI RRtype is a possibility as long as we are sure that all = the APIs that allow sending names with underscores (that is, names that = are not hostnames). If not, then TXT or a new purpose-based RRtype that = is like TXT would be better. --Paul Hoffman= --Apple-Mail=_E25CBEFE-2A86-434D-8A9F-8B62CD0D8DC2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE2MTkxNVowIwYJKoZIhvcNAQkEMRYEFGUyOMCbdnBzw6VnzldRk5SaY8HgMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAt8LAQD7/CI8ni9VvAQItfVGAMKea7Sy0xCHwW1IpMFV9XisBCq73jJWScuyU+CHCWTy60 +qti9zgNmMjumKXS5bNNSf+2++mHEr+fKzEiFLoG6vm5JL0YWgPu1p6YrWytYy7vOs/Z2sWRdtVX pAje7eXb9edI0rp8bADWp5V3N+LktmE/zDljE4AN60DiyB8tqWr/4JnnRIHzkrbgsEhEAuJkJy8u 727qAZ8UtmpDFIGc4g1kdKLahClYgqPH+B5glupusN0b5T6F9xDydtJVDWiHdHUMGIfVQMw2uVU/ 3lC1LMVDij7Cx2p49vK/Rnt3F8ldKgGi6nLWagBoelNTAAAAAAAA --Apple-Mail=_E25CBEFE-2A86-434D-8A9F-8B62CD0D8DC2-- From nobody Wed Oct 24 09:22: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 A9C1E130EF9 for ; Wed, 24 Oct 2018 09:22:00 -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 07gA78t8xRyc for ; Wed, 24 Oct 2018 09:21:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.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 11DE8130E7E for ; Wed, 24 Oct 2018 09:21: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.1367.3; Wed, 24 Oct 2018 09:21: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.1367.000; Wed, 24 Oct 2018 09:21:56 -0700 From: Paul Hoffman To: Patrick McManus CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUa7QG03ScnvnAGUuOIe8oqDpQI6UvCUsA Date: Wed, 24 Oct 2018 16:21:55 +0000 Message-ID: <5A1CDF26-7A0B-4A65-8117-0AE63A99AD4C@icann.org> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_76190BBC-96D1-4852-8919-310C9D9D1E40"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:22:04 -0000 --Apple-Mail=_76190BBC-96D1-4852-8919-310C9D9D1E40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2018, at 9:09 AM, Patrick McManus = wrote: > However I disagree with the premise of the work - browsers I have = spoken with do not seek to find a DoH version of a resolver that was = discovered from a broadcast address over a network that wasn't = authenticated in the first place and has an unknown trust relationship = with the user in the second case. I would want to hear that directly from the browser vendors before = abandoning this work, particularly because we are hearing a lot of = interest from organizations who want it. Also, even if the browser = vendors didn't want it, web application providers might want it. --Paul Hoffman= --Apple-Mail=_76190BBC-96D1-4852-8919-310C9D9D1E40 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE2MjE1NVowIwYJKoZIhvcNAQkEMRYEFKBMgisTwW7Ft1PygRQ7PFqNeJSSMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQANTxZ5D6bXcOHVTKCJksE+Q9G5zz0QfTHpGctS4dg5dtD4D5AYJhS56UH5HZ4B7EwApaKE qx6t8G17zoKaFCGfYT9ronxA+BQ997y2+EWsdsEJSIG9GITfn73x+6c/O5RDLqoMJNDTyYxrPJIh pHn+mEB2fPBx1hYrn3SM3bVKUdRjc7kMZc5beFWANbMCQ3rtkWpQbxcmQ/mU6eDkKnsj89t7JPXG vI/nqgjYvUHEHS0wJrKI9hZcpTIapGHMcPpwHIoOqSoHkk09GALzoY8JtZwhv8bvjKzc9NFvLI+c 68UDQ54xyxqYGzYk4h6CGe93GXa/JcKksIoMm3zR2ngzAAAAAAAA --Apple-Mail=_76190BBC-96D1-4852-8919-310C9D9D1E40-- From nobody Wed Oct 24 09:24: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 C6757130E02 for ; Wed, 24 Oct 2018 09:24:15 -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 AJ_m-FFAK1ry for ; Wed, 24 Oct 2018 09:24:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D42130DF0 for ; Wed, 24 Oct 2018 09:24:14 -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.1367.3; Wed, 24 Oct 2018 09:24: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.1367.000; Wed, 24 Oct 2018 09:24:12 -0700 From: Paul Hoffman To: Adam Roach CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUa7UvSo5WfKDXeEqFP1wNfOnvHKUvCeyA Date: Wed, 24 Oct 2018 16:24:11 +0000 Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_6AF34F9C-898A-4179-A443-204A291A882B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:24:16 -0000 --Apple-Mail=_6AF34F9C-898A-4179-A443-204A291A882B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2018, at 9:17 AM, Adam Roach wrote: > And CAB forum rules have allowed issuance of such certs for quite a = while now. The issue isn't technology or permission -- it's CA policies. = I think you'd need to find CAs willing to issue such certs before you = feel comfortable predicating a technology on them. At the last IETF meeting, I was told by one large CA that they have = happily/profitably been issuing IP-address certs for years. OTOH, they = did indicate that they didn't think many of their competitors were doing = so. --Paul Hoffman= --Apple-Mail=_6AF34F9C-898A-4179-A443-204A291A882B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE2MjQxMVowIwYJKoZIhvcNAQkEMRYEFLMzrJxKUbSKfnST5nN9JKxCTM8qMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQB/iwf2Xi6w4bKWsHL5TibLcXSJmg9+jxBrP9JD1Asc6gKev/ZCCp8CGFHE4WRrxBlqNI9N vavPVB+7ABBKTePFH4bzE57l50RP0rHtnbs/b5MvX7PrY8u1NwZPNiqqvOAncj0lVqDFXN2yLzIZ LZ0Y7O+PG+lP7jIylL9FxN+0VetDjQ2ao2XznrPqSYwhxye5nKquK7nRfRdWTqnHkEuFn/9qLgEw OxqjBd6U1wmHb/8uIT1qeVtJL2esZBsAunpcoo9ns7vgd3qr4+A4jk5emXGzeYIR8sTuyekx2bxI zlF3Tbr1TVD71ESIGpE7KGsJRASlJMAjMvCQV1nLL+EwAAAAAAAA --Apple-Mail=_6AF34F9C-898A-4179-A443-204A291A882B-- From nobody Wed Oct 24 10:05: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 9C1B71277D2 for ; Wed, 24 Oct 2018 10:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGAt_ZazPQTN for ; Wed, 24 Oct 2018 10:05:23 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 45382130E39 for ; Wed, 24 Oct 2018 10:05:23 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id p83-v6so3591732iod.12 for ; Wed, 24 Oct 2018 10:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wJkLF9nNEACpj8x02mscdr7I64EhJ3j3evRz6mN2jps=; b=hQJD5zCqlMvjvwuk7urURseLy/K9y11OA2tGdeB7wf6gnzzg6vI3E7LJai1rNiWE/2 w9Y1y6C+0qy+drRivAFZ16J44M1Qd+E1jwExSdR6uV8UfLa72hoadtARYtoiOhdhRwhK DsEY0vs5N5p0ktV5s1ssJyC0ZKPMVwnzbDRzxSCWJ8bZGH88WJOPm6rRPlQ5HrgWrbBM HZD/mSqjSSjCNaKD2+A6g9gD/BoR0EtUh7wFi6+hbNjixr+tPqQiZEEcMkOvIh6kbgps WmQvXcPbm06q5fc6hkx0zjoj0cylFwhMaJFmsVQqIXN0iT635ZKO4vgo9c023hjPAVgj XCKw== 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=wJkLF9nNEACpj8x02mscdr7I64EhJ3j3evRz6mN2jps=; b=pAngJ9+PnQl16+t14UgoT8LQ1KNXd7d94o3slowDDNa37wxk9sZJiOPSDFVa/aDwRk Kv4ikKg8gVHuXUGHdXddnpUR7k1pR71oZvpzCBReWfE8UBZ6rJS6FEr8sM9+drNP2fjT B/cyFeGS0Dr1h9UTaPkp6CBmjpqcP4uHW+AWN2qD8utzZXewytwwh2ZL9nMzMzFfpSzu Fd5he4rubR2ht+w0Sgw5N5tZn+L/ZIpos38/LQ+e4xKz2P19cKo3l3Org4NSv41md5O1 yVMhIGw6B3rVk62pPwCIYPpYuLL8LXBR4Ho/OaYNLo9SWSW63ztv4yk1LWmfbi/o4OZy qtiw== X-Gm-Message-State: AGRZ1gJHqsvnO5QfwVuUp1lb3SuaCr2eed0Oc+0Yu/oHZWu4YXw+Pf5k zXcsyKwpsO4fBQJTdtrhfUMAPiS0M6q5eilKsR6w36QX26aRNw== X-Google-Smtp-Source: AJdET5e/iJmfdjdQ4MLRqzdzuf5R6NgGeQf9AQV9tB+Ni//6ryGuVuNTzbHl2N4+aaM009I05sx5ddmsPpdoW3bUg38= X-Received: by 2002:a5e:de45:: with SMTP id e5-v6mr12479033ioq.235.1540400721640; Wed, 24 Oct 2018 10:05:21 -0700 (PDT) MIME-Version: 1.0 References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> <003601d46b81$341b13d0$9c513b70$@sebbe.eu> In-Reply-To: <003601d46b81$341b13d0$9c513b70$@sebbe.eu> From: Ben Schwartz Date: Wed, 24 Oct 2018 13:05:09 -0400 Message-ID: To: sebastian=40sebbe.eu@dmarc.ietf.org Cc: ulrich@wisser.se, DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000dc4a410578fc7d46" Archived-At: Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 17:05:26 -0000 --000000000000dc4a410578fc7d46 Content-Type: multipart/alternative; boundary="000000000000d3f76d0578fc7dd1" --000000000000d3f76d0578fc7dd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sebastian, This is definitely a topic of interest, but it may be outside of the DoH Working Group's charter. Discussions on this topic have been moved to their own special mailing list: https://mailarchive.ietf.org/arch/browse/resolverless-dns/ I encourage you to read the messages there, and also to send your thoughts to that list. Thanks, Ben Schwartz On Wed, Oct 24, 2018 at 6:06 AM Sebastian Nielsen wrote: > 1: Yes, but the server should supply the whole chain to the root, thus th= e > client only need to do root validation. > > 2: yes. > > 3: The reason to require DNSSEC signature for third-party domains is so > not a hostile WWW server can replace answers to third party domains, for > example loading paypal.com in a frame and then pointing paypal.com to > themselves. > > > > 4: The server should point this out to the administrator during > configuration. The thing is that the client should refuse to accept > non-DNSSEC signed responses for reason 3. The server could just refuse > queries for domains not DNSSEC signed, like for domains not in the ACL, b= ut > the server should of course keep the domain in the ACL in case it selects > to start DNSSEC signing in the future, but for such domains cache updatin= g > could be done less often, for example weekly. > > > > During configuration of the ACL, or startup of the server software, and i= f > it doesn=E2=80=99t have any cache data written, the server could simply = =E2=80=9Cprime=E2=80=9D the > cache by doing one request for all domains in the ACL, for all record typ= es. > > > > *Fr=C3=A5n:* Doh *F=C3=B6r *Ulrich Wisser > *Skickat:* den 24 oktober 2018 11:54 > *Till:* Sebastian Nielsen > *Kopia:* doh@ietf.org > *=C3=84mne:* Re: [Doh] Suggestion: The final endpoint should be able to > temporarly act as a recursive DoH resolver > > > > I can see the reason behind this but would like to point out a few detail= s. > > > > - clients would have to do dnssec validation > > - servers would need to not only provide answers to queries, but also the > dnssec chain for the validation > > - what should happen with not dnssec signed answers? Dropped? How will th= e > client get an answer in that case? > > > > Additionally, I think it should be made clearer that an endpoint should > only answer for a known list of domains, as to not get abused by clients. > > - what should a server do if a not dnssec signed domain is configured in > it's list? > > > > /Ulrich > > > > Sebastian Nielsen schrieb am Mi., > 24. Okt. 2018 um 11:38 Uhr: > > I have a suggestion for extending the DoH specification: > > > > The final endpoint, should be able to act as a authorative and sometimes > recursive DoH resolver if it has support for the DoH protocol, during the > normal HTTPS connection. > > > > This could mean that once you reach a WWW server, theres no need for > looking up domains like static.example.org and such since the result of > such domains could be returned by the original HTTPS server over the same > connection as the website traffic goes over. > > If the HTTPS server has other domains for example > ads.thirdparty-example.org as links it could return those aswell but only > if they are DNSSEC signed, and for security, a DoH client should only > accept results for a third-party domain if the result is DNSSEC signed. > > > > To avoid abuse, a WWW server supporting this extension should only allow > queries for its own domain and subdomains, and also queries for any > resources it has been configured to resolve (and this type of configurati= on > could be done automatically by for example a script on the web server tha= t > adds all external links to its ACL) > > > > This would mean an WWW server serving content for itself and also have > links to ads.thirdparty-example.org could have those 2 domains cached in > its internal DoH resolver and resolve for those, thus once you reach a > webpage=E2=80=99s server, you no longer need to talk to your recursive Do= H serverl, > which also increases privacy. > > > > This could lead to much faster response times aswell, as the WWW server > would have the information about all its linked hosts permanently cached > and updated regularly. > > Think like OCSP stapling but for DNS responses instead. > > > > > > Best regard, Sebastian Nielsen > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > -- > > Ulrich Wisser > > ulrich@wisser.se > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000d3f76d0578fc7dd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sebastian,

This is = definitely a topic of interest, but it may be outside of the DoH Working Gr= oup's charter.=C2=A0 Discussions on this topic have been moved to their= own special mailing list:=C2=A0https://mailarchive.ietf.org/arch/browse/resolv= erless-dns/

I encourage you to read the messag= es there, and also to send your thoughts to that list.

=
Thanks,
Ben Schwartz

On Wed, Oct 24, 2018 at 6:06 AM Sebastian Nielsen= <sebastian=3D40sebbe.eu@dm= arc.ietf.org> wrote:

1: Yes, but the = server should supply the whole chain to the root, thus the client only need= to do root validation.

2: yes.

3: The reason to require DNSSEC signature for third-party= domains is so not a hostile WWW server can replace answers to third party = domains, for example loading paypal.com in a frame and then pointing paypal.com to themselves.

=C2=A0

4: The server should point this o= ut to the administrator during configuration. The thing is that the client = should refuse to accept non-DNSSEC signed responses for reason 3. The serve= r could just refuse queries for domains not DNSSEC signed, like for domains= not in the ACL, but the server should of course keep the domain in the ACL= in case it selects to start DNSSEC signing in the future, but for such dom= ains cache updating could be done less often, for example weekly.=

=C2=A0=

During configura= tion of the ACL, or startup of the server software, and if it doesn=E2=80= =99t have any cache data written, the server could simply =E2=80=9Cprime=E2= =80=9D the cache by doing one request for all domains in the ACL, for all r= ecord types.

=C2=A0

Fr=C3=A5n: Doh <doh-bo= unces@ietf.org> F=C3=B6r Ulrich Wisser
Skickat: den= 24 oktober 2018 11:54
Till: Sebastian Nielsen <sebastian=3D40sebbe.eu@dma= rc.ietf.org>
Kopia: doh@ietf.org
=C3=84mne: Re: [Doh] Suggestion: The= final endpoint should be able to temporarly act as a recursive DoH resolve= r

=C2=A0

I can see the reason behind this but would like to point= out a few details.

=C2= =A0

- clients would have to do = dnssec validation

- serv= ers would need to not only provide answers to queries, but also the dnssec= =C2=A0chain for the validation

- what should happen with not=C2=A0dnssec=C2=A0signed answers? Dropp= ed? How will the client get an answer in that case?

=

=C2=A0

Additionally, I think it should be made clearer that an endpoint= should only answer for a known list of domains, as to not get abused by cl= ients.

- what should a s= erver do if a not dnssec=C2=A0signed domain is configured in it's list?=

=C2=A0

/Ulrich

=C2=A0

Sebastian Nielsen <sebastian=3D40sebbe.eu@dmarc.ietf.org> schrieb am Mi., 2= 4. Okt. 2018 um 11:38=C2=A0Uhr:

I have a suggestion for extending the DoH specification:<= u>

=C2=A0<= u>

The final endp= oint, should be able to act as a authorative and sometimes recursive DoH re= solver if it has support for the DoH protocol, during the normal HTTPS conn= ection.

=C2=A0

This could mean that once you reach a WWW server, theres no need for looki= ng up domains like = static.example.org and such since the result of such domains could be r= eturned by the original HTTPS server over the same connection as the websit= e traffic goes over.

If the HTTPS server has other domains for example ads.thirdparty-example= .org as links it could return those aswell but only if they are DNSSEC = signed, and for security, a DoH client should only accept results for a thi= rd-party domain if the result is DNSSEC signed.

=C2=A0

To avoid abuse, a WWW server suppo= rting this extension should only allow queries for its own domain and subdo= mains, and also queries for any resources it has been configured to resolve= (and this type of configuration could be done automatically by for example= a script on the web server that adds all external links to its ACL)=

=C2=A0=

This would me= an an WWW server serving content for itself and also have links to ads.thirdparty-exa= mple.org could have those 2 domains cached in its internal DoH resolver= and resolve for those, thus once you reach a webpage=E2=80=99s server, you= no longer need to talk to your recursive DoH serverl, which also increases= privacy.

=C2=A0

This could lead to much faster response times aswell, as the WWW server = would have the information about all its linked hosts permanently cached an= d updated regularly.

Think like OCSP stapling but for DNS responses instead.

=C2=A0

=C2=A0

Best regard,= Sebastian Nielsen

_______________________________________________
Doh mailing list
<= a href=3D"mailto:Doh@ietf.org" target=3D"_blank">Doh@ietf.org
https://w= ww.ietf.org/mailman/listinfo/doh

--

= Ulrich Wisser

____________________________________________= ___
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000d3f76d0578fc7dd1-- --000000000000dc4a410578fc7d46 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYJWDwudxwNjwu8B4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MTAxNDA4MjIxMloXDTE5MDQx MjA4MjIxMlowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCjAFK2jxl2SbwdLgmpNj92zrqk75pYCWjsHhvdBpOYu7YqUel7 tZEj5mGxVhKL8jbTW9bEM/iB1XBfK+JjPXV+WADiV+9+yRRDRugD0oy5iTiEFNVATSd4G5Su+lfw aCM7aa4opbbXPkehb7Gkx3zks54gj2F5KH7dvmvMdAVZuH6Ff4TnUkzolgu/llEzjYArUXHDaAR4 WE02VO3FbyLV97Y68Z3gtHbzsyAOXK6hjLiVwGBTaWaApt9i+d0jR0SDWClPDyK3Vq3QhLVpewN8 bRR1rb72UKt2an3n95SrvbhD639vfyy/cHR09HxDXXlTfyugAk0kYIQiqwS1X74zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFDPcHr72CmAhHX2sPCeQbgmPbXZWMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQATQwVzUhwG45UvRH44 Ls0IDXKJb9GVoZurKcd19M1EtjywGT6ZfFDW1DenoGaf/gizTDc0dHMLV79yXlj6yLtsDkP6rb7f zOyczFMqHbXRXT9YDJlPcOrtp3E2wA/HHph+nimVhrmfcGMndO5AV2DzTD2oOQe5C/mh9RUT5z6/ CrUQ0dAaBZweRC8agj/PQ4Jnen/kqDBE/TgK0ChQ7Q44MkuENG0dp2bPuHG7ZPKkqZ2V5LGhrba4 c4MtQvK9dyNE8urDPL70ogUS3pwBvfui1H1gbHJwe3npqkBvuqswxS7IvDmW88A1wGeWt/02LLQP ysd6YM+XWMe3rBB1zzJDMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYJWDwudx wNjwu8B4MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCisyxHa7QjHirvMymWZm44 s3ikAuTtQoWza24HUwWQQTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODEwMjQxNzA1MjJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZnR+EaL78TGxjy6che+GQcLVLZLs4SKZV/FelbnK CJQetxcvucGbndrbLbGf/P8JoqmB/7sNAmm7GHTu0tUbHrx4iizG2WqH0uEoy1LN0V+WCuu6syE7 Pi57vykB2Tj/UiPLo8tgA1J1QdjPe1qQEA/34c92gLT6kwBEemvSrZOxoDKROJcmg4ah1DjP8QSB nuG3dNfOLjA2URS82ICVn3c5/O5i7X3sqcdOw56LKszJvZPWVZ0IHaktNMrtjFZGI59uOHpthhzg G9XMUWabRrmOWx3tgp1lfi9jFUkb9ikwTIxEpGh2gOytFb/rJKBfNMyknITbz2oK1NB48h/1GA== --000000000000dc4a410578fc7d46-- From nobody Wed Oct 24 11:17: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 DBEF6129619 for ; Wed, 24 Oct 2018 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 a9HXU1Pf46EV for ; Wed, 24 Oct 2018 11:16:59 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 A0B32124C04 for ; Wed, 24 Oct 2018 11:16:58 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id w16-v6so2611397lfc.0 for ; Wed, 24 Oct 2018 11:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d2w1PZyEufUwv6Lsb2IlsclV+zRdHfqPBhy8jcWAeOc=; b=JyKJlEvejoV/Ko/05fQUB/I/TF4Hyt1lAXnnXoizbZlpAFvPAeXtbEgSbOTUSK7ZGN A1QO9/GA/JfGZiCzuBd/10b18BLUli91xyY/j/Hzpqm33t+U2W0/XZnc+ELNGfvZwL1+ WidJ1x8iGebtF/djT3fHO8alHwoo7Spaqk5FAr9e6yGxh+Vkvx0Yq1zfd5m9ReAftRwA EkoZQEt+rhLYSKItsab7sUfDAdHID63dA6RBwyjgbvROcb1lSJt4JSR8sNtx1nm7FkDY HnMHxp2X9yPIyL4N+3e3nD+7JOSTVighg5NT2EH1R84ly+nBgEsHmIK2qlA6vD0ErrVx i/xw== 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=d2w1PZyEufUwv6Lsb2IlsclV+zRdHfqPBhy8jcWAeOc=; b=G1qMFFpd+Ry7vtraghTDXQrcfIx621hpaetYK9RTH2MLn5FdVH4baMLWI7aJ23Lwlu qGgjupFBJ14BQalzBGhTQIj7oUWVePDKbXvM3nSvBcZ7Wjf7Rs6gPvCx7/lYQEaTkWs9 cQ/0Qn4vaz9gtx/NmA2RHFTZ7ArATTmZi/+zBCCSCRQqV8IpqWyroOPsgxQYNTRy7VAE SaTMKMqY8sWuzjF4p2rilLZQxch0YglXMzMkjVoYRT6IULiVIAp4LFNB0nQxOAfOGIOw +k3z00fWWFWuK6w6q7alcSspKpiJ7VIWSFhcwhCkR/q8N145uJlEvK+94Cz7KtCqBYDx tvkQ== X-Gm-Message-State: ABuFfojrgStPy4op9C8AWbwbyEWlQpPK8NWUERhYW530Un9AFL4JsTtN ipuqckWbz6CsiNeXeY6T5MqfqSgOIGjFg0S2eKaCcrKp X-Google-Smtp-Source: ACcGV60KSfrv3J9rvbXm7odVH+4cq82lfPi3Nyil+8uE4YNae8i+u030QD2mrA3LnD+51sxonQ7Sy4RyI8i7KZWr6Bw= X-Received: by 2002:a19:5a05:: with SMTP id o5mr16403742lfb.140.1540405016740; Wed, 24 Oct 2018 11:16:56 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: From: Eric Rescorla Date: Wed, 24 Oct 2018 11:16:19 -0700 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000d603ed0578fd7d20" Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:17:01 -0000 --000000000000d603ed0578fd7d20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman wrote= : > On Oct 23, 2018, at 8:18 PM, Eric Rescorla wrote: > > Several points here: > > 1. As a matter of aesthetics, I agree with Martin that domain names would > be better. > > > If we can get non-address records back, I would prefer to go all the way > to "here are the URI templates of the DoH servers". No need to cause > another round-trip. > > 2. Martin sent a link to a method for resolving TXT records on Windows. > MacOS has its own API: https://developer.apple.com/documentation/dnssd/18= 04747-dnsservicequeryrecord?language=3Dobjc > [developer.apple.com] > > . > So, this doesn't seem prohibitive to me. > > > I thought this only worked for DNSSD, not DNS. Does it work for both? Or > is there a similar-flavored Mac call for DNS? > I am reliably informed it works for ordinary DNS. 4. There are other uses cases for which it might be nice to have real domain names, in which case the IP address cert thing is a pain. For these reasons, I think a domain name in TXT or the like would be better= . Do you see a use case for domain names other than "here's a way to get to a > well-known URI on the resolver"? If so, we could add that as well as "her= e > are the URI templates for the associated DoH server. > I think templates would be fine. -Ekr > --Paul Hoffman > --000000000000d603ed0578fd7d20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Oct 24, 2018 at 9:11 AM Paul Hoffman <paul.hoffman@icann.org> wrote:
On Oct 23, 2018, at 8:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Several points here:

1. As a matter of ae= sthetics, I agree with Martin that domain names would be better.

If we can get non= -address records back, I would prefer to go all the way to "here are t= he URI templates of the DoH servers". No need to cause another round-t= rip.

<= div dir=3D"ltr">
2. Martin sent a link to a method for= resolving TXT records on Windows. MacOS has its own API:=C2=A0https://developer.apple.com/documentation/dnssd/1804= 747-dnsservicequeryrecord?language=3Dobjc [developer.apple.com].
<= div>So, this doesn't seem prohibitive to me.

I thought this only worked for DNSSD, not DN= S. Does it work for both? Or is there a similar-flavored Mac call for DNS?<= /div>

I am reliably informed it works= for ordinary DNS.


4. There are = other uses cases for which it might be nice to have real domain names, in w= hich case the IP address cert thing is a pain.

For= these reasons, I think a domain name in TXT or the like would be better.

Do you see a use case for domain names other than "here's a way = to get to a well-known URI on the resolver"? If so, we could add that = as well as "here are the URI templates for the associated DoH server.<= /div>

I think templates would be fine= .

-Ekr


--Paul Hoffman
--000000000000d603ed0578fd7d20-- From nobody Wed Oct 24 11:25: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 B53D6130F0F for ; Wed, 24 Oct 2018 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 ysqXRo47Fcpt for ; Wed, 24 Oct 2018 11:25:05 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97059130EBC for ; Wed, 24 Oct 2018 11:25:05 -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.1367.3; Wed, 24 Oct 2018 11:25:03 -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.1367.000; Wed, 24 Oct 2018 11:25:02 -0700 From: Paul Hoffman To: Eric Rescorla CC: DoH WG Thread-Topic: [Doh] [Ext] Re: Associating a DoH server with a resolver Thread-Index: AQHUa0hXLZIOUPksW0KFptJhvlWHNqUvBzSAgAAi5oCAAAJugA== Date: Wed, 24 Oct 2018 18:25:02 +0000 Message-ID: <7D43ECB0-BFDF-43B8-972C-41FF6CD07837@icann.org> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_A2D2A4CB-3622-43E6-AEB3-1C497AA61407"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:25:15 -0000 --Apple-Mail=_A2D2A4CB-3622-43E6-AEB3-1C497AA61407 Content-Type: multipart/alternative; boundary="Apple-Mail=_58F6284F-BD4C-4773-B932-0513FB28F1FF" --Apple-Mail=_58F6284F-BD4C-4773-B932-0513FB28F1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2018, at 11:16 AM, Eric Rescorla wrote: >=20 > On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman > wrote: > On Oct 23, 2018, at 8:18 PM, Eric Rescorla > wrote: >> Several points here: >>=20 >> 1. As a matter of aesthetics, I agree with Martin that domain names = would be better. >=20 > If we can get non-address records back, I would prefer to go all the = way to "here are the URI templates of the DoH servers". No need to cause = another round-trip. >=20 >> 2. Martin sent a link to a method for resolving TXT records on = Windows. MacOS has its own API: = https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrec= ord?language=3Dobjc [developer.apple.com] = . >> So, this doesn't seem prohibitive to me. >=20 > I thought this only worked for DNSSD, not DNS. Does it work for both? = Or is there a similar-flavored Mac call for DNS? >=20 > I am reliably informed it works for ordinary DNS. Yay! >> 4. There are other uses cases for which it might be nice to have real = domain names, in which case the IP address cert thing is a pain. >>=20 >> For these reasons, I think a domain name in TXT or the like would be = better. >=20 > Do you see a use case for domain names other than "here's a way to get = to a well-known URI on the resolver"? If so, we could add that as well = as "here are the URI templates for the associated DoH server. >=20 > I think templates would be fine. Sounds good. In the next draft I'll add back in the way of getting the = templates directly in one DNS call for browsers that can do that, and = will say that it SHOULD be used first. I'll let the various ADs decide where this document should end up, if = anywhere. --Paul Hoffman --Apple-Mail=_58F6284F-BD4C-4773-B932-0513FB28F1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 24, 2018, at 11:16 AM, Eric Rescorla <ekr@rtfm.com> wrote:

On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman = <paul.hoffman@icann.org> wrote:
On Oct 23, 2018, at 8:18 PM, Eric Rescorla = <ekr@rtfm.com> wrote:
Several points here:

1. As a matter of aesthetics, I agree = with Martin that domain names would be = better.

If we can get = non-address records back, I would prefer to go all the way to "here are = the URI templates of the DoH servers". No need to cause another = round-trip.

2. Martin sent a = link to a method for resolving TXT records on Windows. MacOS has its own = API: https://developer.apple.com/documentation/dnssd/1804747-dnsserv= icequeryrecord?language=3Dobjc [developer.apple.com].
So, this doesn't seem prohibitive to = me.

I thought this only worked for DNSSD, not DNS. Does it = work for both? Or is there a similar-flavored Mac call for = DNS?

I am reliably informed it works for ordinary = DNS.

Yay!

4. = There are other uses cases for which it might be nice to have real = domain names, in which case the IP address cert thing is a = pain.

For = these reasons, I think a domain name in TXT or the like would be = better.

Do you see a use case for domain names other = than "here's a way to get to a well-known URI on the resolver"? If so, = we could add that as well as "here are the URI templates for the = associated DoH server.

I think templates would be fine.

Sounds good. In the next draft I'll add back in = the way of getting the templates directly in one DNS call for browsers = that can do that, and will say that it SHOULD be used = first.

I'll let the various ADs = decide where this document should end up, if anywhere.

--Paul Hoffman

= --Apple-Mail=_58F6284F-BD4C-4773-B932-0513FB28F1FF-- --Apple-Mail=_A2D2A4CB-3622-43E6-AEB3-1C497AA61407 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNDE4MjUwMlowIwYJKoZIhvcNAQkEMRYEFKKw1ZB+FsJVrfnLhi5bjBBmoCGbMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQArrErqNO1Ikf/QOZKj9ku7feh9t1tVGFVFPTK8vAl9WghdhzXbDKgltotLqeCfIfbYF/WS uNL8rv4zkDLlCLUriuxgIx2Hy22wGh0n9vB5QZ9wgia3WsgoLaZxjrRGMuh5b8ez6UR7SL/0L28f 5awHKj+iay8OKpHqQByTEldyLJamJdstf3470MRIm/HCuURX254YUITzgKZ5+3ZWjaNKLi9e79S8 HGSura9Lz7znYp1BzgCJMDN9pkeXOR3+B818bjaA2b0T71PaE2GfHueT6IlVnrY3Vkzl6ngpOnIU l2tH3aKOBYraoaF3HgpT3msz0F2LoLulTEvBabNP62qMAAAAAAAA --Apple-Mail=_A2D2A4CB-3622-43E6-AEB3-1C497AA61407-- From nobody Wed Oct 24 20:29: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 4462312F18C for ; Wed, 24 Oct 2018 20:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zdeRsah-fvYr for ; Wed, 24 Oct 2018 20:29:33 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 9819F130934 for ; Wed, 24 Oct 2018 20:29:33 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id c205so4589255vsd.3 for ; Wed, 24 Oct 2018 20:29:33 -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=wi8azTjHJl4aG6KaXUaNQD1i2kFoPSP+1VSRGkno/9Q=; b=mz77tkjQhP4cdGGywr0tfE8iUVwddT4mR9otvfCX8498PczsMt3aVWuNN3ZPOcyqeZ afPz7LzP9CbyN8ild6kVUMX8kPzMoW0VS/mfJ3ILBudj14TdxtB7txJT15PyDu31RN+/ 6uDaZs8mArAYgGMaclvFzkcCbUMmsVwEHLS18J5kSn8MA9tM9L6qhAyk4V1toeaU1dqR MIDDzkmm/YDfPfdjntO0iqwGlw0/VD0vcKiLhqq0mZtnnCO/7W3v7Sx1Wl7IY4E8Kks2 PQQziE6ilj9wl1CRY6JOb0UKaYwmI41ZZrQ0Yg61EjyzL+KQc4OG+JAvV0pdWfj7Cn1a MdbQ== 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=wi8azTjHJl4aG6KaXUaNQD1i2kFoPSP+1VSRGkno/9Q=; b=E1ZJAIw9pVsld79jh9k23MxjZP6BSF1CJHxVw14IlxZlIHBcw6HgCS+UAoaKBM/jg8 WsRwy3Yb+g/fxHG3eHEMu4XzBuSoej2N4tA3ipqvHNTiaPP8SVvvvh87HCcQW2TUx5Sy SqqVswVAwIjSPf6jNAaRTxiM4YdVoNyMKKHwmxq+uX8lFRwuJznYbLInrib7yKrKH3J9 e2N6Jn2EwxPZsc+8DV6tus+x8iqB5SKxhQQ1QPtkmF+IxFKSOisacHUlGV9W5rjBPQrc 9Kb8neQzBgkPt4BZpxquYTW1AaEBHHu6eJdmZkAqOjUwHb1s1o7VExYzgsr25uOx7HGR 4Chg== X-Gm-Message-State: AGRZ1gI5Pm2DHWJzQGR2cOU12RIbnMSsZf7vQEFb7LDakssNgFdIRKpZ I30jGFwwKCkj7S3VK5GayU/FV2H4ebYG0VuCIlSkzg== X-Google-Smtp-Source: AJdET5ef4SbRIRzLZsvtwtsbMIwJQoZhfQAVqwJYeyDGxGZfpQlYlYcpaQOFBN38MS6E5de7TgaUepcdiHYD+uDVeKw= X-Received: by 2002:a67:941:: with SMTP id 62mr2348072vsj.203.1540438172311; Wed, 24 Oct 2018 20:29:32 -0700 (PDT) MIME-Version: 1.0 References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <7D43ECB0-BFDF-43B8-972C-41FF6CD07837@icann.org> In-Reply-To: <7D43ECB0-BFDF-43B8-972C-41FF6CD07837@icann.org> From: Christopher Wood Date: Wed, 24 Oct 2018 20:29:18 -0700 Message-ID: To: Paul Hoffman Cc: Eric Rescorla , doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 03:29:35 -0000 On Wed, Oct 24, 2018 at 11:25 AM Paul Hoffman wrote: > > On Oct 24, 2018, at 11:16 AM, Eric Rescorla wrote: > > > On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman wrote: >> >> On Oct 23, 2018, at 8:18 PM, Eric Rescorla wrote: >> >> Several points here: >> >> 1. As a matter of aesthetics, I agree with Martin that domain names would be better. >> >> >> If we can get non-address records back, I would prefer to go all the way to "here are the URI templates of the DoH servers". No need to cause another round-trip. >> >> 2. Martin sent a link to a method for resolving TXT records on Windows. MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc [developer.apple.com]. >> So, this doesn't seem prohibitive to me. >> >> >> I thought this only worked for DNSSD, not DNS. Does it work for both? Or is there a similar-flavored Mac call for DNS? > > > I am reliably informed it works for ordinary DNS. > > > Yay! Chiming in to confirm this is accurate. :-) Best, Chris > > 4. There are other uses cases for which it might be nice to have real domain names, in which case the IP address cert thing is a pain. > > For these reasons, I think a domain name in TXT or the like would be better. > > >> Do you see a use case for domain names other than "here's a way to get to a well-known URI on the resolver"? If so, we could add that as well as "here are the URI templates for the associated DoH server. > > > I think templates would be fine. > > > Sounds good. In the next draft I'll add back in the way of getting the templates directly in one DNS call for browsers that can do that, and will say that it SHOULD be used first. > > I'll let the various ADs decide where this document should end up, if anywhere. > > --Paul Hoffman > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Thu Oct 25 04:38: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 4EF14130E37 for ; Thu, 25 Oct 2018 04:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2AIzAx-6n4AE for ; Thu, 25 Oct 2018 04:38:22 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43AE1286E3 for ; Thu, 25 Oct 2018 04:38:21 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id EBE432420FD8; Thu, 25 Oct 2018 11:38:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 25 Oct 2018 12:38:17 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <0603C647-35EB-44BB-A221-420DDE817ABA@rfc1035.com> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <67726F45-C947-48ED-B6ED-ABE2BD547AB1@icann.org> To: Tony Finch X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 11:38:23 -0000 On 24 Oct 2018, at 12:24, Tony Finch wrote: >=20 > Both of our CAs will not give us iPAddress certificates. I=E2=80=99m fairly sure there=E2=80=99s an RIR based not a million miles = away from Amsterdam who would be delighted to issue with certificates = for your IP addresses. From nobody Thu Oct 25 04:43: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 91A381286E3 for ; Thu, 25 Oct 2018 04:43:15 -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, RCVD_IN_DNSWL_MED=-2.3, 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 lIfIbd0gOyh9 for ; Thu, 25 Oct 2018 04:43:13 -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 82D861286D9 for ; Thu, 25 Oct 2018 04:43:13 -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]:38558) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gFe2i-0004OH-cs (Exim 4.91) (return-path ); Thu, 25 Oct 2018 12:43:12 +0100 Date: Thu, 25 Oct 2018 12:43:11 +0100 From: Tony Finch To: Jim Reid cc: DoH WG In-Reply-To: <0603C647-35EB-44BB-A221-420DDE817ABA@rfc1035.com> Message-ID: References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <67726F45-C947-48ED-B6ED-ABE2BD547AB1@icann.org> <0603C647-35EB-44BB-A221-420DDE817ABA@rfc1035.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1870870841-851835995-1540467792=:24450" Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 11:43:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-851835995-1540467792=:24450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Jim Reid wrote: > On 24 Oct 2018, at 12:24, Tony Finch wrote: > > > > Both of our CAs will not give us iPAddress certificates. > > I=E2=80=99m fairly sure there=E2=80=99s an RIR based not a million miles = away from > Amsterdam who would be delighted to issue with certificates for your IP > addresses. I don't think RPKI will be much use for web PKI purposes :-) Tony. --=20 f.anthony.n.finch http://dotat.at/ strengthen the democratic process and ensure that there is a just and representative system of government --1870870841-851835995-1540467792=:24450-- From nobody Thu Oct 25 07:57: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 613B8130E5A for ; Thu, 25 Oct 2018 07:57:14 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Fgm0OJ6buul9 for ; Thu, 25 Oct 2018 07:57:12 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13938130E69 for ; Thu, 25 Oct 2018 07:57:12 -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.1367.3; Thu, 25 Oct 2018 07:57:09 -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.1367.000; Thu, 25 Oct 2018 07:57:09 -0700 From: Paul Hoffman To: Ben Schwartz CC: DoH WG Thread-Topic: [Ext] [Doh] Associating a DoH server with a resolver Thread-Index: AQHUbHMAS2WH9fYpIkSbfmTvqNJTAg== Date: Thu, 25 Oct 2018 14:57:09 +0000 Message-ID: <9232174A-E543-40BA-8293-9682FC412D30@icann.org> References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> 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=_8E298BAB-67BC-4AF7-9504-795BFBBBA9C1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 14:57:14 -0000 --Apple-Mail=_8E298BAB-67BC-4AF7-9504-795BFBBBA9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for the belated reply to this. Gotta love corporate mail = systems... On Oct 23, 2018, at 2:05 PM, Ben Schwartz = wrote: >=20 > Hi Paul, thanks for the continuing work on this topic. >=20 > Two related questions: > 1. Does the resolver have to return its own IP in the RR for = resolver-addresses.arpa, or can it return some other IP addresses? The current wording is that the resolver returns its own IP address, = which makes the resolver operator responsible for running the service = that will respond to the well-known URI. There is no expectation that = the URI templates returned from the well-known URI will all point to = that same resolver; it would be find for the resolver operator to point = to trusted third-party services. > 2. If a client has some OS-specific way to enumerate the DNS server = IPs for the default network interface, is it still required to perform = "Step 1"? (Most OSes do have some enumeration mechanism like this.) Good point; I'll add this to the next draft and say "no". I'll also say = "if the application can enumerate the OS's preferred DoH servers, there = is no need to use the protocol here at all". > Other minor comments: > On Section 4, User Interface: I don't see the need for a user = interface here. In my view, opportunistic security generally shouldn't = require user action and shouldn't produce a user-visible change. Browser vendors might prefer that, privacy-concerned users might want a = UI. I guess I'm targeting the latter. > I think interaction with DoT is worth discussing here, even though = it's probably trivial. If I can probe for DoT and (with this draft) = DoH, which one do I probe first, and which should I prefer if both = succeed? Yes, I'll add a stub for discussion of this. --Paul Hoffman --Apple-Mail=_8E298BAB-67BC-4AF7-9504-795BFBBBA9C1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL9DCCBZ4w ggSGoAMCAQICEAbzeOJeWp48+t/BRQQfhmcwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE4MDYxMzAwMDAwMFoXDTIxMDYxMzEy MDAwMFowgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMR4wHAYDVQQDExVQYXVsIEhvZmZtYW4gMjAxODA2MTMxJTAjBgkqhkiG9w0B CQEWFnBhdWwuaG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtNvEFt/FuTVXENCw6YSbXhi1rYATlwFwn+S0yQL5pCtMIxJetAl+OIxRSd2d8BPUNZx+ODvTq +8hNrWWQVougX1vpw0gIwqyJsWu4XLxkDZuwg9Fc8/NKxjrOJt1K00Kmu41NCiIv1sjGVCmpFTH8 F+8cCFLuDl0A5xGCSlb1DhKLluXoDapLQiYgzOS01xXGtYCfQewb27xwpxIIEnFq9ECcy39eETu0 IgKPKh6imthnbO2Z1lQvpSAw2sPP8qh40cBbNMAfjmGfUnPUiC4Ysz8zZVvyYXx4/fACHikxUiLa MLA2oLj3tHzHSWw2vKgb67L/bqcrp+EJOpV8XqGBAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUP5JPmEQdtO4cllP2G6wM3tUtB2AwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQADu8aIhNUm8QiAU3dRWzMP ifK3ySzx38iTlSPWM+4Pz41fiUGkM4i99iQKfwphKvH6wxCumhLZ6ds4zB6R5/e05uXaFUrZD62/ UaSw+r21D3wBvU52/Ugz1phpTVqVHn8QSFzS6qzVSXPZZRzzH9qd/f8ilsfIQ904IuIv2aJvgYMz zP2aq8AT4y2KypGzb7CUzML/rew0qkDop18E0owsefKoIAoXuW4ZanrXbI+YaiHrdsEuulElCisj 9+y/lITakrdd/ndb8Qt/qzFYyxeb2ISAx6gA60N4keu/6L6+WV3AcckrrOVch1WuPFGSXKAhJeaW x0ez+wOnUwSplM5cMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMAkG BSsOAwIaBQCgggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MTAyNTE0NTcwOVowIwYJKoZIhvcNAQkEMRYEFAZYXuxSxnbuYlv5V232PrHpPQ8VMIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ BvN44l5anjz638FFBB+GZzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+GZzANBgkqhkiG9w0BAQEF AASCAQAwYuD4NqkyQ+C5no5WKo1nSa5lsWVUrUkZU8k5iXbnzVXG1RPotn3oKF2bLSCxELAjEOgR 00L218hUDF97/OGSmYfi4LAlvvMMEhHI5S2n3fisTgchZEAKu1yAvkCPn7HQwjQgbGZ55iPDzsT8 RXhh2BqZ0EE9iUPuG1qUronkHhbKHffHzF+27PcfE3lfxRhStoBedNW3JCxyg1MlRUaL+E3Q3vKy qykgR9Xk0lFTqz5WbtDVisCXoU4pJG8gw0X+i/IdueKYsCQXmiv9f6KVqStWtThVTQx/F2TWelLF keaBveea9dku9r8SwI9RB2pHMD510pEyCUFYuXbB4FsPAAAAAAAA --Apple-Mail=_8E298BAB-67BC-4AF7-9504-795BFBBBA9C1-- From nobody Thu Oct 25 08:35:34 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 6EF49130DD3 for ; Thu, 25 Oct 2018 08:35:33 -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=unavailable 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 6wYlWJoQaaRW for ; Thu, 25 Oct 2018 08:35:32 -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 693C6130E76 for ; Thu, 25 Oct 2018 08:35:32 -0700 (PDT) Received: from Svantevit.attlocal.net (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 w9PFZAoL056407 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Oct 2018 10:35:11 -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 Svantevit.attlocal.net To: Paul Hoffman , Ben Schwartz Cc: DoH WG References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <9232174A-E543-40BA-8293-9682FC412D30@icann.org> From: Adam Roach Message-ID: <60306ee3-7151-54c4-31ef-3c86f62ebb7d@nostrum.com> Date: Thu, 25 Oct 2018 10:35:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9232174A-E543-40BA-8293-9682FC412D30@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:35:33 -0000 On 10/25/18 9:57 AM, Paul Hoffman wrote: > >> Other minor comments: >> On Section 4, User Interface: I don't see the need for a user interface here. In my view, opportunistic security generally shouldn't require user action and shouldn't produce a user-visible change. > Browser vendors might prefer that, privacy-concerned users might want a UI. I guess I'm targeting the latter. You cast this as a matter of user agency, while the analysis that's been done in this space has concluded that these kinds of indicators for opportunistic security are quite hostile to user interests. It's hard to convey the subtlety of "you might be talking to the wrong thing, and there might be undetectable on-path attackers reading and modifying your data, but at least passive attackers can't see what's going on." And users who overestimate the level of protection implied by security indicia run a high risk of behaving in a way that does not suit their interests. /a From nobody Thu Oct 25 10: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 6CDBA1277D2 for ; Thu, 25 Oct 2018 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 n7QBbTQUNeUo for ; Thu, 25 Oct 2018 10:58:09 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8965E126F72 for ; Thu, 25 Oct 2018 10:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2332; q=dns/txt; s=iport; t=1540490288; x=1541699888; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TxG/mTEIaK4K0hMOqdViNOx+8zquJWBTJCCvXBwQcwI=; b=gM2vr2XdXo9Tf1577fu39Ak7G9xu6L9URj5F6VK4cwKKbUSPX/EsEi89 dBJg8u7nen6zLoNGIqXBag9QzBAfsdZv/8fiW6sCtnL42tAH9sHr7CTdH /VcjwY6MN1BrzkdejA0ad6Wg77SmZ35lnKvrnEzPejdoqzbB9tHkWowVn 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAAAeA9Jb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZQKDaIQdiHeNRpkWCAWEbAKDMjgWAQMBAQIBAQJtKEI?= =?us-ascii?q?BDgGEaQEFI08HEAsYKgICVwYBDAgBAYMdAYIBp2mBLooOD4JtiRCCAIE4gj0?= =?us-ascii?q?uhGiDGYJXAp52CYQUgW+KdAYYgUOHeocGlwmBWiGBVTMaCBsVgyiQWD2FN4c?= =?us-ascii?q?8AQE?= X-IronPort-AV: E=Sophos; i="5.54,425,1534809600"; d="asc'?scan'208"; a="7536177" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 17:58:06 +0000 Received: from [10.61.168.239] ([10.61.168.239]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w9PHw5ZQ003739; Thu, 25 Oct 2018 17:58:06 GMT To: Patrick McManus , Paul Hoffman Cc: DoH WG , Martin Thomson References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Thu, 25 Oct 2018 19:58:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tu92tlw787BN5dRCGrXuiSETYPbzcQ494" X-Outbound-SMTP-Client: 10.61.168.239, [10.61.168.239] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 17:58:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tu92tlw787BN5dRCGrXuiSETYPbzcQ494 Content-Type: multipart/mixed; boundary="kYyUjGGmja9RlzBwgN2qHnghM7xH4ZPXG"; protected-headers="v1" From: Eliot Lear To: Patrick McManus , Paul Hoffman Cc: DoH WG , Martin Thomson Message-ID: Subject: Re: [Doh] [Ext] Re: Associating a DoH server with a resolver References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> In-Reply-To: --kYyUjGGmja9RlzBwgN2qHnghM7xH4ZPXG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 24.10.18 18:09, Patrick McManus wrote: > > However I disagree with the premise of the work - browsers I have > spoken with do not seek to find a DoH version of a resolver that was > discovered from a broadcast address over a network that wasn't > authenticated in the first place and has an unknown trust relationship > with the user in the second case. If you're referring to DHCP, I think it's worth stepping through the entire trust model and comparing before we get to sweeping generalization= s. Eliot --kYyUjGGmja9RlzBwgN2qHnghM7xH4ZPXG-- --tu92tlw787BN5dRCGrXuiSETYPbzcQ494 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvSBC0ACgkQh7ZrRtnS ejOz1Qf+O3PlTTveEe7QWx2TdbNHpiuDLtL+LKg0LEJFoCZ79CsqLT7tvb28sQ7Q paiGL1L8zk6rV7XEC425oMDYt2rV7PGeJtbV9ssFD3JhJV2ggHJm9mEQ30wwt0Rf CZ5aikQNWD0b49jquxSU1l9vQ3ErSamMECf1bYVTxOu+Rd941Wu72/9HSz/nCH+x 99hxf1qNxKRK7ZKuPiSGU6y9Ju9mn1G84tQugWF1mOPSbq1PWt0AvT2Js8Fkma/Y qZ/cvRkHY4r9bEIKoFxLxqA91uNy9UhK6JAoJwgT68MSQ65+OvWyvBqiXhIkGWO7 /H4r1+2ZsYG96Z1S6pkQcNUvKMnaiw== =531B -----END PGP SIGNATURE----- --tu92tlw787BN5dRCGrXuiSETYPbzcQ494-- From nobody Thu Oct 25 12:42: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 5BBCB130EA3 for ; Thu, 25 Oct 2018 12:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-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 6r0IAfivHfo5 for ; Thu, 25 Oct 2018 12:42:18 -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 02A1A130E6E for ; Thu, 25 Oct 2018 12:42:17 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id EAF474CBF0; Thu, 25 Oct 2018 15:42:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23506.7319.938389.445190@gro.dd.org> Date: Thu, 25 Oct 2018 15:42:15 -0400 From: Dave Lawrence Cc: In-Reply-To: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> Archived-At: Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 19:42:19 -0000 Sebastian Nielsen writes: > This could mean that once you reach a WWW server, theres no need for > looking up domains like static.example.org and such since the result > of such domains could be returned by the original HTTPS server over > the same connection as the website traffic goes over. Do note that even if you're talking to www.example.org, static.example.org can be in a different authoritative domain. It shouldn't be exempted from DNSSEC. From nobody Thu Oct 25 17:58:21 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 B233E130E08; Thu, 25 Oct 2018 17:58:12 -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 0i7PpXNEQ9RQ; Thu, 25 Oct 2018 17:58:10 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 69E5B1286E7; Thu, 25 Oct 2018 17:58:10 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id w19-v6so10174492eds.1; Thu, 25 Oct 2018 17:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vYv3baw+iUilpFIbuJeqQUBx5NDF0saZHWF6IaUeDH4=; b=sWv7W8QEJespj3futdEcWNIOl7eRIUR3Z2UIXHNj7sUWAYbg4kxTAY0HIOyzDCmEv7 p7/nI5eTbgBqTg1tlWHRHhcZCUgZKD8FqrgPu2Eanw4QVd07mE9hcVcqNgMLe/PQSpWm lnDulI/EmX+O+gJur8SF5sVJc5+4rTZv8jhLZNeHr9RvhbhXuFAMlkL8+wJZagw5K7b4 e7c1IH92o3FhA9y0rmZFaDbW9THMDYHkSS2I+T/My3+FnrsXkH9GHJbGvJvP9Y62DUjQ VRm5DU3rC5yZI1mLh/cNwWs4b7ldv/luDWXXJoGrCa72BBsgje9KJyvsQ2yojb7SHwPl pM1w== 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=vYv3baw+iUilpFIbuJeqQUBx5NDF0saZHWF6IaUeDH4=; b=bVEvs7xHiRZaTIQCYf0XbVfySkaVQFSbUNlUDv8Mv2imnGOI7mlHaSgB5q13G0aMub hn6gaiSiNbX23E2j05cwsTSuPIpW9d1LiZgs4S2fMRhEXshtZ2gLs6N2D1Dkb6unyhof FN7GY5wqTjjCdFpezNVVgbP+aVPVjXEraNF+FwAWFvnTv/V9sF6CTXUV/mvZ/WvBzU+y 7xUa04jdeQgd/yyk5Ujx0iRiGkvq6lSSPnWCEIDLbe3pLlDCIj0RsAZhTaOr9/1b7PC1 wNF3iAiiHCFYC6uoTB25q/vpO/8yZfDt0gRlln4s5/v/mvQGr2REYXhxSSdYW+Ax1RpT K87A== X-Gm-Message-State: AGRZ1gJRunTd4BDIP9tthH9Aci1FeCFrK7hgwJWUYmtv7zb/nXO1c1ov C80iGn7Vx9rb4Fw/PRPpU2KlzH4OEMNZZ+3FQqIgT8Nk9as= X-Google-Smtp-Source: AJdET5dCDhKTIwHs8KQVIzzF282ZyncYBmpGIpMzA1Bcdq1FcsZWp27jE1OQQeAluEHoly42wtINQmGgx2cngSe7skY= X-Received: by 2002:aa7:c149:: with SMTP id r9-v6mr1019788edp.213.1540515488512; Thu, 25 Oct 2018 17:58:08 -0700 (PDT) MIME-Version: 1.0 From: Todd Hubers Date: Fri, 26 Oct 2018 11:57:56 +1100 Message-ID: To: jmap@ietf.org, doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000076bde2057917369c" Archived-At: Subject: [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 00:58:13 -0000 --00000000000076bde2057917369c Content-Type: text/plain; charset="UTF-8" Hi All, Is there a document/RFC about the IETFs collective general movement toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe others using Web/HTTP/JSON? I read the introduction of DoH [RFC8484], and noted there was no reference there, so such a document probably doesn't exist. Instead, it could read something like "Web Convergence is desirable [RFCXXXX]", and that RFC could be very comprehensive in the collective decision about this direction. It would critically help in determining when a current standard should be considered for Web Convergence. I believe it would be something to be referenced in the charter of such a WG, to clarify WHY the work is being completed, in addition to the other good reasons. Even if we don't have an RFC, this idea does need a solid name/label. I have initial ideas for the content of such a Web Convergence RFC [Appendix 1], and what it might be ultimately called [Appendix 2] (I am also new to IETF generally, so I'm still learning. But I like learning by doing._ Thanks, Todd Hubers --- Appendix 1 For rebuilding of older standards the web way; OR, building new standards the web way. The reasons should be the same. Initial ideas for reasons to be collated in such a document/rfc: - Accessible directly by web applications (javascript), removing the need to push via a specialised application server adaptor service (eg. HTTP to SMTP) - The reuse of standard web sysops tools (eg. nginx, certificate management, services like CloudFlare and more) - The reuse of standard web frameworks and libraries (eg. header parsing, asynchronous threads) - Reducing the diffusion of open source development contribution (redefining the same functions in different standards, and different source code is inefficient). - Additional features available from current and future web standards (eg. redirect, media-type negotiation, compression, multiplexing, proxying, caching, authentication, Header Parsing, URIs, well-named folders, Identity, Semantics, etc..) - More secure with exactly the same security model as web - (eg. no plain text email transmission) - All security/firewalls leveraging accumulated PORT 80/443 and HTTP intelligence. --- Appendix 2 Possible names for this process - Web Recasting - Web Convergence - Http Convergence (specifically HTTP of Web Convergence) --00000000000076bde2057917369c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2= =A0All,

Is there a document/RFC about the IETFs=C2=A0col= lective general movement toward re-standardisation of things like DNS (DOH)= , SMTP (JMAP), and maybe others using Web/HTTP/JSON?

I read the introduction of DoH [RFC8484], and noted there was no ref= erence there, so such a document probably doesn't exist.=C2=A0

Instead,=C2=A0it could read something like "Web Conve= rgence is desirable [RFCXXXX]", and that RFC could be very comprehensi= ve in the collective decision about this direction. It would critically hel= p in determining when a current standard should be considered for Web Conve= rgence.

I believe it would be something to be refe= renced in the charter of such a WG, to clarify WHY the work is being comple= ted, in addition to the other good reasons. Even if we don't have an RF= C, this idea does need a solid name/label.

I have = initial ideas for the content of such a Web Convergence RFC [Appendix 1], a= nd what it might be ultimately called [Appendix 2]

(I am also new to IETF generally, so I'm still learning. But I like le= arning by doing._

Thanks,
=

Todd Hubers

---

Appendix 1

For= rebuilding of older standards the web way; OR, building new standards the = web way. The reasons should be the same.

Ini= tial ideas for reasons to be collated in such a document/rfc:

- Accessible directly by web applications (javascript)= , removing the need to push via a specialised application server adaptor se= rvice (eg. HTTP to SMTP)
- The reuse of standard web sysops t= ools (eg. nginx, certificate management, services like CloudFlare and more)=
- The reuse of standard web frameworks and libraries (eg. header= parsing, asynchronous threads)
- Reducing the diffusion of open = source development contribution (redefining the same functions in different= standards, and different source code is inefficient).
- Addition= al features available from current and future web standards (eg. redirect, = media-type negotiation, compression, multiplexing, proxying, caching, authe= ntication, Header Parsing, URIs, well-named folders, Identity, Semantics, e= tc..)
- More secure with exactly the same security model as web -= (eg. no plain text email transmission)
- All security/firewalls = leveraging accumulated PORT 80/443 and HTTP intelligence.=C2=A0=C2=A0
=

---

Appendix 2

Possible names for this process

- Web Recasting
- Web Convergence
- Http Conve= rgence (specifically HTTP of Web Convergence)
=
--00000000000076bde2057917369c-- From nobody Thu Oct 25 18:30:53 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 CE051130DC1; Thu, 25 Oct 2018 18:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 ip3TWbDen8bC; Thu, 25 Oct 2018 18:30:49 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0096.outbound.protection.outlook.com [104.47.93.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F2C1294D7; Thu, 25 Oct 2018 18:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IGIeqldCg/k5bRpZZSh9pbMdtrusa48f1eXk2Thy5ZA=; b=t+WF5GdY1XIO9w4nZQ3njvjFfdTwd+ccZHrOcmb1lN5G/P2RROnxVNaKOtASYvtVGOrhPRhu4SE1kQFwMi4/RpNrzYlCiaFul/GJOuiyaelyCxe5n1tKsuDQFFSeAY7zXMZI9gqcsPyCJxuJhv53NDKrgDftrXYknrkANeqIoIU= Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com (52.133.162.14) by TY1PR01MB0778.jpnprd01.prod.outlook.com (10.167.158.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20; Fri, 26 Oct 2018 01:30:46 +0000 Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::883f:aaf4:50da:73a6]) by TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::883f:aaf4:50da:73a6%3]) with mapi id 15.20.1273.025; Fri, 26 Oct 2018 01:30:46 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Todd Hubers , "jmap@ietf.org" , "doh@ietf.org" Thread-Topic: [Doh] Web Convergence - is there a document/RFC for this apparent direction? Thread-Index: AQHUbMcCrD2p+NvHbUCOXnpVhAOWD6UwvXsA Date: Fri, 26 Oct 2018 01:30:46 +0000 Message-ID: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TY1PR01CA0141.jpnprd01.prod.outlook.com (2603:1096:402:1::17) To TY1PR01MB1547.jpnprd01.prod.outlook.com (2603:1096:403:4::14) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB0778; 6:Y0A6wo4RyCm79/XcJS7qDvgNbKi/PACf5GEPRZEtsRNPDp1+u7ixVYF71mjReq0Wt2QHBperjhpt8DER98XvG3EuOrNceDpH3n6CwOC/eKy8nHfrHNzne2RFNvauIH9XieVy088Z30905z3ZFIo5DqNRQSMhBXMPru8aMEJPgzKZXiw/IKENOgp4CrO4DCYIu9X0oIOY3WsK8AzkU5PWJ2ryIHTTuxvJ9l/s/1xWRzInmgTnvJiV9kEuJMODMVWuNFVSmqP6sNUcHVy881Rowcf5ETdkyWeW3Y1Qvx+JFr/eIAP0V9BPJK4fItNqHHTYIa6Dkp2k5uJsGu3PGKEV89fjJ2mBGupCqekRk9ers5phCIyI53BSn9HfjyF2oY+QiJpkXLB6/CGzI06W+gTQV0yblisVtmSMdr849RtB5ILPIyKum+856pvzXa8KPo6nPQbesWht/TYMpUb9JHA6Bg==; 5:dwDcgB1GOw3GsYKL46A8xnYuWSw2vaVhcat83lI1TR3JIQs8zzc13LsfSDj4Riqu91j2CRFqjT/RbD4ymhUzGblDaIn9iVq2Oi2wWKlAKsQlPTZ8bUxeZ19fZQFofz2VIa5coPuDJz9uGVeYLOk5Jqvj7M7HNYbxAz/I5rC+Kbo=; 7:gmHCm2bIbODycX0EXmkbC5mMIU4NsQ45R7ma1I4HgH4NU8aKaiSsQZD0ubugM9rpF5555uP2sqP8rohxAT3OdwWxgc/zAGyhoSScpPEU/pnOA7a721gZm+Cue+ccEWXC5LfANLLWsIOnc/rd43T/UHLNN51sfqK9XZ/I8h2NpM9Iy2m9wXPk6NB1fvRHnVJNk2WYBINml4sgwSnw75Xu+hpxbSR5q6q/QWLJJwSyd+6SpLmvYjDv6+NRHffmUXLK x-ms-office365-filtering-correlation-id: f097df54-5750-4224-0759-08d63ae2a717 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7025125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB0778; x-ms-traffictypediagnostic: TY1PR01MB0778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(278428928389397)(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(4982022)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(2016111802025)(20161123560045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:TY1PR01MB0778; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0778; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39840400004)(366004)(376002)(346002)(396003)(53754006)(199004)(189003)(229853002)(8676002)(81156014)(81166006)(305945005)(14444005)(186003)(7736002)(66066001)(76176011)(2201001)(102836004)(52116002)(26005)(446003)(11346002)(256004)(8936002)(68736007)(3846002)(6116002)(2906002)(476003)(2616005)(110136005)(486006)(53546011)(6506007)(386003)(6436002)(99286004)(6486002)(5660300001)(25786009)(966005)(74482002)(105586002)(106356001)(85202003)(31686004)(508600001)(2900100001)(39060400002)(71190400001)(71200400001)(53936002)(316002)(6512007)(786003)(31696002)(6306002)(85182001)(86362001)(97736004)(5250100002)(14454004)(6246003)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0778; H:TY1PR01MB1547.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: /Zla1z+BQJWk7VREAlhzyLECO6CqGmbZs8BIp3VnbNmFzpd/VJyR2uyqL7sa52w6gyGh7n2rPQf6KdMWiI7nXLyLwpotnZSdY4FILhuvvRsU52zhwe//za+ehe06I0ZzELfSffzFbGp1ZexojbKqSd5P6k34/rBTo7phwsSVnKD5BEeycDwx5Q4wY90t5bNX9t5i5I53+78qoiDwuy5DkgbscFQq4r2bsOQWLZyH5DfgSNpOcL/6GNljJg6UHz+zk/etUO4qyxlQBKHqfOBNaHTlXsvjluubiy6RhZ5PvB4r9CkPn+Bqk8BfsSWQVDV4D57gWixXlG5aJdKEU16aLjyd3FsPtTzxV6XK2jATlUU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <38CEF41361ED1E4A8706F1CFADA04880@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: f097df54-5750-4224-0759-08d63ae2a717 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 01:30:46.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0778 Archived-At: Subject: Re: [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 01:30:52 -0000 SGVsbG8gVG9kZCwNCg0KVGhpcyBpcyBqdXN0IGEgcGVyc29uYWwgb3BpbmlvbiwgYnV0IGJhc2Vk IG9uIG1vcmUgdGhhbiAyMCB5ZWFycyBvZiANCmV4cGVyaWVuY2Ugd2l0aCB2YXJpb3VzIHN0YW5k YXJkcyBvcmdhbml6YXRpb25zIGluY2x1ZGluZyB0aGUgSUVURi4NCg0KT24gMjAxOC8xMC8yNiAw OTo1NywgVG9kZCBIdWJlcnMgd3JvdGU6DQo+IEhpIEFsbCwNCj4gDQo+IElzIHRoZXJlIGEgZG9j dW1lbnQvUkZDIGFib3V0IHRoZSBJRVRGcyBjb2xsZWN0aXZlIGdlbmVyYWwgbW92ZW1lbnQgdG93 YXJkDQo+IHJlLXN0YW5kYXJkaXNhdGlvbiBvZiB0aGluZ3MgbGlrZSBETlMgKERPSCksIFNNVFAg KEpNQVApLCBhbmQgbWF5YmUgb3RoZXJzDQo+IHVzaW5nIFdlYi9IVFRQL0pTT04/DQo+IA0KPiBJ IHJlYWQgdGhlIGludHJvZHVjdGlvbiBvZiBEb0ggW1JGQzg0ODRdLCBhbmQgbm90ZWQgdGhlcmUg d2FzIG5vIHJlZmVyZW5jZQ0KPiB0aGVyZSwgc28gc3VjaCBhIGRvY3VtZW50IHByb2JhYmx5IGRv ZXNuJ3QgZXhpc3QuDQoNCkkgZ3Vlc3MgeW91J3JlIHJpZ2h0LiBCdXQgdGhlcmUgbWF5IGJlIGRv Y3VtZW50cyB0aGF0IGFyZSBzb21ld2hhdCANCnJlbGF0ZWQuIEluIHBhcnRpY3VsYXIsIEknbSB0 aGlua2luZyBvZiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aHR0cGJpcy1iY3A1NmJpcy8uDQoNCj4gSW5zdGVhZCwgaXQgY291bGQgcmVhZCBzb21ldGhpbmcg bGlrZSAiV2ViIENvbnZlcmdlbmNlIGlzIGRlc2lyYWJsZQ0KPiBbUkZDWFhYWF0iLCBhbmQgdGhh dCBSRkMgY291bGQgYmUgdmVyeSBjb21wcmVoZW5zaXZlIGluIHRoZSBjb2xsZWN0aXZlDQo+IGRl Y2lzaW9uIGFib3V0IHRoaXMgZGlyZWN0aW9uLiBJdCB3b3VsZCBjcml0aWNhbGx5IGhlbHAgaW4g ZGV0ZXJtaW5pbmcgd2hlbg0KPiBhIGN1cnJlbnQgc3RhbmRhcmQgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgZm9yIFdlYiBDb252ZXJnZW5jZS4NCg0KVGhlIElFVEYgaXMgKGF0IGxlYXN0IG9mZmljaWFs bHkpIGEgY29sbGVjdGlvbiBvZiBpbmRpdmlkdWFscy4gTWFueSBvZiANCnRoZXNlIGluZGl2aWR1 YWxzIHNlZSB0cmVuZHMgbGlrZSB0aGUgb25lIHlvdSBicmluZyB1cCBoZXJlLiBCdXQgdGhlIA0K SUVURiBhcyBhIHdob2xlIGlzbid0IG9yZ2FuaXplZCBvciBlbXBvd2VyZWQgdG8gYWRhcHQgZ3Jl YXQgdHJlbmRzIGFuZCANCnRoZW4gZm9yY2UgZXZlcnlib2R5IHRvIGZvbGxvdyB0aGVtLiBXaGVy ZSB0aGF0IGhhcyBiZWVuIHRyaWVkLCBpdCBoYXMgDQp1c3VhbGx5IG5vdCB3b3JrZWQgZXh0cmVt ZWx5IHdlbGwuDQoNCk90aGVyIHN0YW5kYXJkcyBvcmdhbml6YXRpb25zIG1heSBkbyBtb3JlIG9m IHN1Y2ggIm92ZXJhbGwgZGlyZWN0aW9uIiANCmRvY3VtZW50cywgYnV0IGluIGdlbmVyYWwsIEkg ZG9uJ3QgdGhpbmsgdGhleSBoYXZlIHRvbyBtdWNoIHN1Y2Nlc3Mgd2l0aCANCnRoZW0uDQoNCj4g SSBiZWxpZXZlIGl0IHdvdWxkIGJlIHNvbWV0aGluZyB0byBiZSByZWZlcmVuY2VkIGluIHRoZSBj aGFydGVyIG9mIHN1Y2ggYQ0KPiBXRywgdG8gY2xhcmlmeSBXSFkgdGhlIHdvcmsgaXMgYmVpbmcg Y29tcGxldGVkLCBpbiBhZGRpdGlvbiB0byB0aGUgb3RoZXINCj4gZ29vZCByZWFzb25zLiBFdmVu IGlmIHdlIGRvbid0IGhhdmUgYW4gUkZDLCB0aGlzIGlkZWEgZG9lcyBuZWVkIGEgc29saWQNCj4g bmFtZS9sYWJlbC4NCg0KV0dzIGdldCBmb3JtZWQgYmVjYXVzZSBlbm91Z2ggaW5kaXZpZHVhbHMg KGFuZCBvZnRlbiBjb21wYW5pZXMgdGhhdCANCmVtcGxveSB0aGVtKSBhcmUgaW50ZXJlc3RlZCBp biBnZXR0aW5nIHNvbWUgc3RhbmRhcmRpemF0aW9uIHdvcmsgZG9uZS4gDQpUaGF0IHdvcmsgbWF5 IGJlIHdheSBhaGVhZCBvZiBhIHRyZW5kLCBtYXkgYmUgaW4gb25lIG9mIHRoZSBjdXJyZW50IA0K dHJlbmRzLCBtYXkgYmUgd2F5IGJlaGluZCBhIHRyZW5kLCBvciBjb21wbGV0ZWx5IHVucmVsYXRl ZCB0byBhbnkgdHJlbmQuDQoNCj4gSSBoYXZlIGluaXRpYWwgaWRlYXMgZm9yIHRoZSBjb250ZW50 IG9mIHN1Y2ggYSBXZWIgQ29udmVyZ2VuY2UgUkZDDQo+IFtBcHBlbmRpeCAxXSwgYW5kIHdoYXQg aXQgbWlnaHQgYmUgdWx0aW1hdGVseSBjYWxsZWQgW0FwcGVuZGl4IDJdDQo+IA0KPiAoSSBhbSBh bHNvIG5ldyB0byBJRVRGIGdlbmVyYWxseSwgc28gSSdtIHN0aWxsIGxlYXJuaW5nLiBCdXQgSSBs aWtlDQo+IGxlYXJuaW5nIGJ5IGRvaW5nLl8NCg0KRXZlcnlib2R5IChpbmNsdWRpbmcgeW91KSBj YW4gc3VibWl0IGFuIEludGVybmV0IERyYWZ0IChleGNlcHQgdGhpcyANCndlZWspLiBTbyB3cml0 aW5nIHVwIHlvdXIgaWRlYXMgYW5kIHN1Ym1pdHRpbmcgYSBkcmFmdCBtYXkgYmUgYSBnb29kIA0K aWRlYS4gTXkgcGVyc29uYWwgYWR2aWNlIHdvdWxkIGJlIHRvIGJlIG1vcmUgZGVzY3JpcHRpdmUg YW5kIGxlc3MgDQpwcmVkaWN0aXZlIG9yIHByZXNjcmlwdGl2ZS4NCg0KUmVnYXJkcywgICBNYXJ0 aW4uDQoNCj4gVGhhbmtzLA0KPiANCj4gVG9kZCBIdWJlcnMNCj4gDQo+IC0tLQ0KPiANCj4gQXBw ZW5kaXggMQ0KPiANCj4gRm9yIHJlYnVpbGRpbmcgb2Ygb2xkZXIgc3RhbmRhcmRzIHRoZSB3ZWIg d2F5OyBPUiwgYnVpbGRpbmcgbmV3IHN0YW5kYXJkcw0KPiB0aGUgd2ViIHdheS4gVGhlIHJlYXNv bnMgc2hvdWxkIGJlIHRoZSBzYW1lLg0KPiANCj4gSW5pdGlhbCBpZGVhcyBmb3IgcmVhc29ucyB0 byBiZSBjb2xsYXRlZCBpbiBzdWNoIGEgZG9jdW1lbnQvcmZjOg0KPiANCj4gLSBBY2Nlc3NpYmxl IGRpcmVjdGx5IGJ5IHdlYiBhcHBsaWNhdGlvbnMgKGphdmFzY3JpcHQpLCByZW1vdmluZyB0aGUg bmVlZA0KPiB0byBwdXNoIHZpYSBhIHNwZWNpYWxpc2VkIGFwcGxpY2F0aW9uIHNlcnZlciBhZGFw dG9yIHNlcnZpY2UgKGVnLiBIVFRQIHRvDQo+IFNNVFApDQo+IC0gVGhlIHJldXNlIG9mIHN0YW5k YXJkIHdlYiBzeXNvcHMgdG9vbHMgKGVnLiBuZ2lueCwgY2VydGlmaWNhdGUNCj4gbWFuYWdlbWVu dCwgc2VydmljZXMgbGlrZSBDbG91ZEZsYXJlIGFuZCBtb3JlKQ0KPiAtIFRoZSByZXVzZSBvZiBz dGFuZGFyZCB3ZWIgZnJhbWV3b3JrcyBhbmQgbGlicmFyaWVzIChlZy4gaGVhZGVyIHBhcnNpbmcs DQo+IGFzeW5jaHJvbm91cyB0aHJlYWRzKQ0KPiAtIFJlZHVjaW5nIHRoZSBkaWZmdXNpb24gb2Yg b3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQgY29udHJpYnV0aW9uDQo+IChyZWRlZmluaW5nIHRoZSBz YW1lIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgc3RhbmRhcmRzLCBhbmQgZGlmZmVyZW50IHNvdXJj ZQ0KPiBjb2RlIGlzIGluZWZmaWNpZW50KS4NCj4gLSBBZGRpdGlvbmFsIGZlYXR1cmVzIGF2YWls YWJsZSBmcm9tIGN1cnJlbnQgYW5kIGZ1dHVyZSB3ZWIgc3RhbmRhcmRzIChlZy4NCj4gcmVkaXJl Y3QsIG1lZGlhLXR5cGUgbmVnb3RpYXRpb24sIGNvbXByZXNzaW9uLCBtdWx0aXBsZXhpbmcsIHBy b3h5aW5nLA0KPiBjYWNoaW5nLCBhdXRoZW50aWNhdGlvbiwgSGVhZGVyIFBhcnNpbmcsIFVSSXMs IHdlbGwtbmFtZWQgZm9sZGVycywNCj4gSWRlbnRpdHksIFNlbWFudGljcywgZXRjLi4pDQo+IC0g TW9yZSBzZWN1cmUgd2l0aCBleGFjdGx5IHRoZSBzYW1lIHNlY3VyaXR5IG1vZGVsIGFzIHdlYiAt IChlZy4gbm8gcGxhaW4NCj4gdGV4dCBlbWFpbCB0cmFuc21pc3Npb24pDQo+IC0gQWxsIHNlY3Vy aXR5L2ZpcmV3YWxscyBsZXZlcmFnaW5nIGFjY3VtdWxhdGVkIFBPUlQgODAvNDQzIGFuZCBIVFRQ DQo+IGludGVsbGlnZW5jZS4NCj4gDQo+IC0tLQ0KPiANCj4gQXBwZW5kaXggMg0KPiANCj4gUG9z c2libGUgbmFtZXMgZm9yIHRoaXMgcHJvY2Vzcw0KPiANCj4gLSBXZWIgUmVjYXN0aW5nDQo+IC0g V2ViIENvbnZlcmdlbmNlDQo+IC0gSHR0cCBDb252ZXJnZW5jZSAoc3BlY2lmaWNhbGx5IEhUVFAg b2YgV2ViIENvbnZlcmdlbmNlKQ0KPiANCg== From nobody Thu Oct 25 18:57: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 14CAB126CC7; Thu, 25 Oct 2018 18:57:23 -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 gtfJ_rs6j13M; Thu, 25 Oct 2018 18:57:20 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 CAA6D1294D7; Thu, 25 Oct 2018 18:57:19 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id v18-v6so2625076edq.13; Thu, 25 Oct 2018 18:57:19 -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=nyrNlPrxJe+FLVfc53JtdK2MzaquxCs7zejUeRWgWcM=; b=Mtva/qpv1dUNy4E8AnU0BVRYcGeW8VCmfijY3TI2VyijzI/mNrJj7vZN4LrNgpbeJo PYUyizcPUAgTo/f2qaNVoeqGKUfLOkAMTvt42zKpl1PvzQLpKXVocHTXZ6cBABqzEgZv PRhvBLXS1Ifaz3B4XU8ukihq8NldG9I3/x8rHfDBlstZ3XdQjTzRPNqtvwEqfmE/QkS0 BVPEVANCgA+ZXLyjpMlTFAaj2iatNarr/LBgQorLSwcBasqEiQLIJgVjdcZWjqOnTL3e TOCZcXPxmFr8sMmafLrXYcO9ZsYF+KYR9NBa4G9mo+vc6Q6B8AgAcO/DX7pLkhJEGERm 39Nw== 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=nyrNlPrxJe+FLVfc53JtdK2MzaquxCs7zejUeRWgWcM=; b=q/Cdg7fm98dTRj9eqlYsG/c+dwgZMCMfP76Cfwpoj9cSf6msLetW1bsedLvrh75asf +IRi7VdCMw6gZqdgh8u6h5geaekUcG42fH9BeQhY8qOSdqJXXU9GyzCbUckLgBhgq0lc bmTyd8/N+7QyDQgdLTQWMc/gZpTNlhE9eryMsEUocxdoJ9B24RiJyUIZLx8vzEQJvBsj Y3vZvPGRDuG3iNOPjbm6AZuTg38EQbaGbiCu2GkJD5U3x0Pz1ajufpFQrqCJBl6gdYwf prwcmKB6xTm6Xk/H7aP/vjmlmVwRl2Fs4EjPcxYAt+M3mtmcFWN3VR4USufswtfsQH5i qVyw== X-Gm-Message-State: AGRZ1gL7Tk+ySAWaFp6MUetYWylQFMwjeeehCx/QFP69rn6d0ZDWf2DR dUEk1s0HjxKX4u7F/1DjaZR1yUBFUhbZV8o7LgsQwjjYCiA= X-Google-Smtp-Source: AJdET5cLWhmGcpztTxNdiqa724sTzll6QLoUaXLKZrQqirf/egZRsBfrkpXucH8nlA2lXVNqWHYtnIp8ob9WBuFif/o= X-Received: by 2002:a17:906:2899:: with SMTP id o25-v6mr899659ejd.53.1540519038084; Thu, 25 Oct 2018 18:57:18 -0700 (PDT) MIME-Version: 1.0 References: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> In-Reply-To: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> From: Todd Hubers Date: Fri, 26 Oct 2018 12:57:05 +1100 Message-ID: To: duerst@it.aoyama.ac.jp Cc: jmap@ietf.org, doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000008ea730579180a02" Archived-At: Subject: Re: [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 01:57:23 -0000 --00000000000008ea730579180a02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, Thanks for your time. At the very least, I seek validation of the necessity for this from others, while I refine my communication of the ideas I'm trying to express. I have been reading a lot of material, and also the intro youtube videos. So I do have a good grasp of the correct approach. I understand the fundamental principles of no voting etc., This is why I was careful to write "collective decision of direction" - such a direction isn't necessarily conscious/formal. However, It would have been better if I wrote "..that RFC could be very comprehensive in cataloguing the reasons why Web Convergence is desirable...". I don't expect such a document to be prescriptive at all. As you say, there is no "decision", although there is an observed "direction" in some IETF proposals and in the industry broadly; this is a tool for decision making and a reference for brevity. It would be a body of work that could be referenced, helping to establish why any organisation would write their standard leveraging Web Standards (and why not). https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ is a fantastic reference, this is exactly the kind of document I was hoping to find. It's a great starting point, if not the exact thing, I was describing. I'll need to spend time and read it in more detail. It might need to be broadened to "Web"; either directly or via a separate new Internet Draft. JMAP is a good example of why such broadening may be useful: The JMAP standard document doesn't actually reference HTTP, I believe it's more about JSON schema than HTTP mechanisms (or perhaps such mechanisms are in other standards that I haven't read yet) - although the charter does mention HTTP - perhaps HTTP is a missing component from the JMAP standard. If I had a fresh stab of a description of a new Internet Draft, it would be "Choosing whether or not to build new standards upon Web Standards". The title "Web Convergence" is probably too prescriptive, "Building Protocols with Web Standards" might be an appropriate title, or "Building Standards based on Web Standards". So with my clarifications above, I would welcome any further criticisms or support, to help guide me in coming weeks. Thanks, Todd On Fri, 26 Oct 2018 at 12:30, Martin J. D=C3=BCrst wrote: > Hello Todd, > > This is just a personal opinion, but based on more than 20 years of > experience with various standards organizations including the IETF. > > On 2018/10/26 09:57, Todd Hubers wrote: > > Hi All, > > > > Is there a document/RFC about the IETFs collective general movement > toward > > re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe > others > > using Web/HTTP/JSON? > > > > I read the introduction of DoH [RFC8484], and noted there was no > reference > > there, so such a document probably doesn't exist. > > I guess you're right. But there may be documents that are somewhat > related. In particular, I'm thinking of > https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/. > > > Instead, it could read something like "Web Convergence is desirable > > [RFCXXXX]", and that RFC could be very comprehensive in the collective > > decision about this direction. It would critically help in determining > when > > a current standard should be considered for Web Convergence. > > The IETF is (at least officially) a collection of individuals. Many of > these individuals see trends like the one you bring up here. But the > IETF as a whole isn't organized or empowered to adapt great trends and > then force everybody to follow them. Where that has been tried, it has > usually not worked extremely well. > > Other standards organizations may do more of such "overall direction" > documents, but in general, I don't think they have too much success with > them. > > > I believe it would be something to be referenced in the charter of such= a > > WG, to clarify WHY the work is being completed, in addition to the othe= r > > good reasons. Even if we don't have an RFC, this idea does need a solid > > name/label. > > WGs get formed because enough individuals (and often companies that > employ them) are interested in getting some standardization work done. > That work may be way ahead of a trend, may be in one of the current > trends, may be way behind a trend, or completely unrelated to any trend. > > > I have initial ideas for the content of such a Web Convergence RFC > > [Appendix 1], and what it might be ultimately called [Appendix 2] > > > > (I am also new to IETF generally, so I'm still learning. But I like > > learning by doing._ > > Everybody (including you) can submit an Internet Draft (except this > week). So writing up your ideas and submitting a draft may be a good > idea. My personal advice would be to be more descriptive and less > predictive or prescriptive. > > Regards, Martin. > > > Thanks, > > > > Todd Hubers > > > > --- > > > > Appendix 1 > > > > For rebuilding of older standards the web way; OR, building new standar= ds > > the web way. The reasons should be the same. > > > > Initial ideas for reasons to be collated in such a document/rfc: > > > > - Accessible directly by web applications (javascript), removing the ne= ed > > to push via a specialised application server adaptor service (eg. HTTP = to > > SMTP) > > - The reuse of standard web sysops tools (eg. nginx, certificate > > management, services like CloudFlare and more) > > - The reuse of standard web frameworks and libraries (eg. header parsin= g, > > asynchronous threads) > > - Reducing the diffusion of open source development contribution > > (redefining the same functions in different standards, and different > source > > code is inefficient). > > - Additional features available from current and future web standards > (eg. > > redirect, media-type negotiation, compression, multiplexing, proxying, > > caching, authentication, Header Parsing, URIs, well-named folders, > > Identity, Semantics, etc..) > > - More secure with exactly the same security model as web - (eg. no pla= in > > text email transmission) > > - All security/firewalls leveraging accumulated PORT 80/443 and HTTP > > intelligence. > > > > --- > > > > Appendix 2 > > > > Possible names for this process > > > > - Web Recasting > > - Web Convergence > > - Http Convergence (specifically HTTP of Web Convergence) > > > --=20 -- Todd Hubers --00000000000008ea730579180a02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for = your time. At the very least, I seek validation of the necessity for this f= rom others, while I refine my communication of the ideas I'm trying to = express.

I have been reading a lot of material, an= d also the intro youtube videos. So I do have a good grasp of the correct a= pproach. I understand the fundamental principles of no voting etc., This is= why I was careful to write "collective decision of direction" - = such a direction isn't necessarily conscious/formal. However, It would = have been better if I wrote "..that RFC could be very comprehensive in= cataloguing=C2=A0the reasons why Web Convergence is desirable...".=C2= =A0

I don't expect such a document to be presc= riptive at all. As you say, there is no "decision", although ther= e is an observed "direction" in some IETF proposals and in the in= dustry broadly; this is a tool for decision making and a reference for brev= ity. It would be a body of work that could be referenced, helping to establ= ish why any organisation would write their standard leveraging Web Standard= s (and why not).

https://datatracker.ietf.org/doc/d= raft-ietf-httpbis-bcp56bis/ is a fantastic reference, this is exactly t= he kind of document I was hoping to find. It's a great starting point, = if not the exact thing, I was describing. I'll need to spend time and r= ead it in more detail. It might need to be broadened to "Web"; ei= ther directly or via a separate new Internet Draft. JMAP is a good example = of why such broadening may be useful: The JMAP standard document doesn'= t actually reference HTTP, I believe it's more about JSON schema than H= TTP mechanisms (or perhaps such mechanisms are in other standards that I ha= ven't read yet) - although the charter does mention HTTP - perhaps HTTP= is a missing component from the JMAP standard.

If= I had a fresh stab of a description of a new Internet Draft, it would be &= quot;Choosing whether or not to build new standards upon Web Standards"= ;. The title "Web Convergence" is probably too prescriptive, &quo= t;Building Protocols with Web Standards" might be an appropriate title= , or "Building Standards based on Web Standards".=C2=A0

So with my clarifications above, I would welcome any furthe= r criticisms or support, to help guide me in coming weeks.

Thanks,

Todd

On Fri, 26 Oct 2018 at 12:30, Martin J= . D=C3=BCrst <duerst@it.aoyama= .ac.jp> wrote:
Hello Todd,
This is just a personal opinion, but based on more than 20 years of
experience with various standards organizations including the IETF.

On 2018/10/26 09:57, Todd Hubers wrote:
> Hi All,
>
> Is there a document/RFC about the IETFs collective general movement to= ward
> re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe ot= hers
> using Web/HTTP/JSON?
>
> I read the introduction of DoH [RFC8484], and noted there was no refer= ence
> there, so such a document probably doesn't exist.

I guess you're right. But there may be documents that are somewhat
related. In particular, I'm thinking of
https://datatracker.ietf.org/doc/draft-= ietf-httpbis-bcp56bis/.

> Instead, it could read something like "Web Convergence is desirab= le
> [RFCXXXX]", and that RFC could be very comprehensive in the colle= ctive
> decision about this direction. It would critically help in determining= when
> a current standard should be considered for Web Convergence.

The IETF is (at least officially) a collection of individuals. Many of
these individuals see trends like the one you bring up here. But the
IETF as a whole isn't organized or empowered to adapt great trends and =
then force everybody to follow them. Where that has been tried, it has
usually not worked extremely well.

Other standards organizations may do more of such "overall direction&q= uot;
documents, but in general, I don't think they have too much success wit= h
them.

> I believe it would be something to be referenced in the charter of suc= h a
> WG, to clarify WHY the work is being completed, in addition to the oth= er
> good reasons. Even if we don't have an RFC, this idea does need a = solid
> name/label.

WGs get formed because enough individuals (and often companies that
employ them) are interested in getting some standardization work done.
That work may be way ahead of a trend, may be in one of the current
trends, may be way behind a trend, or completely unrelated to any trend.
> I have initial ideas for the content of such a Web Convergence RFC
> [Appendix 1], and what it might be ultimately called [Appendix 2]
>
> (I am also new to IETF generally, so I'm still learning. But I lik= e
> learning by doing._

Everybody (including you) can submit an Internet Draft (except this
week). So writing up your ideas and submitting a draft may be a good
idea. My personal advice would be to be more descriptive and less
predictive or prescriptive.

Regards,=C2=A0 =C2=A0Martin.

> Thanks,
>
> Todd Hubers
>
> ---
>
> Appendix 1
>
> For rebuilding of older standards the web way; OR, building new standa= rds
> the web way. The reasons should be the same.
>
> Initial ideas for reasons to be collated in such a document/rfc:
>
> - Accessible directly by web applications (javascript), removing the n= eed
> to push via a specialised application server adaptor service (eg. HTTP= to
> SMTP)
> - The reuse of standard web sysops tools (eg. nginx, certificate
> management, services like CloudFlare and more)
> - The reuse of standard web frameworks and libraries (eg. header parsi= ng,
> asynchronous threads)
> - Reducing the diffusion of open source development contribution
> (redefining the same functions in different standards, and different s= ource
> code is inefficient).
> - Additional features available from current and future web standards = (eg.
> redirect, media-type negotiation, compression, multiplexing, proxying,=
> caching, authentication, Header Parsing, URIs, well-named folders,
> Identity, Semantics, etc..)
> - More secure with exactly the same security model as web - (eg. no pl= ain
> text email transmission)
> - All security/firewalls leveraging accumulated PORT 80/443 and HTTP > intelligence.
>
> ---
>
> Appendix 2
>
> Possible names for this process
>
> - Web Recasting
> - Web Convergence
> - Http Convergence (specifically HTTP of Web Convergence)
>


--
--
Todd Hubers
<= /div>
--00000000000008ea730579180a02-- From nobody Thu Oct 25 19:57: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 AB866130DC9 for ; Thu, 25 Oct 2018 19:57:57 -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 Fgr3R4mec_dT for ; Thu, 25 Oct 2018 19:57:56 -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 69E0F130DC6 for ; Thu, 25 Oct 2018 19:57:56 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9C4834CD27; Thu, 25 Oct 2018 22:57:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23506.33451.615286.881946@gro.dd.org> Date: Thu, 25 Oct 2018 22:57:47 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 02:57:58 -0000 Todd Hubers writes: > Is there a document/RFC about the IETFs collective general movement > toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and > maybe others using Web/HTTP/JSON? I'm curious about the use of the term "re-standardization" here, and suspect my interpretation of it is different than what you intended. I would take the word to mean redefinition, and in that light I'd have a really hard time defining DoH as the DNS being re-standardized. How did you mean it? From nobody Thu Oct 25 20:12: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 516B7130DC9 for ; Thu, 25 Oct 2018 20:12:31 -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 FB9dZCkCnL19 for ; Thu, 25 Oct 2018 20:12:29 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 8712B12D4EA for ; Thu, 25 Oct 2018 20:12:28 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id e5-v6so10332722eds.6 for ; Thu, 25 Oct 2018 20:12:28 -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=SBGxvuxx3GEWPaSh7pZUtE60KNutrLlZ/c0nB+gGyXw=; b=nDoO3Gjb1nzYgPdveqHSBuXYbi23N9dslHRfIPDXidDlb91a7YKzmc570droFjXb1v gzOqXwHvkJxXMwo5C9JdiWNpSKakPYLvpLB5ipzGQkONrgi0OxuR7Wa+w+9LPcb47EnA T36yh5gqSCpDBjaESxi9pTIS4Utpq/zvyAVmtOgUwDsZkL0X2ClGxLFgw3Nnwgh048fA XCkJ686ursnUzCNAcBUKP2ppFsTTD6SF8ItdsU8bVBb21G5zGmISS7PK3nQZiB0Ndzhf FPK7dMB/DNermcNnAq8Bg5DPw4trKuBgByV7Ffc/yVZ54rrSXBwadcyZu+SaTnV144mA VRJA== 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=SBGxvuxx3GEWPaSh7pZUtE60KNutrLlZ/c0nB+gGyXw=; b=V68mvOcQPmeDOR9I2f9laotw4sx7JBa88+G40ly4bkvRTR5WUCDChkQY9iTkuFS/1U BPZJN90anVAfaCX+/bM5GPc/yilMKBr9qu22WaEC65p/YUzL8ZtVf1SO+5erC8wxvXR3 221WoFpT35sp/IWYd28se6F5BPSVD6fZ5DuO4FR/5GwFCX3/ptxj2MtY5BxHNXH1jUpr OFg2gmptUzMqeiQI/x0dTdEOWE9OZl4iKUaYpL9BrZjVr6jv2UWRrB4ESrjeujtnoJ4j LI4Iot8d2dAIHPkmL5HK6zCw+9qQwFLkA3wp/Wt81g4LMwHw0Y7F532juHhOqKT7OO7Y kAsw== X-Gm-Message-State: AGRZ1gLij2slIUOdai6iFiH/FDznQXA+ZXKnrL1ihj2Dt9SY4Cji0hNa SXOK2CaeHGp46oTjR0RilQMJdbbBpL8qSKIRlRgX490r X-Google-Smtp-Source: AJdET5fJfWtHfaQn79GOesj4av7gQxu3StbZ0CZXB5Wtl7RLHkkWpDRv0Gscx+6U1udzTQAZkbp6fZ/D2oei3kom2Xc= X-Received: by 2002:a50:f1cc:: with SMTP id y12-v6mr1405758edl.140.1540523546955; Thu, 25 Oct 2018 20:12:26 -0700 (PDT) MIME-Version: 1.0 References: <23506.33451.615286.881946@gro.dd.org> In-Reply-To: <23506.33451.615286.881946@gro.dd.org> From: Todd Hubers Date: Fri, 26 Oct 2018 14:12:14 +1100 Message-ID: To: tale@dd.org Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000c8d13a057919167e" Archived-At: Subject: Re: [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 03:12:31 -0000 --000000000000c8d13a057919167e Content-Type: text/plain; charset="UTF-8" Hi Dave, This is simply a poor choice of words on my part. I see DoH as a new standard that leverages the DNS binary protocol in the message area. I used the term "re-standardization" to mean a new standard that redefines and the way an older one worked. Most significantly, DNS uses another port for example, but DoH would use port 80/443. So "redefine" is probably better, but "new standard" is probably the best, because it isn't directly superceding - the two standards will live on side by side. Also, "recasting" is another idea I had with respect to DoH. A lot of the same "material" is used, but in another form. Thanks, On Fri, 26 Oct 2018 at 13:58, Dave Lawrence wrote: > Todd Hubers writes: > > Is there a document/RFC about the IETFs collective general movement > > toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and > > maybe others using Web/HTTP/JSON? > > I'm curious about the use of the term "re-standardization" here, and > suspect my interpretation of it is different than what you intended. > I would take the word to mean redefinition, and in that light I'd have > a really hard time defining DoH as the DNS being re-standardized. How > did you mean it? > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- -- Todd Hubers --000000000000c8d13a057919167e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

This is simply a poor choice o= f words on my part. I see DoH as a new standard that leverages the DNS bina= ry protocol in the message area. I used the term "re-standardization&q= uot; to mean a new standard that redefines and the way an older one worked.= Most significantly, DNS uses another port for example, but DoH would use p= ort 80/443.

So "redefine" is probably be= tter, but "new standard" is probably the best, because it isn'= ;t directly=C2=A0superceding=C2=A0- the two standards will live on side by = side.=C2=A0

Also, "recasting" is another= idea I had with respect to DoH. A lot of the same "material" is = used, but in another form.

Thanks,

=
On Fri, 26 Oct 2018 at 13:58, D= ave Lawrence <tale@dd.org> wrote:<= br>
Todd Hubers writes:
> Is there a document/RFC about the IETFs collective general movement > toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and > maybe others using Web/HTTP/JSON?

I'm curious about the use of the term "re-standardization" he= re, and
suspect my interpretation of it is different than what you intended.
I would take the word to mean redefinition, and in that light I'd have<= br> a really hard time defining DoH as the DNS being re-standardized.=C2=A0 How=
did you mean it?

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


--
--
Todd Hubers
<= /div>
--000000000000c8d13a057919167e-- From nobody Mon Oct 29 02:30:15 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 67278130E0A for ; Mon, 29 Oct 2018 02:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boSe28T-zzc4 for ; Mon, 29 Oct 2018 02:30:12 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 64CDA130E09 for ; Mon, 29 Oct 2018 02:30:12 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id x3-v6so7046351lji.13 for ; Mon, 29 Oct 2018 02:30:12 -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=kHpz5t3SCGUARFg5xl9IS7jKvyi3LLjgdwUwKctCqk4=; b=o9utD9K5V62o9W+Dec+rtmX7bu3uTUAqnjx8nHJDXh1RQlWS5qFHrxqvJRgadA4gjD CDM48AbREis31Qeineor+sqz/A4girnno8hCYxCr7UbhMyAfiL6vMOCq1e6GLbuuaZ+S 0R/uWPhxrmjLxgWUY5Ac8BUFDkTkZF8fug+3SbBCOlfX4vi18z7C00AVeJAHI/sljpmm DAQbavEeGfKAXyQrcG84LTX79jNy0CjZGUlgP/C2EBdNNw47ojuID/G/9zZX8eHUqG1K 01dPKKjowSM8/39lwc2tPR4libsaGe95emN451W1HoaFpkKrPmhbjjR+um/GvlBW7KeM Jwjg== 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=kHpz5t3SCGUARFg5xl9IS7jKvyi3LLjgdwUwKctCqk4=; b=Ao8Iyg85DCqh4sQREvYmT35YxE0yrOXptC/odfar3UGDoKvKa9jcriMhhEZiPvFxdD nWKJwdcN2m+vnaIDXt06GX+jTpvnnqwSbATsBdX2T4TIlXr51m+fZ1RuO2rrYit+3tYp o7f9yMxI8MdEwuUt7ZiRW/oliyrIiQCSNONqLayU/520Piommv4nHWkeqRmh9X/RKTW7 gdPTBtJrjaxjBW+AirHOLMv3jz6NDgGv86SAwstOGbOR7umZ/cs5GOdxkJWc/Gw5ILL+ xZsNI+p2DnaetsDi2LHaMnMg+YLdHQV6qeMWYFlNYsrOwpy8jHo5lKkHso5sSx6iWIc2 W8Ag== X-Gm-Message-State: AGRZ1gJNFOy1H07WH6YMduHVCsjFHdDKgVUveoYNsFI/W/ZeawI3mI/n qSQg7A27K871QQL+aYFfEWpugDEkVyr1lgTc0ykAG6H58Zs= X-Google-Smtp-Source: AJdET5cRr4JzgS/MjFmQs30MWqpaxLYbgz/rj8eJGGxP38Gl+osO0h9nj/7cPlSCdC2APf2GVusICSwtefhnCBJ8KnI= X-Received: by 2002:a2e:96c6:: with SMTP id d6-v6mr9391443ljj.35.1540805410081; Mon, 29 Oct 2018 02:30:10 -0700 (PDT) MIME-Version: 1.0 From: Kenji Baheux Date: Mon, 29 Oct 2018 18:29:57 +0900 Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000023162e05795ab769" Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 09:30:15 -0000 --00000000000023162e05795ab769 Content-Type: text/plain; charset="UTF-8" *Apologies for starting a new thread (maybe), I couldn't find a straightforward way of replying to a thread that pre-existed my subscription.* *tl;dr:* I'm involved with Chrome's DNS over HTTPS effort. While I haven't yet read the proposal and I could be missing some important context, I support the use case (i.e. facilitating the discovery of DoH support from an existing resolver). Paul Hoffman said: "I would want to hear that [*no browser vendor is interested in ways to find the DoH version of a resolver* (paraphrasing)] directly from the browser vendors before abandoning this work, particularly because we are hearing a lot of interest from organizations who want it." I'm involved with Chrome's DNS over HTTPS effort. We are considering a behavior where Chrome would identify if the user's existing DNS server supports DoH, and if so, then perform an automatic upgrade (TBD: silent or with an opt in/out prompt). Our short term approach is to have a list of known resolvers that support DoH and do the mapping internally. But, in the long run, this doesn't seems ideal. Also, for custom resolvers, it seems preferable to have an easy configuration path instead of the potentially cumbersome URL scheme + POST/GET choice? So, while I haven't read the proposal, and it's possible that I'm missing important context, I support the use case. -- Kenji BAHEUX Product Manager - Chrome Google Japan --00000000000023162e05795ab769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for starting a new thread (maybe), I couldn't fi= nd a straightforward way of replying to a thread that pre-existed my subscr= iption.

tl;dr:=C2=A0I'm= involved with Chrome's DNS over HTTPS effort. While I haven't yet = read the proposal and I could be missing some important context, I support = the use case (i.e. facilitating the discovery of DoH support from an existi= ng resolver).


Paul Hoffman said:
"I would want to hear that [no browser vendor is intere= sted in ways to find the DoH version of a resolver (paraphrasing)] dire= ctly from the browser vendors before abandoning this work, particularly bec= ause we are hearing a lot of interest from organizations who want it."=

I'm involved with Chrome's DNS over HTTPS= effort. We are considering a behavior where Chrome would identify if the u= ser's existing DNS server supports DoH, and if so, then perform an auto= matic upgrade (TBD: silent or with an opt in/out prompt).=C2=A0
<= br>
Our short term approach is to have a list of known resolvers = that support DoH and do the mapping internally. But, in the long run, this = doesn't seems ideal. Also, for custom resolvers, it seems preferable to= have an easy configuration path instead of the potentially cumbersome URL = scheme=C2=A0+ POST/GET choice?

So, while I haven&#= 39;t read the proposal, and it's possible that I'm missing importan= t context, I support the use case.

--
Kenji BAHEUXProduct Manager - Chrome
Google Japan
--00000000000023162e05795ab769-- From nobody Mon Oct 29 02:48: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 BA80C130E36 for ; Mon, 29 Oct 2018 02:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 44ovuoCxucJf for ; Mon, 29 Oct 2018 02:47:59 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 9A24F130E34 for ; Mon, 29 Oct 2018 02:47:59 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id t10-v6so6664058eds.12 for ; Mon, 29 Oct 2018 02:47:59 -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=T4sGF2x176tcC5hXX8IMkjuZ8njY6zZ7kFDEwMCUZB8=; b=rFqv4Wv2LCg3C+Sum9kUaLo9o/P4Agkl01thU6txwJ0/bgOJNRxBtzwHAfdc/28YYb COPJpAg8ymowTojHwYcER17Jvf3ud+fj8wXWm6kmcM+xzdQp1mDjE+gahQ1qcikYypgc MDQSq0j2iVLJ4mrYErCvxEw5FkgAGl/Gc9Wqe06l+2O0JNnjuePMv9B0AwOlQKq1xjRr TmqX6duZ3+W5309tJKXVyJe2q/5aA0eBJHs6zrpyhxEjHXC1TKM7AWuKEgGVYkW7+MZE L1Wfa+eatToC5j0M8Ogex3rNZwNHoZ6a3Ujw7JXKh3E2hSeQxP6S90+ZLFmyplIoYBL9 xUFg== 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=T4sGF2x176tcC5hXX8IMkjuZ8njY6zZ7kFDEwMCUZB8=; b=giL0vt/f1paMwfzTXdQ8n4+fcJ+Repp8QFeOPkHK0ZdHpabIgjSU/Ditb2DcfXqoa+ 9kY/Nl5ItZPULVmIkJu1OVUkaW7QsHxj0DeMARFSa+3Yb82y/WsANmpsGUvIlI6MN83X 5zKmHKYfs2bGCmB3iWA3P9H0fSPXhL0RCNk4YxQIZi/1WreRlYar7zavCwOCy1u11VAl SFWaWmWW9GQ/HJc4tVqAGrH2F/ii4PD0OY2RIZOT5moO6Vp77PM4T19e21svB+l4GVTu ZIk987bkZRWjdi4lTAIVDuXyRX+X2kHm2A12Eor0omQJWk4m4HJbY6m8dbn15ECqvGjp 4lEQ== X-Gm-Message-State: AGRZ1gKJZfOG40Lm6qQjmN3Viwv/4/95Ef8UVIAcagi3d2Cy7AgWq2ve 8oT4lmcJmBnCle4PH659pjWftLTTnaB9IAnLibrkl5tVwMc= X-Google-Smtp-Source: AJdET5e/MbZ/Smw5D2cRxQuX8fxUgrHJYDt0ri5QVfr722neiMAXwJjMclMIWELd7kgLt/vItwemsNcrDXtmJEUBUjo= X-Received: by 2002:a50:9724:: with SMTP id c33-v6mr12781712edb.47.1540806477991; Mon, 29 Oct 2018 02:47:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Hubers Date: Mon, 29 Oct 2018 20:47:44 +1100 Message-ID: To: kenjibaheux=40google.com@dmarc.ietf.org Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9d3c505795af66f" Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 09:48:02 -0000 --000000000000c9d3c505795af66f Content-Type: text/plain; charset="UTF-8" Kenji, I have a longterm desire to develop a protocol for recursive service discovery that works through a hierarchy of nested gateways. Primarily, this is so applications can be more considerate of user's internet costs, allowing the querying for information about the ISP service contract boundaries and usage status; but I also foresee other uses as well. I am planning to start incubating the idea in the research-working-group nmrg. While it won't satisfy your needs today (and isn't guaranteed to become a standard), perhaps you might find this worth your support? I won't go into detail here and now, but you can find my message here https://www.ietf.org/mail-archive/web/nmrg/current/msg01989.html. Regards, Todd Hubers Software Engineer On Mon, 29 Oct 2018 at 20:30, Kenji Baheux wrote: > *Apologies for starting a new thread (maybe), I couldn't find a > straightforward way of replying to a thread that pre-existed my > subscription.* > > *tl;dr:* I'm involved with Chrome's DNS over HTTPS effort. While I > haven't yet read the proposal and I could be missing some important > context, I support the use case (i.e. facilitating the discovery of DoH > support from an existing resolver). > > > Paul Hoffman said: > "I would want to hear that [*no browser vendor is interested in ways to > find the DoH version of a resolver* (paraphrasing)] directly from the > browser vendors before abandoning this work, particularly because we are > hearing a lot of interest from organizations who want it." > > I'm involved with Chrome's DNS over HTTPS effort. We are considering a > behavior where Chrome would identify if the user's existing DNS server > supports DoH, and if so, then perform an automatic upgrade (TBD: silent or > with an opt in/out prompt). > > Our short term approach is to have a list of known resolvers that support > DoH and do the mapping internally. But, in the long run, this doesn't seems > ideal. Also, for custom resolvers, it seems preferable to have an easy > configuration path instead of the potentially cumbersome URL scheme + > POST/GET choice? > > So, while I haven't read the proposal, and it's possible that I'm missing > important context, I support the use case. > > -- > Kenji BAHEUX > Product Manager - Chrome > Google Japan > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- -- Todd Hubers --000000000000c9d3c505795af66f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kenji,

I have a longterm desire to develop a protocol for recursive service dis= covery that works through a hierarchy of nested gateways. Primarily, this i= s so applications can be more considerate of user's internet costs, all= owing the querying for information about the ISP service contract boundarie= s and usage status; but I also foresee other uses as well. I am planning to= start incubating the idea in the research-working-group nmrg.

While it won't satisfy your needs today (and isn't guarantee= d to become a standard), perhaps you might find this worth your=C2=A0suppor= t? I won't go into detail here and now, but you can find my message her= e=C2=A0https://www.ietf.org/mail-archive/web/nmrg/current/msg01989.html.



Apologies for starting a new thread (maybe), I couldn&= #39;t find a straightforward way of replying to a thread that pre-existed m= y subscription.

tl;dr:=C2= =A0I'm involved with Chrome's DNS over HTTPS effort. While I haven&= #39;t yet read the proposal and I could be missing some important context, = I support the use case (i.e. facilitating the discovery of DoH support from= an existing resolver).


Paul Hoffma= n said:
"I would want to hear that [no browser vendor= is interested in ways to find the DoH version of a resolver (paraphras= ing)] directly from the browser vendors before abandoning this work, partic= ularly because we are hearing a lot of interest from organizations who want= it."

I'm involved with Chrome's DNS = over HTTPS effort. We are considering a behavior where Chrome would identif= y if the user's existing DNS server supports DoH, and if so, then perfo= rm an automatic upgrade (TBD: silent or with an opt in/out prompt).=C2=A0

Our short term approach is to have a list of known = resolvers that support DoH and do the mapping internally. But, in the long = run, this doesn't seems ideal. Also, for custom resolvers, it seems pre= ferable to have an easy configuration path instead of the potentially cumbe= rsome URL scheme=C2=A0+ POST/GET choice?

So, while= I haven't read the proposal, and it's possible that I'm missin= g important context, I support the use case.

--
Kenji BAHEUX
Product Manager -= Chrome
Google Japan
<= /div>
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--
--
Todd Hubers
<= /div>
--000000000000c9d3c505795af66f-- From nobody Mon Oct 29 05:18: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 E8BFB130EDF for ; Mon, 29 Oct 2018 05:18: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 PcXZwQ0FSRHa for ; Mon, 29 Oct 2018 05:18:11 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 C2659130EDA for ; Mon, 29 Oct 2018 05:18:10 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id j124so1803317vsd.4 for ; Mon, 29 Oct 2018 05:18:10 -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=eVe4pWIy8ySIwc9jQMjjigiNS2P+/aq6CN3F/i8nxA4=; b=m7xhRSk+9l8watGbdnybPZvM4SCziBoaQAV5MCj9OyjDnma+fs5MTmKofM4l0ryrZs 5t7OZiZda6QDR6Wt2S75UY2GQpKrV/qaoO6jaz6y71XqadNy01ySuf2KoRh1SCoK00Ne fz/eHXXRxaJ5cqrS0Ys28j+Sdiw3P1akhOfqLdtXNGbvYJPZiptrO2eOmUswKU5gu7mP pecTINR66BxsG6AdSnZf2XjWGnxJOJa8ANpsHTjNC7H+tSwr9gDnhujXKDdd7TAx873h 2BECJHW3Ql8GOHMZ2mU5vD9+kuluJRPR7ID3ck7rNEPPEcCL9R5WaUEmH209PST1yCdh KL5A== 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=eVe4pWIy8ySIwc9jQMjjigiNS2P+/aq6CN3F/i8nxA4=; b=GdqDYVWvQBAWDm5DbbxG31ybHoOQCTDfvMO0ajzoevPwcyoz3qTtaIbALlEza0M4T5 S4+iLJQESkK530HgmI+PSwlURDRazCJZut3FuA+ezKhGwy0G1UcXz9XI6scoF/BEmPvH PBmbm/h/ST8XqLOb+KFSvlEzONHz8O3U/m4yAKRF5sdQCKhj+SYG4ScJHw4K76m+W7DY /VomTZSs56Jdxrjf2OrU1V0cVdUOu1JryDyUmhIilwBQ91WRKM9NmrkhgT4kCRvgxNWv Xz0L5hUTZaGPFqquYnND6mEj33Omb9fMgvuYe4rKdrKtyHXEvIoQvMK6r5AwhPcmplhd 6U6w== X-Gm-Message-State: AGRZ1gISkX8yMVeBIAGIcAs3ng1ZArqJ3aEUVvVVMBCpgI0AFJsGV3/z a0J5C1aaH1B9bcocp5ldSPPCwQ== X-Google-Smtp-Source: AJdET5fWTy6FtFUrJiXqal0vo9TmmmEbdXWpZBhiry1OKx36j6JORmaIEGdozrnr9HkvtBu4ykdgCQ== X-Received: by 2002:a67:4285:: with SMTP id p127mr3346853vsa.134.1540815489589; Mon, 29 Oct 2018 05:18:09 -0700 (PDT) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v127-v6sm5573016vke.46.2018.10.29.05.18.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 05:18:09 -0700 (PDT) From: Ted Lemon Message-Id: <170BA2E7-48EA-411C-87C8-6F2B28BB2B8A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_14F5D816-1D35-4FA3-AC0E-B5458F6466DD" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.42\)) Date: Mon, 29 Oct 2018 08:18:08 -0400 In-Reply-To: Cc: doh@ietf.org To: Kenji Baheux References: X-Mailer: Apple Mail (2.3445.100.42) Archived-At: Subject: Re: [Doh] Associating a DoH server with a resolver X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 12:18:13 -0000 --Apple-Mail=_14F5D816-1D35-4FA3-AC0E-B5458F6466DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2018, at 5:29 AM, Kenji Baheux = wrote: > I'm involved with Chrome's DNS over HTTPS effort. We are considering a = behavior where Chrome would identify if the user's existing DNS server = supports DoH, and if so, then perform an automatic upgrade (TBD: silent = or with an opt in/out prompt).=20 Do you just bypass DNS-over-TLS? That's a lot easier for a home = gateway to do. --Apple-Mail=_14F5D816-1D35-4FA3-AC0E-B5458F6466DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 29, 2018, at 5:29 AM, Kenji Baheux <kenjibaheux=3D40google.com@dmarc.ietf.org> = wrote:
I'm involved with Chrome's DNS over = HTTPS effort. We are considering a behavior where Chrome would identify = if the user's existing DNS server supports DoH, and if so, then perform = an automatic upgrade (TBD: silent or with an opt in/out = prompt). 

Do you just = bypass DNS-over-TLS?   That's a lot easier for a home gateway to = do.


= --Apple-Mail=_14F5D816-1D35-4FA3-AC0E-B5458F6466DD--