idnits 2.17.1 draft-rintaro-eds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8484]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 1, 2021) is 1060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Kobayashi 3 Internet-Draft Hyogo Prefectural Ono High School 4 Expires: December 3, 2021 June 1, 2021 6 Effective DNS Service 7 draft-rintaro-eds-00 9 Abstract 11 In DNS Queries over HTTPS [RFC8484], the port that communicates with 12 DNS would change from UDP to TCP 443. This change causes a new 13 problem that makes it difficult to identify which is the name 14 resolution request, so it is difficult to use web filtering, parental 15 controls and so on. Furthermore, a user-agent in a HTTP header that 16 is necessary for HTTPS communications could be a data used to track 17 users. In summary, DNS Queries over HTTPS has some problems that 18 affect users' security and privacy. This draft proposes a system 19 that is set mediation servers between client side and DNS servers. 20 With this proposal, it is expected that those two problems will be 21 solved. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 3, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. The structure of Effective DNS Service . . . . . . . . . 3 61 2.2. Web filtering . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Additional Considerations . . . . . . . . . . . . . . . . . . 4 63 3.1. Safety EDS and Third-party EDS . . . . . . . . . . . . . 4 64 3.2. EDS Certification system . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 6.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 In Effective DNS Service, there is a new server that mediates between 75 client side and DNS servers. Between client side and mediation 76 servers (hereinafter called EDS server) is HTTPS encryption. The 77 FQDN posted from client side is analyzed in an EDS server. After 78 analyzing in the EDS server, when the FQDN posted from client side is 79 matched with the FQDN that is blacklisted, EDS server does not send a 80 DNS request, and is returned to client side with a 403 Error and 81 error messages. If the FQDN is not blacklisted, EDS server starts to 82 communicate with the EDS server by using DNS over HTTPS. In 83 consequence, we can set web filtering by using EDS. Moreover, it is 84 impossible to track user by user-agent because all EDS servers use 85 the same user-agent. 87 1.1. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 Many of the specialized terms used in this specification are defined 94 in DNS Terminology [RFC7719]. 96 2. Proposed Solution 98 2.1. The structure of Effective DNS Service 100 DNS servers 101 | | 102 ,''''''''''''''''''''''|'|'''''''''''''''''''''''`. 103 | Effective DNS Service server (EDS server) | 104 | .......................... | 105 | :Web Filtering (Optional): | 106 | : +----------+ : | 107 | : | Black | : | 108 | : | List | : | 109 | : +----------+ : | 110 | :...........|.|..........: | 111 | | | | 112 `'''''''''''''''''''''|'|''''''''''''''''''''''''' 113 Client side 115 We can realize fast Internet connections because the number of 116 servers is not limited. I accessed the local DNS server and measured 117 the response time by using w/- - write-out. The total response time 118 was 0.2 sec. However, the total response time of the Heroku server 119 in the United States was 1.2 sec. Therefore, the response time is 120 dependant on the location of the EDS server, so EDS servers need to 121 be dispersed widely across the world. 123 2.2. Web filtering 125 I tested the web-filtering feature in EDS. First, I created an array 126 that has FQDN needs to block. This array is as a blacklist. Second, 127 when the FQDN is posted from client side, check whether the FQDN is 128 blacklisted or not. Then, make a judgement on starting communication 129 with DNS server or returning a 403 Error. 131 //Node.js v14 132 //[example: web filtering black list] 133 const blacklist = ["www.example.com", "www.rintaro.tech"] 134 if (blacklist.includes(FQDN) == false) { 135 res.send(kakunouko); 136 console.log(kakunouko); 137 }else{ 138 res.status(403); 139 res.send({code: 403, error: "EDS sever blocked DNS request because 140 the FQDN was blacklisted."}) 141 console.log(403) 143 3. Additional Considerations 145 3.1. Safety EDS and Third-party EDS 147 EDS server should be a distributed system and EDS servers should be 148 set in many countries. These EDS servers are managed by a 149 professional organization directly, and being officially certified by 150 this organization as "Safety EDS". The closest EDS server is set as 151 the default EDS server on browsers, and Safety EDS servers are 152 secured by the organization. By protecting some EDS servers with an 153 official organization, we can assure users' security. To stand up to 154 the crush of demand, all EDS servers are based on AnyCast. In 155 addition to Safety EDS, users can create independent EDS servers as 156 "Third-party EDS". Every EDS server must have "EDS certificate" for 157 a safe connection. 159 3.2. EDS Certification system 161 There are two institutions: PA and CA that manage EDS certification. 162 An owner applies for certification to PA, and PA also applies it to 163 CA. CA will issue the certification, and they store it in a 164 repository. The users check the server's certification, and verify 165 the validity by using the repository. By these structures that is 166 similar to SSL certification, we can run this system much more 167 safely. 169 4. IANA Considerations 171 This document has no IANA actions. 173 5. Security Considerations 175 Effective DNS Service also uses HTTPS. This mitigates classic 176 amplification attacks for UDP-based DNS. [RFC8484] 178 About Third-party EDS, the security of connection will be depend on 179 owners' skills. If these servers are for an unspecified large number 180 of people, the feature that users can report the server to a 181 certification organization will be needed. 183 6. References 185 6.1. Normative References 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, 189 DOI 10.17487/RFC2119, March 1997, 190 . 192 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 193 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 194 2015, . 196 6.2. Informative References 198 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 199 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 200 . 202 Author's Address 204 Rintaro Kobayashi 205 Hyogo Prefectural Ono High School 206 518 Nishihommachi-cho 207 Ono city, Hyogo 6751375 208 Japan 210 Email: k.rintaro1@icloud.com 211 URI: https://www.rintaro.tech