idnits 2.17.1 draft-farrell-tls-wkesni-02.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 (30 November 2021) is 871 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-13 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-08 Summary: 0 errors (**), 0 flaws (~~), 3 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 30 November 2021 5 Expires: 3 June 2022 7 A well-known URI for publishing ECHConfigList values. 8 draft-farrell-tls-wkesni-02 10 Abstract 12 We propose use of a well-known URI at which web servers can publish 13 ECHConfigList values 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 3 June 2022. 32 Copyright Notice 34 Copyright (c) 2021 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 (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Revised BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Revised BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Example use of the well-known URI for ECH . . . . . . . . . . 3 51 4. The ech well-known URI . . . . . . . . . . . . . . . . . . . 4 52 5. The JSON structure for ECHConfigList values . . . . . . . . . 4 53 6. Zone factory behaviour . . . . . . . . . . . . . . . . . . . 5 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 58 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 Encrypted ClientHello (ECH) [I-D.ietf-tls-esni] for TLS1.3 [RFC8446] 64 defines a confidentiality mechanism for server names and other 65 ClientHello content in TLS. For many applications, that requires 66 publication of ECHConflgList data structures in the DNS. An 67 ECHConfigList structure contains a list of ECHConfig values. Each 68 ECHConfig value contains the public component of a key pair that will 69 typically be periodically (re-)generated by a web server. Many web 70 infrastructures will have an API that can be used to dynamically 71 update the DNS RR values containing ECHConfigList values. Some 72 deployments however, will not, so web deployments could benefit from 73 a mechanism to use in such cases. 75 We define such a mechanism here. Note that this is not intended for 76 universal deployment, but rather for cases where the web server 77 doesn't have write access to the relevant zone file (or equivalent). 78 That zone file will eventually include an HTTPS or SVCB RR 79 [I-D.ietf-dnsop-svcb-https] containing an ECHConfigList. 81 We use the term "zone factory" for the entity that does have write 82 access to the zone file. We assume the zone factory (ZF) can also 83 make HTTPS requests to the web server with the ECH keys. 85 We propose use of a well-known URI [RFC8615] on the web server that 86 allows ZF to poll for changes to ECHConfigList values. For example, 87 if a web server generates new ECHConfigList values hourly and 88 publishes those at the well-known URI, ZF can poll that URI. When ZF 89 sees new values, it can check if those work, and if they do, then 90 update the zone file and re-publish the zone. 92 [[This idea could: a) wither on the vine, b) be published as it's own 93 RFC, or c) end up as a PR for [I-D.ietf-tls-esni]. There is no 94 absolute need for this to be in the RFC that defines ECH, so (b) 95 seems feasible if there's enough interest, hence this draft. The 96 source for this is in https://github.com/sftcd/wkesni/ PRs are 97 welcome there too.]] 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. Example use of the well-known URI for ECH 109 An example deployment could be as follows: 111 * Web server generates new ECHConfigList values hourly at N past the 112 hour via a cronjob 113 * ECHConfigList values are "current" for an hour, published with a 114 TTL of 1800, and remain usable for 3 hours from the time of 115 generation 116 * Web server has a set of "backend" sites - the DNS name for each 117 such site is here represented as $BACKEND, which will end up as an 118 SNI value to be encrypted inside an ECH extension 119 * Web server has a "front-end" site ($FRONT), where $FRONT will 120 typically be the DNS name used in the ECHConfigList public_name 121 field for ECHConfig version 0xff0d 122 * A cronjob creates creates a JSON file for each backend site at 123 https://$FRONT/.well-known/ech/$BACKEND.json 124 * Each JSON file contains an array with the ECHConfigList values 125 values for that particular $BACKEND as shown in Figure 1 - the 126 values in Figure 1 with ellipses are the values we want to 127 eventually see in the DNS 128 * On the zone factory, a cronjob runs at N+3 past the hour, it knows 129 all the names involved and checks to see if the content at those 130 well-known URIs has changed or not 131 * If the content has changed the cronjob attempts to use the 132 ECHConfigList values, and for each $BACKEND where that works, it 133 updates the zone file and re-publishes the zone containing only 134 the new ECHConfigList values 136 4. The ech well-known URI 138 When a web server ($FRONT) wants to publish ECHConfigList information 139 for a backend site ($BACKEND) then it provides the JSON content 140 defined in Section 5 at: https://$FRONT/.well-known/ech/$BACKEND.json 142 The well-known URI defined here MUST be an https URL and therefore 143 the zone factory verifies the correct $FRONT is being accessed. If 144 there is any failure in accessing the well-known URI, then the zone 145 factory MUST NOT modify the zone. 147 5. The JSON structure for ECHConfigList values 149 [[Since the specifics of the JSON structure in Figure 1 are very 150 likely to change, this is mostly TBD. What is here for now, is what 151 the author has currently implemented simply because it worked ok and 152 was easy to do:-)]] 154 [[Might change this due to retry-configs and now that I've 155 implemented split-mode]] 157 [ 158 { 159 "desired-ttl": 1800, 160 "ports": [ 443, 8413 ], 161 "echconfiglist": "AD7+DQA65wAgAC..AA==" 162 }, 163 { 164 "desired-ttl": 1800, 165 "ports": [ 443, 8413 ], 166 "echconfiglist": "AD7+DQA65wAgAC..AA==" 167 } 168 ] 170 Figure 1: Sample JSON 172 The JSON file at the well-known URI MUST contain an array with one or 173 more elements. Each element of the array MUST have these fields: 175 * desired-ttl: contains a number indicating the TTL that the web 176 server would like to see used for this RR. The zone factory MUST 177 NOT use a longer TTL. 178 * ports: this has a list of the TCP ports on which the web server 179 with the relevant key pair will listen (needed to produce the 180 correct zone file). 181 * ECHConfigList: contains the value to be used as a base64 encoded 182 string. 184 The JSON file contains an array for a couple of reasons: 186 * As TLS authentication doesn't really distinguish ports, servers on 187 the same host could in any case cheat on one another, so we may as 188 well just read one JSON file per name. 189 * Different ports could map to different sets of ECHConfig values 190 * As ECHConfigList is (regrettably:-) an extensible structure, it 191 may be necessary to publish different ECHConfigList values to get 192 best interoperability. 194 6. Zone factory behaviour 196 The zone factory SHOULD check that the presented ECHConfigList values 197 work with the $BACKEND server before publication. A "special" TLS 198 client may be needed for this check, that does not require the 199 ECHConfigList value to have already been published in the DNS. [[I 200 guess that calls for the zone factory to know of a "safe" URL on 201 $BACKEND to try, or maybe it could use HTTP HEAD? Figuring that out 202 is TBD. The ZF could also try a GREASEd ECH and see if the retry- 203 configs it gets back is one of the ECHConfig values in the 204 ECHConfigList.]] 206 A careful zone factory could explode the ECHConfigList value 207 presented into "singleton" values with one public key in each and 208 test each for each port claimed. 210 The zone factory SHOULD publish all the ECHConfigList values that are 211 presented in the JSON file, and that pass the check above. 213 The zone factory SHOULD only publish ECHConfigList values that are in 214 the latest version of the JSON file. This leaves the control of 215 "expiry" with the web server, so long as the ECHConfigList values 216 presented actually work. [[An alternative could be to have the new 217 values just be appended to the zone, but that'd require some form of 218 "notAfter" value in the JSON file which seems unnecessary and more 219 complex.]] 221 The SCVB and HTTPS RR specification [I-D.ietf-dnsop-svcb-https] 222 defines how and where the ECHConfigList values for $BACKEND needs to 223 be published in the DNS. The zone factory is assumed to be in 224 control of how ECHConfigList values are included in such RRs. 226 A possibly interesting (unintended) consequence of this design is 227 that once a TLS client has first gotten an ECHConfigList from the DNS 228 for $BACKEND with the ECHConfigList structure containing the 229 public_name field, the TLS client would know both $FRONT and $BACKEND 230 and so could later probe for this .well-known as an alternative to 231 doing so via DoT/DoH. Probably not something a web browser might do, 232 but could be fun for other applications maybe. 234 [[The extent to which retry-configs could be used for a similar 235 purpose might be worth considering. But the JSON stuff here may 236 still be needed if implementations (such as mine:-) tend to only 237 return one ECHConfig in retry-configs.]] 239 7. Security Considerations 241 This document defines another way to publish ECHConfigList values. 242 If the wrong keys were read from here and published in the DNS, then 243 clients using ECH would do the wrong thing, likely resulting in 244 denial of service, or a privacy leak, or worse, when TLS clients 245 attempt to use ECH with a backend web site. So: Don't do that:-) 247 8. Acknowledgements 249 Thanks to Niall O'Reilly for a quick review of -00. 251 9. IANA Considerations 253 [[TBD: IANA registration of a .well-known. Also TBD - how to handle 254 I18N for $FRONT and $BACKEND within such a URL.]] 256 10. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 265 May 2017, . 267 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 268 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 269 . 271 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 272 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 273 . 275 [I-D.ietf-tls-esni] 276 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 277 Encrypted Client Hello", Work in Progress, Internet-Draft, 278 draft-ietf-tls-esni-13, 12 August 2021, 279 . 282 [I-D.ietf-dnsop-svcb-https] 283 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 284 and parameter specification via the DNS (DNS SVCB and 285 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 286 dnsop-svcb-https-08, 12 October 2021, 287 . 290 Appendix A. Change Log 292 [[RFC editor: please remove this before publication.]] 294 From -01 to -02: 296 * General changes from ESNI to ECH. 298 From -00 to -01: 300 * Re-structured a bit after re-reading rfc8615 302 Author's Address 304 Stephen Farrell 305 Trinity College Dublin 306 Dublin 307 2 308 Ireland 310 Phone: +353-1-896-2354 311 Email: stephen.farrell@cs.tcd.ie