-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-ietf-tls-wkech-01.txt
448 lines (292 loc) · 16.6 KB
/
draft-ietf-tls-wkech-01.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
TLS S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Experimental R. Salz
Expires: April 26, 2023 Akamai Technologies
B. Schwartz
Google LLC
October 23, 2022
A well-known URI for publishing ECHConfigList values.
draft-ietf-tls-wkech-01
Abstract
We propose use of a well-known URI at which an HTTP origin can inform
an authoritative DNS server, or other interested parties, about this
origin's Service Bindings, i.e. its "HTTPS" DNS records. These
instructions can include Encrypted ClientHello (ECH) configurations,
allowing the origin to publish and rotate its own ECH keys.
AUTHORS NOTE: This version proposes changing from the highly
ECHConfig specific approach of -00 to a much more generic approach.
The authors are seeking feedback from the Working Group as to which
of these approaches may be more likely to garner rough consensus. If
the WG feel this is worse than -00 we're fine with reverting.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farrell, et al. Expires April 26, 2023 [Page 1]
Internet-Draft Well-Known URI for ECH October 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Example use of the well-known URI for ECH . . . . . . . . . . 3
4. The origin-svcb well-known URI . . . . . . . . . . . . . . . 4
5. The JSON structure for origin service binding info . . . . . 4
6. Zone factory behaviour . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Encrypted ClientHello (ECH) [I-D.ietf-tls-esni] for TLS1.3 [RFC8446]
defines a confidentiality mechanism for server names and other
ClientHello content in TLS. For many applications, that requires
publication of ECHConflgList data structures in the DNS. An
ECHConfigList structure contains a list of ECHConfig values. Each
ECHConfig value contains the public component of a key pair that will
typically be periodically (re-)generated by a web server. Many web
infrastructures will have an API that can be used to dynamically
update the DNS RR values containing ECHConfigList values. Some
deployments however, will not, so web deployments could benefit from
a mechanism to use in such cases.
We define such a mechanism here. Note that this is not intended for
universal deployment, but rather for cases where the web server
doesn't have write access to the relevant zone file (or equivalent).
That zone file will eventually include an HTTPS or SVCB RR
[I-D.ietf-dnsop-svcb-https] containing an ECHConfigList. This
mechanism is extensible to deliver other kinds of information about
the origin, but in this specification it only provides the
functionality necessary to configure ECH.
Farrell, et al. Expires April 26, 2023 [Page 2]
Internet-Draft Well-Known URI for ECH October 2022
We use the term "zone factory" for the entity that does have write
access to the zone file. We assume the zone factory (ZF) can also
make HTTPS requests to the web server with the ECH keys.
We propose use of a well-known URI [RFC8615] on the web server that
allows ZF to poll for changes to ECHConfigList values. For example,
if a web server generates new ECHConfigList values hourly and
publishes those at the well-known URI, ZF can poll that URI. When ZF
sees new values, it can check if those work, and if they do, then
update the zone file and re-publish the zone.
[[The source for this is in https://github.com/sftcd/wkesni/ PRs are
welcome there too.]]
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Example use of the well-known URI for ECH
An example deployment could be as follows:
1. Web server generates new ECHConfigList values hourly at N past
the hour via some regular, automated process (e.g. a cronjob)
2. ECHConfigList values are "current" for an hour, and remain usable
for 3 hours from the time of generation
3. The cronjob updates the ECHConfigList values in a JSON resource
at at https://$ORIGIN/.well-known/origin-svcb, as shown in
Figure 1.
4. On the zone factory, an HTTP client retrieves this JSON resource.
It attempts to connect to the origin using these values and
confirms that they are working.
5. The zone factory observes that the JSON resource has an HTTP
freshness lifetime of 3600 seconds, and chooses a DNS TTL of
1800. It updates the zone file for $ORIGIN and re-publishes the
zone containing only the new ECHConfigList values.
6. When the TTL of the DNS records approaches the remaining
freshness lifetime of the JSON resource, the zone factory
attempts to refresh its cached copy of the JSON resource. If the
resource has changed, it repeats this process.
Farrell, et al. Expires April 26, 2023 [Page 3]
Internet-Draft Well-Known URI for ECH October 2022
4. The origin-svcb well-known URI
If a web server ($ORIGIN) wants to convey information to the Zone
Factory, it publishes the JSON content defined in Section 5 at:
https://$ORIGIN/.well-known/origin-svcb
The well-known URI defined here MUST be an https URL and therefore
the zone factory verifies the correct $ORIGIN is being accessed. If
there is any failure in accessing the well-known URI, then the zone
factory MUST NOT modify the zone.
5. The JSON structure for origin service binding info
[[The JSON structure is a work in progress.]]
{
"endpoints": [{
"priority": 1,
"target": "cdn.example.",
"ech": "AD7+DQA65wAgAC..AA=="
}, {
"priority": 1,
"port": 8413,
"ech": "AD7+DQA65wAgAC..AA=="
}]
}
Figure 1: Sample JSON for ECH without aliases
{
"alias": "cdn.example.net:443"
}
Figure 2: Sample JSON with aliasing
The JSON file at the well-known URI MUST contain an object with
either an "endpoints" key or an "alias" key. If the "endpoints" key
is present, its value is an array whose elements represent HTTPS
records in ServiceMode. Each element MAY contain one or more keys
from the JSON HTTP Origin Info registry (see IANA Considerations).
The initial registry entries are:
o priority: The value is a positive integer corresponding to the
SvcPriority. If omitted, the zone factory SHOULD infer
numerically increasing SvcPriority from the order of the endpoints
array.
Farrell, et al. Expires April 26, 2023 [Page 4]
Internet-Draft Well-Known URI for ECH October 2022
o target: The value is a string containing a fully qualified domain
name, corresponding to the HTTPS record's TargetName. The default
value is ".".
o port: The value is a non-negative integer, corresponding to the
value of the "port" SvcParamKey.
o ech: The value is a string containing an ECHConfigList encoded in
Base64 [RFC4648], corresponding to the value of the "ech"
SvcParamKey.
An empty endpoint object corresponds to an HTTPS record with inferred
SvcPriority, TargetName=".", and no ECH support. An empty record of
this kind can be useful as a simple way to make use of the HTTPS RR
type's HSTS behavior.
[[TODO: What does the zone factory do if it encounters an
unrecognized field?]]
If the object contains an "alias" key, its value MUST be an
"authority" (Section 3.2 of [RFC3986]). This indicates that $ORIGIN
is hosted on the same endpoints as this target, and is equivalent to
an HTTPS AliasMode record. A zone factory might implement this
directive by publishing an AliasMode record, publishing a CNAME
record, copying HTTPS records from the target zone, or fetching
https://$TARGET/.well-known/origin-svcb" (if it exists).
This arrangement provides the following important properties:
o Origins can indicate that different ECHConfigs are used on
different ports.
o Origins can indicate that multiple CDNs are in use, each with its
own ECHConfig.
o Origins that simply alias to a single target can indicate this
without copying the ECHConfig and other parameters, which can
interfere with key rotation and other maintenance.
o "port" and "target" are generally sufficient to uniquely identify
a ServiceMode record, so zone factories can use the endpoint list
to add ECH to pre-existing ServiceMode records that may have other
SvcParams.
6. Zone factory behaviour
The zone factory SHOULD check that the presented endpoints work and
provide access to $ORIGIN before publication. A bespoke TLS client
may be needed for this check, that does not require the ECHConfigList
value to have already been published in the DNS. [[I guess that
calls for the zone factory to know of a "safe" URL on $ORIGIN to try,
or maybe it could use HTTP HEAD? Figuring that out is TBD. The ZF
Farrell, et al. Expires April 26, 2023 [Page 5]
Internet-Draft Well-Known URI for ECH October 2022
could also try a GREASEd ECH and see if the retry-configs it gets
back is one of the ECHConfig values in the ECHConfigList.]]
A careful zone factory could explode the ECHConfigList value
presented into "singleton" values with one public key in each and
test each for each endpoint.
The zone factory SHOULD publish all the endpoints that are presented
in the JSON file, and that pass the check above.
The zone factory MUST set a DNS TTL short enough that any generated
records expire from DNS caches before the JSON object's HTTP cache
lifetime expires. The zone factory MUST refresh the JSON object and
regenerate the zone before it expires each time. This ensures that
ECHConfigs are not used longer than intended by the origin, while
permitting the zone factory to limit the TTL if desired.
7. Security Considerations
This document defines another way to publish ECHConfigList values.
If the wrong keys were read from here and published in the DNS, then
clients using ECH would do the wrong thing, likely resulting in
denial of service, or a privacy leak, or worse, when TLS clients
attempt to use ECH with a backend web site. So: Don't do that:-)
Although this configuration resource MAY be publicly accessible,
general HTTP clients SHOULD NOT attempt to use this resource in lieu
of HTTPS records queries through their preferred DNS server:
o The bootstrap connection would not be able to use ECH, so it would
reveal all the information that ECH seeks to protect.
o The origin could serve the user with a uniquely identifying
configuration, potentially resulting in an unexpected tracking
vector.
8. Acknowledgements
Thanks to Niall O'Reilly for a quick review of -00.
9. IANA Considerations
[[TBD: IANA registration of a .well-known. Also TBD - how to handle
I18N for $FRONT and $BACKEND within such a URL.]]
If approved, this specification requests the creation of an IANA
registry named "JSON HTTP Origin Info" with a Standards Action
registration policy, containing a field named "Name" whose value is a
UTF-8 string.
Farrell, et al. Expires April 26, 2023 [Page 6]
Internet-Draft Well-Known URI for ECH October 2022
10. Normative References
[I-D.ietf-dnsop-svcb-https]
Schwartz, B., Bishop, M., and E. Nygren, "Service binding
and parameter specification via the DNS (DNS SVCB and
HTTPS RRs)", draft-ietf-dnsop-svcb-https-11 (work in
progress), October 2022, <https://www.ietf.org/archive/id/
draft-ietf-dnsop-svcb-https-11.txt>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-15 (work in
progress), October 2022, <https://www.ietf.org/archive/id/
draft-ietf-tls-esni-15.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
Farrell, et al. Expires April 26, 2023 [Page 7]
Internet-Draft Well-Known URI for ECH October 2022
Appendix A. Change Log
[[RFC editor: please remove this before publication.]]
The -00 WG draft replaces draft-farrell-tls-wkesni-03.
Version 01 changed from a special-purpose design, carrying only
ECHConfigs and port numbers, to a more general approach based on
Service Bindings.
Authors' Addresses
Stephen Farrell
Trinity College Dublin
Dublin 2
Ireland
Phone: +353-1-896-2354
EMail: [email protected]
Rich Salz
Akamai Technologies
EMail: [email protected]
Benjamin Schwartz
Google LLC
EMail: [email protected]
Farrell, et al. Expires April 26, 2023 [Page 8]