idnits 2.17.1 draft-farrell-tls-wkesni-01.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1755 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Experimental July 5, 2019 5 Expires: January 6, 2020 7 A well-known URI for publishing ESNIKeys 8 draft-farrell-tls-wkesni-01 10 Abstract 12 We propose use of a well-known URI at which web servers can publish 13 ESNIKeys as a way to help get those published in the DNS. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 6, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Example use of the well-known URI for ESNI . . . . . . . . . 3 52 4. The esni well-known URI . . . . . . . . . . . . . . . . . . . 3 53 5. The JSON structure for ESNIKeys . . . . . . . . . . . . . . . 4 54 6. Zone factory behaviour . . . . . . . . . . . . . . . . . . . 5 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 59 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 Encrypted Server Name Indication (ESNI) [I-D.ietf-tls-esni] for 65 TLS1.3 [RFC8446] defines a confidentiality mechanism for server names 66 in TLS. That requires publication of an ESNIKeys data structure in 67 the DNS. An ESNIKeys structure contains the public component of a 68 key pair that will typically be periodically (re-)generated by a web 69 server. Many web servers will have an API that can be used to 70 dynamically update ESNIKeys in the DNS. Some implementations/ 71 deployments however, will not, so web server implementers could 72 benefit from a mechanism to use in such cases. 74 We define such a mechanism here. Note that this is not intended for 75 universal deployment, but just for cases where the zone file (or 76 equivalent) that includes the ESNIKeys RR is on some machine, which 77 we here call a "zone factory," to which the web server doesn't have 78 write access. 80 We propose use of a well-known URI [RFC8615] on the web server that 81 allows the zone factory for that web server to poll for changes to 82 ESNIKeys RR values. For example, if a web server generates new 83 ESNIKeys hourly and publishes those at the well-known URI, its zone 84 factory server can poll that URI. When the zone factory sees new 85 values, it can check if those work, and if they do, then update the 86 zone file and re-publish the zone. 88 [[This idea could: a) wither on the vine, b) be published as it's own 89 RFC, or c) end up as a PR for [I-D.ietf-tls-esni]. There is no 90 absolute need for this to be in the RFC that defines ESNI, so (b) 91 seems feasible if there's enough interest, hence this draft. The 92 source for this is in https://github.com/sftcd/wkesni/ PRs are 93 welcome there too.]] 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. Example use of the well-known URI for ESNI 105 An example deployment could be as follows: 107 o Web server generates new ESNIKeys hourly at N past the hour via a 108 cronjob 109 o ESNIKeys are "current" for an hour, published with a TTL of 1800, 110 and remain usable for 3 hours from the time of generation 111 o Web server has a set of "hidden" sites - the DNS name for each 112 hidden web site is here represented as $HIDDEN, which will end up 113 as a realSNI value to be encrypted inside an ESNI extension 114 o Web server has a "cover" site ($COVER), where $COVER will 115 typically be the DNS name used in the ESNIKeys public_name field 116 for ESNIKeys version 0xff02 117 o The cronjob creates creates a JSON file for each hidden site at 118 https://$COVER/.well-known/esni/$HIDDEN.json 119 o Each JSON file contains an array with the ESNIKeys RR values for 120 that particular $HIDDEN as shown in Figure 1 - the values in 121 Figure 1 with ellipses are the RR values we want to eventually see 122 in the DNS 123 o On the zone factory, a cronjob runs at N+3 past the hour, it knows 124 all the names involved and checks to see if the content at those 125 well-known URIs has changed or not 126 o If the content has changed the cronjob attempts to use the 127 ESNIKeys, and for each $HIDDEN where that works, it updates the 128 zone file and re-publishes the zone containing only the new 129 ESNIKeys RR values 131 4. The esni well-known URI 133 When a web server ($COVER) wants to publish ESNIKeys information for 134 a hidden site ($HIDDEN) then it provides the JSON content defined in 135 Section 5 at: https://$COVER/.well-known/esni/$HIDDEN.json 137 The well-known URI defined here MUST be an https URL and therefore 138 the zone factory verifies the correct $COVER is being accessed. If 139 there is any failure in accessing the well-known URI, then the zone 140 factory MUST NOT modify the zone. 142 5. The JSON structure for ESNIKeys 144 [[Since the specifics of the JSON structure in Figure 1 are very 145 likely to change, this is mostly TBD. What is here for now, is what 146 the author has currently implemented simply because it worked ok and 147 was easy to do:-)]] 149 [ 150 { 151 "ESNIKeys.version": 0xff01, 152 "desired-ttl": 1800, 153 "ESNIKeys": "/wH5QHc...=" 154 }, 155 { 156 "ESNIKeys.version": 0xff02, 157 "desired-ttl": 1800, 158 "ESNIKeys": "FF02897...OA" 159 } 160 ] 162 Figure 1: Sample JSON 164 The JSON file at the well-known URI MUST contain an array with one or 165 more elements. Each element of the array MUST have these fields: 167 o ESNIKeys.version: contains a number with the value of the version 168 field of the ESNIKeys. This is needed (today) as different 169 versions are published in the DNS differently. (Draft-02 used a 170 TXT RR and is still all that is usable with some early test 171 deployments, draft-03 uses a new RRTYPE from the experimental 172 range.) 173 o desired-ttl: contains a number indicating the TTL that the web 174 server would like to see used for this RR. The zone factory MUST 175 NOT use a longer TTL. 176 o ESNIKeys: contains the RRVALUE value to be used, either as a 177 base64 encoded string (for ESNIKeys.version of 0xff01) or as an 178 ASCII-HEX string (for ESNIKeys.version of 0xff02). 180 The JSON file contains an array for a couple of reasons: 182 o While ESNI is still in draft form, it may be necessary to publish 183 different versions of the ESNIKeys structure. 184 o For some deployments, the same $HIDDEN could be accessible, using 185 ESNI, via different $COVER (or public_name) web servers. 186 o As ESNIKeys is (regrettably:-) an extensible structure, it may be 187 necessary to publish different ESNIKeys values to get best 188 interoperability. 190 6. Zone factory behaviour 192 The zone factory SHOULD check that the presented ESNIKeys values work 193 with the $HIDDEN server before publication. A "special" TLS client 194 may be needed for this check, that does not require the ESNIKeys 195 value to have already been published in the DNS. [[I guess that 196 could call for the zone factory to know of a "safe" URL on $HIDDEN to 197 use, or maybe it could use HTTP HEAD? Figuring that out is TBD.]] 199 The zone factory SHOULD publish all the ESNIKeys values that are 200 presented in the JSON file, and that pass the check above. 202 The zone factory SHOULD only publish ESNIKeys values that are in the 203 latest version of the JSON file. This leaves the control of "expiry" 204 with the web server, so long as the ESNIKeys presented actually work. 205 [[An alternative could be to have the new values just be appended to 206 the zone, but that'd require some form of "notAfter" value in the 207 JSON file which seems unnecessary and more complex.]] 209 From the point of view of the zone factory, the KeyShareEntry values 210 within each element of the JSON array are entirely independent. The 211 zone factory MUST NOT assume that there is any specific relationship 212 between the ESNIKeys values in one JSON structure, nor between the 213 set of JSON structures for the set of $HIDDEN sites that share a 214 $COVER. 216 The ESNI specification [I-D.ietf-tls-esni] defines how and where the 217 ESNIKeys RR for $HIDDEN needs to be published in the DNS. 219 A possibly interesting (unintended) consequence of this design is 220 that once a TLS client has first gotten ESNIKeys from the DNS for 221 $HIDDEN with the draft-03 ESNIKeys structure containing the 222 public_name field, the TLS client would know both $COVER and $HIDDEN 223 and so could later probe for this .well-known as an alternative to 224 doing so via DoT/DoH. Probably not something a web browser might do, 225 but could be fun for other applications maybe. 227 7. Security Considerations 229 This document defines another way to publish ESNIKeys. If the wrong 230 keys were read from here and published in the DNS, then clients using 231 ESNI would do the wrong thing, likely resulting in denial of service, 232 or worse, when TLS clients attempt to use ESNI with a hidden web 233 site. So: Don't do that:-) 235 8. Acknowledgements 237 Thanks to Niall O'Reilly for a quick review. 239 9. IANA Considerations 241 [[TBD: IANA registration of a .well-known. Also TBD - how to handle 242 I18N for $COVER and $HIDDEN within such a URL.]] 244 10. Normative References 246 [I-D.ietf-tls-esni] 247 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 248 "Encrypted Server Name Indication for TLS 1.3", draft- 249 ietf-tls-esni-03 (work in progress), March 2019. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 258 May 2017, . 260 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 261 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 262 . 264 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 265 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 266 . 268 Appendix A. Change Log 270 [[RFC editor: please remove this before publication.]] 272 From -00 to -01: 274 o Re-structured a bit after re-reading rfc8615 276 Author's Address 278 Stephen Farrell 279 Trinity College Dublin 280 Dublin 2 281 Ireland 283 Phone: +353-1-896-2354 284 EMail: stephen.farrell@cs.tcd.ie