From nobody Sat May 12 15:30:41 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A69127873 for ; Sat, 12 May 2018 15:30:39 -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 nzX3cnE-0Kit for ; Sat, 12 May 2018 15:30:38 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6117F126CC7 for ; Sat, 12 May 2018 15:30:38 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 May 2018 15:30:36 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sat, 12 May 2018 15:30:35 -0700 From: Paul Hoffman To: "driu@ietf.org" Thread-Topic: How to describe various flavors of DNS resolvers Thread-Index: AQHT6kDYf7R1n6VnvUm4AoytNMJuww== Date: Sat, 12 May 2018 22:30:34 +0000 Message-ID: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AB6C8117502764E9A91783ED0604C6D@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 22:30:39 -0000 Greetings. This mailing list has many purposes, but a (hopefully easy) one = is: how should DNS-over-TLS be described in protocols like DHCP? Should the= re be a separate DHCP option for naming DNS-over-TLS servers to the DHCP cl= ient? If not, how should clients upgrade from DNS-over-53 to DNS-over-TLS? And: who wants to write the Internet Draft for this? --Paul Hoffman= From nobody Sat May 12 16:19:43 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5761241F5 for ; Sat, 12 May 2018 16:19:42 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jRRAhPEz2rM for ; Sat, 12 May 2018 16:19:40 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69E5129C51 for ; Sat, 12 May 2018 16:19:36 -0700 (PDT) Received: from butte-480.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 2E2A593A; Sat, 12 May 2018 19:18:45 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FF7A683F-C3D2-4847-B62C-282604F99646" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 May 2018 19:19:34 -0400 In-Reply-To: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> Cc: "driu@ietf.org" To: Paul Hoffman References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 23:19:42 -0000 --Apple-Mail=_FF7A683F-C3D2-4847-B62C-282604F99646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 12, 2018, at 6:30 PM, Paul Hoffman = wrote: >=20 > Greetings. This mailing list has many purposes, but a (hopefully easy) = one is: how should DNS-over-TLS be described in protocols like DHCP? = Should there be a separate DHCP option for naming DNS-over-TLS servers = to the DHCP client? If not, how should clients upgrade from DNS-over-53 = to DNS-over-TLS? >=20 > And: who wants to write the Internet Draft for this? >=20 > --Paul Hoffman This is something Willem and I have been working on: = https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/draft= -tpwt-dhc-dns-discovery.txt = But Ted Lemon is concerned that learning about private DNS over DHCP is = not much benefit because you can=E2=80=99t trust the DNS server you = learn about. We have been discussing this is more detail and so I wrote this threat = document to try and work through it: = https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/threa= t.md = This is still a work in progress and talks are ongoing. 1. In the presence of DNSSEC, the responses can be shown to be = trustworthy. In the absence of DNSSEC, there are still some benefits in = my opinion. 2. I think there may be a benefit for operating system vendors and/or = dhclient vendors to have a black list / white list. Something similar is done today with browser vendors / operating = system vendors with https://hstspreload.org 3. Any DNS server providing DNS over TLS or DNS over HTTPS should have = DNSSEC records to show they are authentic servers and TLSA records to = ensure the client is talking to the actual server. Other out of band = mechanisms such as SPKI pinning could be used but distributing this over = DHCP is worthless because having the network provider include the = information needed to check the network provider is not helpful. But = even DNSSEC records for the server do not guarantee the responses that = don=E2=80=99t have DNSSEC validation are not tampered with. SIG(0) can = help. See the threat document. 4. If a well known DNS over TLS server like 1.1.1.1 or 9.9.9.9 is = blocked, then the DHCP client is probably in a hostile environment. If = it can=E2=80=99t verify through DNSSEC, the records it learns, it = probably should disconnect. But how do we know we can trust 1.1.1.1 or = 9.9.9.9? I welcome more discussion and feedback. Thanks, Tom --Apple-Mail=_FF7A683F-C3D2-4847-B62C-282604F99646 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 12, 2018, at 6:30 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:

Greetings. This mailing list has many purposes, but a = (hopefully easy) one is: how should DNS-over-TLS be described in = protocols like DHCP? Should there be a separate DHCP option for naming = DNS-over-TLS servers to the DHCP client? If not, how should clients = upgrade from DNS-over-53 to DNS-over-TLS?

And: who wants to write the Internet Draft for this?

--Paul Hoffman

This is = something Willem and I have been working on:


