< draft-farrell-tls-wkesni-00.txt   draft-farrell-tls-wkesni-01.txt >
TLS S. Farrell TLS S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Experimental July 3, 2019 Intended status: Experimental July 5, 2019
Expires: January 4, 2020 Expires: January 6, 2020
A well-known URI for publishing ESNIKeys A well-known URI for publishing ESNIKeys
draft-farrell-tls-wkesni-00 draft-farrell-tls-wkesni-01
Abstract Abstract
We propose use of a well-known URI at which web servers can publish We propose use of a well-known URI at which web servers can publish
ESNIKeys as a way to help get those published in the DNS. ESNIKeys as a way to help get those published in the DNS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2020. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Example Use of .well-known for ESNIKeys . . . . . . . . . . . 3 3. Example use of the well-known URI for ESNI . . . . . . . . . 3
4. The JSON structure for ESNIKeys . . . . . . . . . . . . . . . 4 4. The esni well-known URI . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. The JSON structure for ESNIKeys . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Zone factory behaviour . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Encrypted Server Name Indication (ESNI) [I-D.ietf-tls-esni] for Encrypted Server Name Indication (ESNI) [I-D.ietf-tls-esni] for
TLS1.3 [RFC8446] defines a confidentiality mechanism for server names TLS1.3 [RFC8446] defines a confidentiality mechanism for server names
in TLS. That requires publication of an ESNIKEys data structure in in TLS. That requires publication of an ESNIKeys data structure in
the DNS. the DNS. An ESNIKeys structure contains the public component of a
key pair that will typically be periodically (re-)generated by a web
server. Many web servers will have an API that can be used to
dynamically update ESNIKeys in the DNS. Some implementations/
deployments however, will not, so web server implementers could
benefit from a mechanism to use in such cases.
Many web servers will have an API that can be used to dynamically We define such a mechanism here. Note that this is not intended for
update ESNIKeys in the DNS. Some implementations/deployments universal deployment, but just for cases where the zone file (or
however, will not, so web server implementers could benefit from a equivalent) that includes the ESNIKeys RR is on some machine, which
mechanism to use in such cases. We define such a mechanism here. we here call a "zone factory," to which the web server doesn't have
Note that this is not intended for universal deployment, but just for write access.
cases where the zone file (or equivalent) that includes the ESNIKeys
RR is on some machine, which we here call a "zone factory," to which
the web server doesn't have write access.
We propose use of a well-known URI on the web server that allows the We propose use of a well-known URI [RFC8615] on the web server that
zone factory for that web server to poll for changes to ESNIKeys RR allows the zone factory for that web server to poll for changes to
values. For example, if a web server generates new ESNIKeys hourly ESNIKeys RR values. For example, if a web server generates new
and publishes those at the .well-known URI, its zone factory server ESNIKeys hourly and publishes those at the well-known URI, its zone
can poll that URI. When the zone factory sees new values, it can factory server can poll that URI. When the zone factory sees new
check if those work, and if they do, then update the zone file and values, it can check if those work, and if they do, then update the
re-publish the zone. zone file and re-publish the zone.
[[This idea could: a) wither on the vine, b) be published as it's own [[This idea could: a) wither on the vine, b) be published as it's own
RFC, or c) end up as a PR for [I-D.ietf-tls-esni]. There is no RFC, or c) end up as a PR for [I-D.ietf-tls-esni]. There is no
absolute need for this to be in the RFC that defines ESNI, so (b) absolute need for this to be in the RFC that defines ESNI, so (b)
seems feasible it there's enough interest, hence this draft. The seems feasible if there's enough interest, hence this draft. The
source for this is in https://github.com/sftcd/wkesni/ PRs are source for this is in https://github.com/sftcd/wkesni/ PRs are
welcome there too.]] welcome there too.]]
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Example Use of .well-known for ESNIKeys 3. Example use of the well-known URI for ESNI
An example deployment could be as follows: An example deployment could be as follows:
o Web server generates new ESNIKeys hourly at N past the hour via a o Web server generates new ESNIKeys hourly at N past the hour via a
cronjob cronjob
o ESNIKeys are "current" for an hour, and published with a TTL of o ESNIKeys are "current" for an hour, published with a TTL of 1800,
1800 and remain usable for 3 hours from the time of generation
o Old ESNIKeys are still usable for 3 hours from time of generation o Web server has a set of "hidden" sites - the DNS name for each
o Web server has a set of "hidden" sites (each represented as a hidden web site is here represented as $HIDDEN, which will end up
$HIDDEN value) and a "cover" site ($COVER) as a realSNI value to be encrypted inside an ESNI extension
o $COVER will typically be the value used in the ESNIKeys o Web server has a "cover" site ($COVER), where $COVER will
public_name field for ESNIKeys version 0xff02 typically be the DNS name used in the ESNIKeys public_name field
for ESNIKeys version 0xff02
o The cronjob creates creates a JSON file for each hidden site at o The cronjob creates creates a JSON file for each hidden site at
https://$COVER/.well-known/esni/$HIDDEN.json https://$COVER/.well-known/esni/$HIDDEN.json
o Each JSON file contains an array with the ESNIKeys RR values for o Each JSON file contains an array with the ESNIKeys RR values for
that particular $HIDDEN as shown in Figure 1 - the values in that particular $HIDDEN as shown in Figure 1 - the values in
Figure 1 with ellipses are the RR values we want to eventually see Figure 1 with ellipses are the RR values we want to eventually see
in the DNS in the DNS
o On the zone factory, a cronjob runs at N+3 past the hour, it knows o On the zone factory, a cronjob runs at N+3 past the hour, it knows
all the names involved and checks to see if the content at those all the names involved and checks to see if the content at those
well-known URIs has changed or not well-known URIs has changed or not
o If the content has changed the cronjob attempts to use the o If the content has changed the cronjob attempts to use the
ESNIKeys, and for each $HIDDEN where that works, it updates the ESNIKeys, and for each $HIDDEN where that works, it updates the
zone file and re-publishes the zone containing only the new zone file and re-publishes the zone containing only the new
ESNIKeys RR values ESNIKeys RR values
4. The esni well-known URI
When a web server ($COVER) wants to publish ESNIKeys information for
a hidden site ($HIDDEN) then it provides the JSON content defined in
Section 5 at: https://$COVER/.well-known/esni/$HIDDEN.json
The well-known URI defined here MUST be an https URL and therefore
the zone factory verifies the correct $COVER 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 ESNIKeys
[[Since the specifics of the JSON structure in Figure 1 are very
likely to change, this is mostly TBD. What is here for now, is what
the author has currently implemented simply because it worked ok and
was easy to do:-)]]
[ [
{ {
"ESNIKeys.version": 0xff01, "ESNIKeys.version": 0xff01,
"desired-ttl": 1800, "desired-ttl": 1800,
"ESNIKeys": "/wH5QHc...=" "ESNIKeys": "/wH5QHc...="
}, },
{ {
"ESNIKeys.version": 0xff02, "ESNIKeys.version": 0xff02,
"desired-ttl": 1800, "desired-ttl": 1800,
"ESNIKeys": "FF02897...OA" "ESNIKeys": "FF02897...OA"
} }
] ]
Figure 1: Sample JSON Figure 1: Sample JSON
4. The JSON structure for ESNIKeys
[[Since the specifics of the JSON structure in Figure 1 are very
likely to change, this is mostly TBD. What is here for now, is what
the author has currently implemented simply because it worked ok and
was easy to do:-)]]
The JSON file at the well-known URI MUST contain an array with one or The JSON file at the well-known URI MUST contain an array with one or
more elements. Each element of the array MUST have these fields: more elements. Each element of the array MUST have these fields:
o ESNIKeys.version: contains a number with the value of the version o ESNIKeys.version: contains a number with the value of the version
field of the ESNIKeys. This is needed (today) as different field of the ESNIKeys. This is needed (today) as different
versions are published in the DNS differently. (Draft-02 used a versions are published in the DNS differently. (Draft-02 used a
TXT RR and is still all that is usable with some early test TXT RR and is still all that is usable with some early test
deployments, draft-03 uses a new RRTYPE from the experimental deployments, draft-03 uses a new RRTYPE from the experimental
range.) range.)
o desired-ttl: contains a number indicating the TTL that the web o desired-ttl: contains a number indicating the TTL that the web
skipping to change at page 4, line 51 skipping to change at page 4, line 51
ASCII-HEX string (for ESNIKeys.version of 0xff02). ASCII-HEX string (for ESNIKeys.version of 0xff02).
The JSON file contains an array for a couple of reasons: The JSON file contains an array for a couple of reasons:
o While ESNI is still in draft form, it may be necessary to publish o While ESNI is still in draft form, it may be necessary to publish
different versions of the ESNIKeys structure. different versions of the ESNIKeys structure.
o For some deployments, the same $HIDDEN could be accessible, using o For some deployments, the same $HIDDEN could be accessible, using
ESNI, via different $COVER (or public_name) web servers. ESNI, via different $COVER (or public_name) web servers.
o As ESNIKeys is (regrettably:-) an extensible structure, it may be o As ESNIKeys is (regrettably:-) an extensible structure, it may be
necessary to publish different ESNIKeys values to get best necessary to publish different ESNIKeys values to get best
interopability. interoperability.
6. Zone factory behaviour
The zone factory SHOULD check that the presented ESNIKeys values work The zone factory SHOULD check that the presented ESNIKeys values work
with the $HIDDEN server before publication. A "special" TLS client with the $HIDDEN server before publication. A "special" TLS client
may be needed for this check, that does not require the ESNIKeys may be needed for this check, that does not require the ESNIKeys
value to have already been published in the DNS. [[I guess that value to have already been published in the DNS. [[I guess that
could call for the zone factory to know of a "safe" URL on $HIDDEN to could call for the zone factory to know of a "safe" URL on $HIDDEN to
use, or maybe it could use HTTP HEAD? Figuring that out is TBD.]] use, or maybe it could use HTTP HEAD? Figuring that out is TBD.]]
The zone factory SHOULD publish all the ESNIKeys values that are The zone factory SHOULD publish all the ESNIKeys values that are
presented in the JSON file, and that pass the check above.. presented in the JSON file, and that pass the check above.
The zone factory SHOULD only publish ESNIKeys values that are in the The zone factory SHOULD only publish ESNIKeys values that are in the
latest version of the JSON file. This leaves the control of "expiry" latest version of the JSON file. This leaves the control of "expiry"
with the web server, so long as the ESNIKeys presented actually work. with the web server, so long as the ESNIKeys presented actually work.
[[An alternative could be to have the new values just be appended to [[An alternative could be to have the new values just be appended to
the zone, but that'd require some form of "notAfter" value in the the zone, but that'd require some form of "notAfter" value in the
JSON file which seems unnecessary and more complex.]] JSON file which seems unnecessary and more complex.]]
From the point of view of the zone factory, the KeyShareEntry values
within each element of the JSON array are entirely independent. The
zone factory MUST NOT assume that there is any specific relationship
between the ESNIKeys values in one JSON structure, nor between the
set of JSON structures for the set of $HIDDEN sites that share a
$COVER.
The ESNI specification [I-D.ietf-tls-esni] defines how and where the The ESNI specification [I-D.ietf-tls-esni] defines how and where the
ESNIKeys RR for $HIDDEN needs to be published in the DNS. ESNIKeys RR for $HIDDEN needs to be published in the DNS.
A possibly interesting (unintended) consequence of this design is A possibly interesting (unintended) consequence of this design is
that once a TLS client has first gotten ESNIKeys from the DNS for that once a TLS client has first gotten ESNIKeys from the DNS for
$HIDDEN with the draft-03 ESNIKeys structure containing the $HIDDEN with the draft-03 ESNIKeys structure containing the
public_name field, the TLS client would know both $COVER and $HIDDEN public_name field, the TLS client would know both $COVER and $HIDDEN
and so could later probe for this .well-known as an alternative to and so could later probe for this .well-known as an alternative to
doing so via DoT/DoH. Probably not something a web browser might do, doing so via DoT/DoH. Probably not something a web browser might do,
but could be fun for other applications maybe. but could be fun for other applications maybe.
5. Security Considerations 7. Security Considerations
This document defines another way to publish ESNIKeys. If the wrong This document defines another way to publish ESNIKeys. If the wrong
keys were read from here and publised in the DNS, then clients using keys were read from here and published in the DNS, then clients using
ESNI would do the wrong thing. So: Don't do that:-) ESNI would do the wrong thing, likely resulting in denial of service,
or worse, when TLS clients attempt to use ESNI with a hidden web
site. So: Don't do that:-)
6. Acknowledgements 8. Acknowledgements
[[Your name here.]] Thanks to Niall O'Reilly for a quick review.
7. IANA Considerations 9. IANA Considerations
[[TBD: IANA registration of a .well-known]] [[TBD: IANA registration of a .well-known. Also TBD - how to handle
I18N for $COVER and $HIDDEN within such a URL.]]
8. Normative References 10. Normative References
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft- "Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-03 (work in progress), March 2019. ietf-tls-esni-03 (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <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>.
Appendix A. Change Log Appendix A. Change Log
[[RFC editor: please remove this before publication.]] [[RFC editor: please remove this before publication.]]
Nothing yet. From -00 to -01:
o Re-structured a bit after re-reading rfc8615
Author's Address Author's Address
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie EMail: stephen.farrell@cs.tcd.ie
 End of changes. 24 change blocks. 
54 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/