But Ted Lemon is concerned that learning about = private DNS over DHCP is not much benefit because you can=E2=80=99t = trust the DNS server you learn about.

We have been discussing this is more detail and so = I wrote this threat document to try and work through it:


This is still a = work in progress and talks are ongoing.

1. In the presence of DNSSEC, the responses can be = shown to be trustworthy. In the absence of DNSSEC, there are still some = benefits in my opinion.

2. I think = there may be a benefit for operating system vendors  and/or = dhclient vendors to have a black list / white list.
  =   Something similar is done today with browser vendors / operating = system vendors with https://hstspreload.org

3. Any DNS server providing DNS over TLS or DNS = over HTTPS should have DNSSEC records to show they are authentic servers = and TLSA records to ensure the client is talking to the actual server. = Other out of band mechanisms such as SPKI pinning could be used but = distributing this over DHCP is worthless because having the network = provider include the information needed to check the network provider is = not helpful. But even DNSSEC records for the server do not guarantee the = responses that don=E2=80=99t have DNSSEC validation are not tampered = with. SIG(0) can help. See the threat document.

4. If a well known DNS over TLS server like = 1.1.1.1 or 9.9.9.9 is blocked, then the DHCP client is probably in a = hostile environment. If it can=E2=80=99t verify through DNSSEC, the = records it learns, it probably should disconnect. But how do we know we = can trust 1.1.1.1 or 9.9.9.9?

I = welcome more discussion and feedback.

Thanks,
Tom


= --Apple-Mail=_FF7A683F-C3D2-4847-B62C-282604F99646-- From nobody Mon May 14 03:00:00 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C524126E64 for ; Mon, 14 May 2018 02:59:58 -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 dfO5W4551PfO for ; Mon, 14 May 2018 02:59:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 C2F5B1241F8 for ; Mon, 14 May 2018 02:59:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fIAGn-0000FaC; Mon, 14 May 2018 11:59:53 +0200 Message-Id: To: driu@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> In-reply-to: Your message of "Sat, 12 May 2018 19:19:34 -0400 ." Date: Mon, 14 May 2018 11:59:53 +0200 Archived-At: Subject: Re: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 09:59:58 -0000 > This is something Willem and I have been working on: > > [2]https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/maste > r/draft-tpwt-dhc-dns-discovery.txt For IPv6 it is unfortunately also necessary to consider router advertisements. It might be worth trying to align the DHCPv6 options and any RA options such that they use as much as possible the same conceptual model. > But Ted Lemon is concerned that learning about private DNS over > DHCP is not much benefit because you cant trust the DNS server > you learn about. > 3. Any DNS server providing DNS over TLS or DNS over HTTPS should > have DNSSEC records to show they are authentic servers and TLSA > records to ensure the client is talking to the actual server. I wonder if, even just as strawman, we should document how to signal DNS over TLS and DNS over HTTPS just using DNS, i.e. - DANE in the reverse zone can signal TLS or HTTPS - the PTR can be used as ADN - SRV records can be used to specify ports as well as ADNs and also signal DNS over TLS or HTTPS. The advantage is that no new wire representations have to be introduced. The disavantage it that it only works if the operator of the resolver has control over reverse DNS. Note that for IPv6, it may take a long time before router vendors support the required changes to router advertisements and some client device vendors seem to have strong objections against the use of DHCPv6. From nobody Mon May 14 21:46:31 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416D9129C51 for ; Mon, 14 May 2018 21:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyVkOD607Sc0 for ; Mon, 14 May 2018 21:46:27 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1951D12EAC8 for ; Mon, 14 May 2018 21:46:27 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id p4-v6so14474884wrh.3 for ; Mon, 14 May 2018 21:46:27 -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=EaAHRh9oIj43g+1EPxCkiVUuqKsbAmX8j/lEZRAVdLc=; b=h9YqbiBlvBHwkAU+fVWeAY4YEwcdXS0oUZ44vSNpUlw9siqLgviezoLsFH0kz1OHmh ks5eOnThTqmgfZeFBd3PuV7Y6PMqJPRtY3kIulsQ1NMycYjUba9T2WlVT+5ZqDT+I0ZC 0Kik3+GZ4L9mMkFBkevf3eXZ0Jeja0Bw7SkVS/d3jFYZ62k9Nj0459y0q5LfYKnETLBA QfUvNFGY+8Zmm9TtxHuHQXZECIbXDgxuvfgbayCldmM7tm2DFh7eKd1T6kASGIZdgLHk xMiiVzsWFIE9YLbxd8+3FTgsrPwGVMJbyWIz6soHfqwVI7Wpt0DeKZCtTxfEgEmhQ6jg FWHw== 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=EaAHRh9oIj43g+1EPxCkiVUuqKsbAmX8j/lEZRAVdLc=; b=mkYEp2qtQyIUCR6jlHKnyomESmlGVYGMoN98EqtGXHcfWEZRHVEeZ/wTYJqwoF4zx8 lhSQQG3HwFysBqOmkEf/m6+IpE/8e0Yn9vdJNctCw68tv0j0q9Aw08TnxW/kz/wq3EMZ pu37Be7VIzaE9/I825tVRkTtnk4YGXX4o1KnPUivmADkWCHNoaKAO5iNaM0RwaR+pHuD R9QJSgmQSW2OZr4FWCLmS4WSbYORjDgCbC6AtxQinVvrvPVCv1rdDLoBf25lcYQqqnpx SwyxIXGhXog3QMhdMUg9uUvMAyKmYUPlkwOs4WKXsXg1phkQRkoIYnD5ElyHFa/o2mpP 5IPA== X-Gm-Message-State: ALKqPwewpO+SYW6gHpZJgfNHOH9G6+iAB3ZaNYcU2RfnooKF6MvT2l/q LTVZbgsCEJc9YYGdnZXIBOhQ7bJo69oHudgw+dCDIm8d X-Google-Smtp-Source: AB8JxZrzDDKnEy/m0+96OobOZyI5Fpc0qKl3aelG5BcJa92d8z0HYMTW+jbTFvPycYfxf3UFmR2Gfy2YqG6uL+T/ENg= X-Received: by 2002:adf:9544:: with SMTP id 62-v6mr8463988wrs.74.1526359585271; Mon, 14 May 2018 21:46:25 -0700 (PDT) MIME-Version: 1.0 References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> In-Reply-To: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> From: Erik Kline Date: Tue, 15 May 2018 13:46:11 +0900 Message-ID: To: Paul Hoffman Cc: driu@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e92ab1056c37483e" Archived-At: Subject: Re: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 04:46:29 -0000 --000000000000e92ab1056c37483e Content-Type: text/plain; charset="UTF-8" > Greetings. This mailing list has many purposes, but a (hopefully easy) one is: how should DNS-over-TLS be described in protocols like DHCP? Should there be a separate DHCP option for naming DNS-over-TLS servers to the DHCP client? If not, how should clients upgrade from DNS-over-53 to DNS-over-TLS? I'm not sure I understand the benefit of trying to provide this extra information. I think clients will need to probe nameservers for their capabilities. Do we think TLS-only nameservers are a likely operational model? --000000000000e92ab1056c37483e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8 LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2 9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgvMWvEj36DKa6heDKdxLb6fVUgi/iJJ2P KXGnLsIJ68cwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNTE1 MDQ0NjI1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGHQr+gkvj7YWMK5vM8uV0c/81t/e8PPX+gz0EWvQnPrKV7uTitz zhtjG0+5Ql5S6jrpelDsZMhFvsCSt7833UBi4mE3+LseNqptQsS0HUdC15lmf4UuAm++VJqEFtqP +yLKsY9bltwK7DHPkpunGcKuMCgjuZ2SCDalQWOhqVS4fcIzbXs0uzLwWZaPGRLnaCkLgerQRM7i krCe0wmsLdrkaJVF1P3w1Ly4FdraV2Ue5Z36u7xMhq/s7oFBsuvmTgnv/o8fBP+Qr9aoCoqCWbiP EyaFgPF1/llpoy+yx1J6n+K5RkXWEro2yWjC7Eyx+lLyr3Ma2RviOWpPLVnbkEk= --000000000000e92ab1056c37483e-- From nobody Tue May 15 07:51:47 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D57E12D80F for ; Tue, 15 May 2018 07:51:45 -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 qRLrB9Xa9wb7 for ; Tue, 15 May 2018 07:51:43 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43148127137 for ; Tue, 15 May 2018 07:51:36 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 15 May 2018 07:51:34 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 15 May 2018 07:51:33 -0700 From: Paul Hoffman To: Erik Kline CC: "driu@ietf.org" Thread-Topic: [Ext] [Driu] How to describe various flavors of DNS resolvers Thread-Index: AQHT7Fw3cG0Zh009oUyAmE+Cu98Vpw== Date: Tue, 15 May 2018 14:51:32 +0000 Message-ID: References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@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=_2AC4D985-3828-4164-BFBF-440D3CAE7443"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Driu] [Ext] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 14:51:45 -0000 --Apple-Mail=_2AC4D985-3828-4164-BFBF-440D3CAE7443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 14, 2018, at 9:46 PM, Erik Kline wrote: > I'm not sure I understand the benefit of trying to provide this extra > information. I think clients will need to probe nameservers for their > capabilities. >=20 > Do we think TLS-only nameservers are a likely operational model? "Probe for DNS-over-TLS" is a possible outcome, but yes, there are = parties who *only* want to provide privacy-enhanced resolvers. In the = DOH WG, there has also been discussion of how to prevent downgrade = attacks from privacy-enhanded to clear-on-port-53. --Paul Hoffman --Apple-Mail=_2AC4D985-3828-4164-BFBF-440D3CAE7443 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCCBZUw ggR9oAMCAQICEAHlUc/Wu3bw9qj3vjSgnBAwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDYyOTAwMDAwMFoXDTE4MDYyOTEy MDAwMFowgbQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRUwEwYDVQQDEwxQYXVsIEhvZmZtYW4xJTAjBgkqhkiG9w0BCQEWFnBhdWwu aG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFp+z8d5Ge 3VPgAkNc47Br7C7lVgMGi3KPyzdtdsjKDFmk8G0b4YNv+pmv8TvISr4XRpHf/+u/+1n7wkKhjVjk rY32PWhXEzk5Vky2MGaS9DiNSGwmyY6FXXxwFR8/e9f/DNZy2UEeYFrHz/kIzf5cwwdfrNEPkds8 FNfftOzdg195KOGVbIyC2DmnA8R0VNN9Ymv8U9+uojD0uuQSxK2z0NspQZdjjthk9CgLtGTDqIsk Ji4AuAkwjCmff5aHlEY+G5GyHRuEpczLGqRIEbpLoRTFnLTrhrbshkxsYQM5pNwWTidtw9CWWEmd RX96sMvym3SdYGkhfFWlpgoF7/3nAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQU9btKWvkJMHw27U3VEwvQ+VCtpqEwDAYDVR0TAQH/BAIwADAh BgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB1Zc/uexWtNIjStm4b/HN1W5/Hcl4eE58O lh+2JgLIsgY7Ten6HoOx/4LNFKPQlnCMdyy1XqkF9FDU/7O+a98B+++tWTvk3U7EBqKGe7XLw1oq w6ymSNZ/gn4L+Bh4Ka5I3RY15+tWxfAOiHkLFHGFvU7NA2Oqsue8tD5fZD/+UNNlQ5YVDiQCgkN1 miFgb6tkX6kLnuItIU1LSFi8etVL+5MN7NyuH2Y/Ta7h3p+JsIvdAGe2F1+9RiVMkHDSRgiS05qo TpdWBJ0hnX9B/0nSs+gXeZbGkO1KXS4+KC9dt+FriAhd5fHc/9g8qtbEkh2TdSZdfse7idXAG+UB tAx3MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAB5VHP1rt28Pao9740oJwQMAkGBSsOAwIaBQCg ggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDUxNTE0NTEz M1owIwYJKoZIhvcNAQkEMRYEFGMYyu6UuwjRDFXz9k4Tj21Wa7+PMIGIBgkrBgEEAYI3EAQxezB5 MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2 qPe+NKCcEDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2qPe+NKCcEDANBgkqhkiG9w0BAQEFAASCAQAU6cdZ mTfHZk+qhMbseYGTBiRbJj65hTvKegrofNavkStVPZ0YwDNeQ4OSKO0F3v1rpRCyTUcvDLE70hph 74IC8F30TH/TX9d0plY/USE2WenOvF5zhLwHtd3F65aXAWCdvsCL2mYgpOKUjCz+/sGCWM4AijmT k8odtYuOL8UpAkIPfm5FxUvvHotKqVZ8vlIQVWHMhDyywmflPTtNLgE4wwVPnapHL/PTYAWCA1gK z2wIM4gFiwHe0w8hzr7knHecKEjMVpKzzy4da2jCKI8ODDqIVpECj0KVL1CP/33CoaRdD7le5XwV YVV29dWAeJl2Ky/jPTHGEaKxk9jhAwJ7AAAAAAAA --Apple-Mail=_2AC4D985-3828-4164-BFBF-440D3CAE7443-- From nobody Tue May 15 09:07:25 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C43126B6E for ; Tue, 15 May 2018 09:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CeVtI8-z4Cm for ; Tue, 15 May 2018 09:07:20 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC2D124207 for ; Tue, 15 May 2018 09:07:20 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 17810 invoked from network); 15 May 2018 18:07:16 +0200 Received: from acnx101.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.177.101]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 15 May 2018 18:07:16 +0200 To: driu@ietf.org, Paul Hoffman References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: Date: Tue, 15 May 2018 18:07:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X8ZhORggA8Nz5a4F3wzp3izMC0e4eROq6" X-WP-MailID: 620a3a644bdcab37a55819f2716bac04 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [UWMk] Archived-At: Subject: Re: [Driu] [Ext] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 16:07:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X8ZhORggA8Nz5a4F3wzp3izMC0e4eROq6 Content-Type: multipart/mixed; boundary="NEYMBhdFvDjHZGJyTQhtAdUdM3NqKXUzc"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: driu@ietf.org, Paul Hoffman Message-ID: Subject: Re: [Driu] [Ext] How to describe various flavors of DNS resolvers References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> In-Reply-To: --NEYMBhdFvDjHZGJyTQhtAdUdM3NqKXUzc Content-Type: multipart/mixed; boundary="------------39E5258E792FB7469B5B9AC7" Content-Language: pl This is a multi-part message in MIME format. --------------39E5258E792FB7469B5B9AC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 15.05.2018 o=C2=A016:51, Paul Hoffman pisze: > On May 14, 2018, at 9:46 PM, Erik Kline wrote: >> I'm not sure I understand the benefit of trying to provide this extra >> information. I think clients will need to probe nameservers for their= >> capabilities. >> >> Do we think TLS-only nameservers are a likely operational model? >=20 > "Probe for DNS-over-TLS" is a possible outcome, but yes, there are part= ies who *only* want to provide privacy-enhanced resolvers. In the DOH WG,= there has also been discussion of how to prevent downgrade attacks from = privacy-enhanded to clear-on-port-53> > --Paul Hoffman IMHuO, preventing downgrade attacks will not work because there are likel= y going to be environments that will block DNS-over-TLS and common DOH servers (C= hina comes to mind). Browsers will have to keep working for these people. Greetings, Mateusz --------------39E5258E792FB7469B5B9AC7 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------39E5258E792FB7469B5B9AC7-- --NEYMBhdFvDjHZGJyTQhtAdUdM3NqKXUzc-- --X8ZhORggA8Nz5a4F3wzp3izMC0e4eROq6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa+wWyAAoJEPvWWrhhCv7G4c0QAIngvbLf3qBTdFWQISt8jJJu 0ZUD71RNJh/WEpn1wYpCx/IWzaF6k59Ud7yabl3CaE2+ph3fI5C5ip9Sa+NVT6za aBPp9CRFjk6YwCFbSkzTT3LtTZrw3gUGkcgz0rT3esFwZsbKAy2nuA6FjLT8ViWm n7yjna1V8NCkeYPw4WJHuTy/0ulssujh6WKEYF88ujyF3VsLIpRl0uJLmWMR8g+j 0znWg77dYLeySiJe5z27CH1PTtEuwKTZGd2j7p9BOJLCM1jyzlxjKUsuaIXWeRHt LY61qdFsD4abyMDFEusTuUEFFlY7V0RgO4Q4nsDCaf6ApotmRgsM14FyghH1KOg/ lyhuueklVdeDbVrvQU34XFnNLNmhQIx6nWGb5PDcgv2wH9FzvIIiy0DABvBzKOXy hX81IbPYKXNX+kzuuSmBuLnBHb2Phf/Z1KWwpApyWL6cmjyutCDmFOFS8LMoHRBb WczkkwHPuxyqJ5yKGiLdqdNGBxUKk17kxYZGnqwAphZrqgrvPrsSgSLUEH6xp6MH 7YeLgWqHuKon8rzPHAcQdlcRxAo+MGJxdljA44wzgb6dxiV9e0ulP34Vj4Sx+Q66 vUVdN/Cf+bbqByohtPo5iePmXAKdOie4sLgMN+8PeNueBnTZ+GS7YXjbXrvJKICO eU4PZBLMd3j7dTq77H95 =COU+ -----END PGP SIGNATURE----- --X8ZhORggA8Nz5a4F3wzp3izMC0e4eROq6-- From nobody Tue May 15 09:20:22 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90B012421A for ; Tue, 15 May 2018 09:20:20 -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 ip422-kQ5o8F for ; Tue, 15 May 2018 09:20:16 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F7912D77D for ; Tue, 15 May 2018 09:20:15 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.237.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 74CA8C68; Tue, 15 May 2018 12:19:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: Date: Tue, 15 May 2018 12:20:11 -0400 Cc: driu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C63E491-2CA9-46BE-B54F-261B5A21AE07@bangj.com> References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> To: Philip Homburg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 16:20:21 -0000 > On May 14, 2018, at 5:59 AM, Philip Homburg = wrote: >=20 >> This is something Willem and I have been working on: >>=20 >> = [2]https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/maste >> r/draft-tpwt-dhc-dns-discovery.txt >=20 > For IPv6 it is unfortunately also necessary to consider router = advertisements. > It might be worth trying to align the DHCPv6 options and any RA = options=20 > such that they use as much as possible the same conceptual model. Yes, this makes sense. We will also consider IPv4 if/when there is = general agreement about IPv6. >> But Ted Lemon is concerned that learning about private DNS over >> DHCP is not much benefit because you cant trust the DNS server >> you learn about. >=20 >> 3. Any DNS server providing DNS over TLS or DNS over HTTPS should >> have DNSSEC records to show they are authentic servers and TLSA >> records to ensure the client is talking to the actual server. >=20 > I wonder if, even just as strawman, we should document how to signal = DNS over > TLS and DNS over HTTPS just using DNS, i.e. > - DANE in the reverse zone can signal TLS or HTTPS > - the PTR can be used as ADN > - SRV records can be used to specify ports as well as ADNs and also = signal > DNS over TLS or HTTPS. >=20 > The advantage is that no new wire representations have to be = introduced.=20 > The disavantage it that it only works if the operator of the resolver = has > control over reverse DNS. I think this is always a possibility (even now) but it causes delays so = it would be better to explicitly advertise the service offering. It=E2=80=99s also possible to have an SRV record advertising the service = that can be verified and the server authenticated. > Note that for IPv6, it may take a long time before router vendors = support > the required changes to router advertisements and some client device = vendors > seem to have strong objections against the use of DHCPv6. Yes, definitely. This is an attempt at determining what the community wants and hashing = out the details. The difference between using RA or DHCPv6 mechanisms is = mostly the same from the trust / threat on DNS perspective since the = network operator controls both. Thanks for the comments, Tom From nobody Tue May 15 09:32:14 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225F12D77D for ; Tue, 15 May 2018 09:32:12 -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 z7WrNGE9unHd for ; Tue, 15 May 2018 09:32:11 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C40126BF7 for ; Tue, 15 May 2018 09:32:11 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.237.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 83501C6E; Tue, 15 May 2018 12:31:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: Date: Tue, 15 May 2018 12:32:07 -0400 Cc: Paul Hoffman , driu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C69A573-5EAF-4D46-BBCF-D825B729E475@bangj.com> References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> To: Erik Kline X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Driu] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 16:32:13 -0000 > On May 15, 2018, at 12:46 AM, Erik Kline wrote: >=20 > I'm not sure I understand the benefit of trying to provide this extra > information. I think clients will need to probe nameservers for their > capabilities. If by =E2=80=98probe=E2=80=99 you mean try something and if it works, = use it, then I agree this is going to happen and will change dynamically = as trust relationships develop. But as the delays of probing accumulate, it makes sense to provide a = mechanism to advertise a more advanced service offering directly. DHCP = is one way to do this. SRV/TLSA records are another. Manual = configuration is a third way. This won=E2=80=99t apply in all = environments. >=20 > Do we think TLS-only nameservers are a likely operational model? Under some environments, yes. There will be circumstances where if a client can=E2=80=99t connect to a = well known and pre-trusted DNS server, it will drop its lease and = disconnect from the network because it sees this as a form of attack. There will be other environments where the only DNS available is = provided by the enterprise network and the clients are happy about this = (clients and servers have the same owners). Tom From nobody Tue May 15 10:33:44 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3F412D944 for ; Tue, 15 May 2018 10:33:39 -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] 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 7lkYkb0zW0lZ for ; Tue, 15 May 2018 10:33:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 77F54126C25 for ; Tue, 15 May 2018 10:33:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fIdpG-0000FGC; Tue, 15 May 2018 19:33:26 +0200 Message-Id: To: driu@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> In-reply-to: Your message of "Tue, 15 May 2018 18:07:04 +0200 ." Date: Tue, 15 May 2018 19:33:26 +0200 Archived-At: Subject: Re: [Driu] [Ext] How to describe various flavors of DNS resolvers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 17:33:39 -0000 >IMHuO, preventing downgrade attacks will not work because there are likely going >to be environments that will block DNS-over-TLS and common DOH servers (China >comes to mind). Browsers will have to keep working for these people. Does that mean that browsers are also going to downgrade https to http if https is blocked? When I made a mistake with a Strict-Transport-Security header, there was really no way I could convince firefox to let me do http. In any case, I would prefer my browser to complain about downgrade attacks and possibly offer an option to allow it. Not just silently switch to an insecure protocol. Related to this issue: a lot of people configure resolvers like 8.8.8.8 manually. It would be nice if we can avoid input fields for TLS, HTTPS, port, sni, certificate, etc. Way better if that kind of stuff is auto discovered. From nobody Tue May 22 08:06:03 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB4B12EB73 for ; Tue, 22 May 2018 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u62-4c121FrR for ; Tue, 22 May 2018 08:05:55 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE2912EB97 for ; Tue, 22 May 2018 08:05:54 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 24986 invoked from network); 22 May 2018 17:05:52 +0200 Received: from acnx253.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.177.253]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 May 2018 17:05:52 +0200 To: driu@ietf.org From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <6d6b7a24-a53d-5910-2817-f841258bf8df@o2.pl> Date: Tue, 22 May 2018 17:04:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wHuqOdg45sisKKrvVfZKYsq4ArIFBi1zE" X-WP-MailID: e32617b5d9384b75cf0c07a5a61831c6 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [MePE] Archived-At: Subject: [Driu] Suggestion: DHCP to choose a DNS provider from a list of trusted servers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 15:06:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wHuqOdg45sisKKrvVfZKYsq4ArIFBi1zE Content-Type: multipart/mixed; boundary="ahVSAYAuhdFVMv9IOQhU4TkCXI6484iFq"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: driu@ietf.org Message-ID: <6d6b7a24-a53d-5910-2817-f841258bf8df@o2.pl> Subject: Suggestion: DHCP to choose a DNS provider from a list of trusted servers --ahVSAYAuhdFVMv9IOQhU4TkCXI6484iFq Content-Type: multipart/mixed; boundary="------------CD0F0A3975D5A4667886C0D8" Content-Language: pl This is a multi-part message in MIME format. --------------CD0F0A3975D5A4667886C0D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I have devised the following mechanism: A DNS API client would have a list of "trustworthy" DNS API servers, but = which DNS API server from that list is used could be selected using DHCP. This would have the following advantages: 1. It would give network administrators an easy way to choose a DNS provi= der across a whole network (using DHCP) and configure it in one place instead= of on multiple machines. 2. It would also enable use of ISP's DNS API server (as a main server or = as a fallback), which would make it possible to share global DNS load across m= any ISP's DNS servers. At the same time, it would provide protection against phishing and rogue = actors. I have written some time ago why it is beneficial to enable fallback to I= SP's DNS API servers (modified): We may end up with the whole Internet using few DOH servers. There are pr= obably few providers that would host publicly-available DOH servers: Cloudflare (1.1.1.1), Google, OpenDNS, IBM (or the folks responsible for 9.9.9.9) an= d possibly Microsoft and Apple (for use with Windows / macOS) [3]. I doubt = that OpenDNS would be happy to have their DOH server configured in application= s as default, and Microsoft and Apple as well (in products other then theirs).= This would be very different from the current situation where most people= are using the DNS server of their own ISP. That change may be great because it increases security, but could create = several points of failure for the whole Internet [1]. It would be vulnerable to D= oS. It is important to have some local fallback - i.e. DOH or DNS servers hosted by ISPs. Greetings, Mateusz [1] This would be much worse then the current situation with DNS root ser= vers. --------------CD0F0A3975D5A4667886C0D8 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------CD0F0A3975D5A4667886C0D8-- --ahVSAYAuhdFVMv9IOQhU4TkCXI6484iFq-- --wHuqOdg45sisKKrvVfZKYsq4ArIFBi1zE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbBDHPAAoJEPvWWrhhCv7G7wkQAJJjcGwUS90O0lFcQpu+Pgkh 9++2F+hl2qQ4tx8M+CFLaWVe20y9N1q9ZwDMwCR6OllYPEJ57LlfVZsdxOIvZLzV rGX9kwNBeKz54nbA2Hlz2SpryC5N9QWIrM6fF6TtfhcSu00IEWBW1sS7QWnVOgFu 0Ei5F6odoZSKY6EpNuyVGjWQmIz8XMEZ14jcoQwbOtTxI8A3EvPWPigny9uBDz3f lKX4fmMnkE9Q2OiEMFDQw2cZ+va+paCMQGUTPq3FfhPb4Te3WS7AqN7XykXZUtn7 kI+zM37qOy1XAOJpvXB/IKceTA98xee/dWHzQzQ4sUTWDZnA3mskztoMbRC9Ne18 1RNyRp4qc3VA3XoWJ1fO/3+WeBW38mqeoz1ozvdhOPYi4qMOOqZ/2/pi6a1jjby9 CwEX8ICOSXxAVpRarAFif+Axh5Fw7pjyfjEZ/fhoH1qq7MTVh1Wxoh3egMtG2hgi nKrCqtAjML52afiOJWqxJMjabgDGhbY4y9U1NW23fYgY3RQ3fLsvMDVbsqRS61kB 495mSXdZY8V8G2VTTgJ+cJiGY141ooqhj3/WE6SPtjV4hW7mX61T9LzNER3PhwG4 eKqPq0lC3FdBq1ErWIRqb2/ZsqeBov0eShLlv8ZFW9GifpUVL2b6NFVuybYcqkMb p/kasbs8oUsbRubkCi2d =f1oF -----END PGP SIGNATURE----- --wHuqOdg45sisKKrvVfZKYsq4ArIFBi1zE-- From nobody Tue May 29 15:04:25 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6512D775 for ; Tue, 29 May 2018 15:03:09 -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 s0dZeiefX5HK for ; Tue, 29 May 2018 15:03:07 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359BC12EAC0 for ; Tue, 29 May 2018 15:03:02 -0700 (PDT) Received: from butte-480.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4C323120; Tue, 29 May 2018 18:01:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Tom Pusateri In-Reply-To: <6d6b7a24-a53d-5910-2817-f841258bf8df@o2.pl> Date: Tue, 29 May 2018 18:03:00 -0400 Cc: driu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8008958C-6B0B-4E6D-AC70-EC5422334BB2@bangj.com> References: <6d6b7a24-a53d-5910-2817-f841258bf8df@o2.pl> To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Driu] Suggestion: DHCP to choose a DNS provider from a list of trusted servers X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 22:03:09 -0000 > On May 22, 2018, at 11:04 AM, Mateusz Jo=C5=84czyk = wrote: >=20 > Hello, > I have devised the following mechanism: >=20 > A DNS API client would have a list of "trustworthy" DNS API servers, = but which > DNS API server from that list is used could be selected using DHCP. >=20 > This would have the following advantages: > 1. It would give network administrators an easy way to choose a DNS = provider > across a whole network (using DHCP) and configure it in one place = instead of on > multiple machines. >=20 > 2. It would also enable use of ISP's DNS API server (as a main server = or as a > fallback), which would make it possible to share global DNS load = across many > ISP's DNS servers. >=20 > At the same time, it would provide protection against phishing and = rogue actors. >=20 >=20 >=20 > I have written some time ago why it is beneficial to enable fallback = to ISP's > DNS API servers (modified): >=20 > We may end up with the whole Internet using few DOH servers. There are = probably > few providers that would host publicly-available DOH servers: = Cloudflare > (1.1.1.1), Google, OpenDNS, IBM (or the folks responsible for 9.9.9.9) = and > possibly Microsoft and Apple (for use with Windows / macOS) [3]. I = doubt that > OpenDNS would be happy to have their DOH server configured in = applications as > default, and Microsoft and Apple as well (in products other then = theirs). >=20 > This would be very different from the current situation where most = people are > using the DNS server of their own ISP. >=20 > That change may be great because it increases security, but could = create several > points of failure for the whole Internet [1]. It would be vulnerable = to DoS. It > is important to have some local fallback - i.e. > DOH or DNS servers hosted by ISPs. As evidenced by the recent Cloudflare BGP hijack, trusting an IP address = isn=E2=80=99t sufficient. You have to authenticate the server. Authentication via a Certificate = Authority is not sufficient either. Any CA can sign any certificate. = That leaves: 1. SPKI pinning 2. DANE/DNSSEC You can=E2=80=99t trust the DNS information you learn via any mechanism = (DHCP or hand configured) because it might not really be that server. = You have to authenticate it. This means that DHCP distribution is no more/less trustworthy than hand = configuring. It=E2=80=99s just another source of DNS info that has to be = verified. Tom