RFC 7808
Time Zone Data Distribution Service
Pages: 56
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 42 to 56
8. Security Considerations
Time zone data is critical in determining local or UTC time for devices and in calendaring and scheduling operations. As such, it is vital that a reliable source of time zone data is used. Servers providing a time zone data distribution service MUST support HTTP over Transport Layer Security (TLS) (as defined by [RFC2818] and [RFC5246], with best practices described in [RFC7525]). Servers MAY support a time zone data distribution service over HTTP without TLS. However, secondary servers MUST use TLS to fetch data from a primary server. Clients SHOULD use Transport Layer Security as defined by [RFC2818], unless they are specifically configured otherwise. Clients that have been configured to use the TLS-based service MUST NOT fall back to using the non-TLS service if the TLS-based service is not available. In addition, clients MUST NOT follow HTTP redirect requests from a TLS service to a non-TLS service. When using TLS, clients MUST verify the identity of the server, using a standard, secure mechanism such as the certificate verification process specified in [RFC6125] or DANE [RFC6698]. A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause clients to connect to any server chosen by the attacker. In the absence of a secure DNS option, clients SHOULD check that the target FQDN returned in the SRV record is the same as the original service domain that was queried, or is a sub-domain of the original service domain. In many cases, the client configuration is likely to be handled automatically without any user input; as such, any mismatch between the original service domain and the target FQDN is treated as a failure and the client MUST NOT attempt to connect to the target server. In addition, when Transport Layer Security is being used, the Transport Layer Security certificate SHOULD include an SRV-ID field as per [RFC4985] matching the expected DNS SRV queries clients will use for service discovery. If an SRV-ID field is present in a certificate, clients MUST match the SRV-ID value with the service type and domain that matches the DNS SRV request made by the client to discover the service. Time zone data servers SHOULD protect themselves against poorly implemented or malicious clients by throttling high request rates or frequent requests for large amounts of data. Clients can avoid being throttled by using the polling capabilities outlined in Section 4.1.4. Servers MAY require some form of authentication or authorization of clients (including secondary servers), as per [RFC7235], to restrict which clients are allowed to access their service or provide better identification of problematic clients.
9. Privacy Considerations
The type and pattern of requests that a client makes can be used to "fingerprint" specific clients or devices and thus potentially used to track information about what the users of the clients might be doing. In particular, a client that only downloads time zone data on an as-needed basis, will leak the fact that a user's device has moved from one time zone to another or that the user is receiving scheduling messages from another user in a different time zone. Clients need to be aware of the potential ways in which an untrusted server or a network observer might be able to track them and take precautions such as the following: 1. Always use TLS to connect to the server. 2. Avoid use of TLS session resumption. 3. Always fetch and synchronize the entire set of time zone data to avoid leaking information about which time zones are actually in use by the client. 4. Randomize the order in which individual time zones are fetched using the "get" action, when retrieving a set of time zones based on a "list" action response. 5. Avoid use of conditional HTTP requests [RFC7232] with the "get" action to prevent tracking of clients by servers generating client-specific ETag header field values. 6. Avoid use of cookies in HTTP requests [RFC6265]. 7. Avoid use of authenticated HTTP requests. 8. When doing periodic polling to check for updates, apply a random (positive or negative) offset to the next poll time to avoid servers being able to identify the client by the specific periodicity of its polling behavior. 9. A server trying to "fingerprint" clients might insert a "fake" time zone into the time zone data, using a unique identifier for each client making a request. The server can then watch for client requests that refer to that "fake" time zone and thus track the activity of each client. It is hard for clients to identify a "fake" time zone given that new time zones are added occasionally. One option to mitigate this would be for the client to make use of two time zone data distribution servers from two independent providers that provide time zone data from
the same publisher. The client can then compare the list of time
zones from each server (assuming they both have the same version
of time zone data from the common publisher) and detect ones that
appear to be added on one server and not the other.
Alternatively, the client can check the publisher data directly
to verify that time zones match the set the publisher has.
Note that some of the above recommendations will result in less
efficient use of the protocol due to fetching data that might not be
relevant to the client.
An organization can set up a secondary server within their own domain
and configure their clients to use that server to protect the
organization's users from the possibility of being tracked by an
untrusted time zone data distribution server. Clients can then use
more-efficient protocol interactions, free from the concerns above,
on the basis that their organization's server is trusted. When doing
this, the secondary server would follow the recommendations for
clients (listed in the previous paragraph) so that the untrusted
server is not able to gain information about the organization as a
whole. Note, however, that client requests to the secondary server
are subject to tracking by a network observer, so clients ought to
apply some of the randomization techniques from the list above.
Servers that want to avoid accidentally storing information that
could be used to identify clients can take the following precautions:
1. Avoid logging client request activity, or anonymize information
in any logs (e.g., client IP address, client user-agent details,
authentication credentials, etc.).
2. Add an unused HTTP response header to each response with a random
amount of data in it (e.g., to pad the overall request size to
the nearest power-of-2 or 128-byte boundary) to avoid exposing
which time zones are being fetched when TLS is being used, via
network traffic analysis.
10. IANA Considerations
This specification defines a new registry of "actions" for the time
zone data distribution service protocol, defines a "well-known" URI
using the registration procedure and template from Section 5.1 of
[RFC5785], creates two new SRV service label aliases, and defines one
new iCalendar property parameter as per the registration procedure in
[RFC5545]. It also adds a new "TZDIST Identifiers Registry" to the
IETF parameters URN sub-namespace as per [RFC3553] for use with
protocol related error codes.
10.1. Service Actions Registration
IANA has created a new top-level category called "Time Zone Data Distribution Service (TZDIST) Parameters" and has put all the registries created herein into that category. IANA has created a new registry called "TZDIST Service Actions", as defined below.10.1.1. Service Actions Registration Procedure
This registry uses the "Specification Required" policy defined in [RFC5226], which makes use of a designated expert to review potential registrations. The IETF has created a mailing list, tzdist-service@ietf.org, which is used for public discussion of time zone data distribution service actions proposals prior to registration. The IESG has appointed a designated expert who will monitor the tzdist-service@ietf.org mailing list and review registrations. A Standards Track RFC is REQUIRED for changes to actions previously documented in a Standards Track RFC; otherwise, any public specification that satisfies the requirements of [RFC5226] is acceptable. The registration procedure begins when a completed registration template, as defined below, is sent to tzdist-service@ietf.org and iana@iana.org. The designated expert is expected to tell IANA and the submitter of the registration whether the registration is approved, approved with minor changes, or rejected with cause, within two weeks. When a registration is rejected with cause, it can be resubmitted if the concerns listed in the cause are addressed. Decisions made by the designated expert can be appealed as per Section 7 of [RFC5226]. The designated expert MUST take the following requirements into account when reviewing the registration: 1. A valid registration template MUST be provided by the submitter, with a clear description of what the action does. 2. A proposed new action name MUST NOT conflict with any existing registered action name. A conflict includes a name that duplicates an existing one or that appears to be very similar to an existing one and could be a potential source of confusion.
3. A proposed new action MUST NOT exactly duplicate the
functionality of any existing actions. In cases where the new
action functionality is very close to an existing action, the
designated expert SHOULD clarify whether the submitter is aware
of the existing action, and has an adequate reason for creating a
new action with slight differences from an existing one.
4. If a proposed action is an extension to an existing action, the
changes MUST NOT conflict with the intent of the existing action,
or in a way that could cause interoperability problems for
existing deployments of the protocol.
The IANA registry contains the name of the action ("Action Name") and
a reference to the section of the specification where the action
registration template is defined ("Reference").
10.1.2. Registration Template for Actions
An action is defined by completing the following template.
Name: The name of the action.
Request-URI Template: The URI template used in HTTP requests for the
action.
Description: A general description of the action, its purpose, etc.
Parameters: A list of allowed request URI query parameters,
indicating whether they are "REQUIRED" or "OPTIONAL" and whether
they can occur only once or multiple times, together with the
expected format of the parameter values.
Response: The nature of the response to the HTTP request, e.g., what
format the response data is in.
Possible Error Codes: Possible error codes reported in a JSON
"problem details" object if an HTTP request fails.
10.1.3. Actions Registry
The following table provides the initial content of the actions registry. +---------------+------------------------+ | Action Name | Reference | +---------------+------------------------+ | capabilities | RFC 7808, Section 5.1 | | list | RFC 7808, Section 5.2 | | get | RFC 7808, Section 5.3 | | expand | RFC 7808, Section 5.4 | | find | RFC 7808, Section 5.5 | | leapseconds | RFC 7808, Section 5.6 | +---------------+------------------------+10.2. timezone Well-Known URI Registration
IANA has added the following to the "Well-Known URIs" [RFC5785] registry: URI suffix: timezone Change controller: IESG. Specification document(s): RFC 7808 Related information: None.10.3. Service Name Registrations
IANA has added two new service names to the "Service Name and Transport Protocol Port Number Registry" [RFC6335], as defined below.10.3.1. timezone Service Name Registration
Service Name: timezone Transport Protocol(s): TCP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: Time Zone Data Distribution Service - non-TLS Reference: RFC 7808
Assignment Note: This is an extension of the http service. Defined
TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
10.3.2. timezones Service Name Registration
Service Name: timezones
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Time Zone Data Distribution Service - over TLS
Reference: RFC 7808
Assignment Note: This is an extension of the https service. Defined
TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
10.4. TZDIST Identifiers Registry
IANA has registered a new URN sub-namespace within the IETF URN Sub-
namespace for Registered Protocol Parameter Identifiers defined in
[RFC3553].
Registrations in this registry follow the "IETF Review" [RFC5226]
policy.
Registry name: TZDIST Identifiers
URN prefix: urn:ietf:params:tzdist
Specification: RFC 7808
Repository: http://www.iana.org/assignments/tzdist-identifiers
Index value: Values in this registry are URNs or URN prefixes that
start with the prefix "urn:ietf:params:tzdist:". Each is
registered independently. The prefix
"urn:ietf:params:tzdist:error:" is used to represent specific
error codes within the protocol as defined in the list of actions
in Section 5 and used in problem reports (Section 4.1.7).
Each registration in the "TZDIST Identifiers" registry requires the
following information:
URN: The complete URN that is used or the prefix for that URN.
Description: A summary description for the URN or URN prefix.
Specification: A reference to a specification describing the URN or
URN prefix.
Contact: Email for the person or groups making the registration.
Index Value: As described in [RFC3553], URN prefixes that are
registered include a description of how the URN is constructed.
This is not applicable for specific URNs.
The "TZDIST Identifiers" registry has the initial registrations
included in the following sections.
10.4.1. Registration of invalid-action Error URN
The following URN has been registered in the "tzdist Identifiers"
registry.
URN: urn:ietf:params:tzdist:error:invalid-action
Description: Generic error code for any invalid action.
Specification: RFC 7808, Section 5
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
10.4.2. Registration of invalid-changedsince Error URN
The following URN has been registered in the "tzdist Identifiers"
registry.
URN: urn:ietf:params:tzdist:error:invalid-changedsince
Description: Error code for incorrect use of the "changedsince" URI
query parameter.
Specification: RFC 7808, Section 5.2
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Index value: N/A.
10.4.3. Registration of tzid-not-found Error URN
The following URN has been registered in the "tzdist Identifiers" registry. URN: urn:ietf:params:tzdist:error:tzid-not-found Description: Error code for missing time zone identifier. Specification: RFC 7808, Sections 5.3 and 5.4 Repository: http://www.iana.org/assignments/tzdist-identifiers Contact: IESG <iesg@ietf.org> Index value: N/A.10.4.4. Registration of invalid-format Error URN
The following URN has been registered in the "tzdist Identifiers" registry. URN: urn:ietf:params:tzdist:error:invalid-format Description: Error code for unsupported HTTP Accept request header field value. Specification: RFC 7808, Section 5.3 Repository: http://www.iana.org/assignments/tzdist-identifiers Contact: IESG <iesg@ietf.org> Index value: N/A.10.4.5. Registration of invalid-start Error URN
The following URN has been registered in the "tzdist Identifiers" registry. URN: urn:ietf:params:tzdist:error:invalid-start Description: Error code for incorrect use of the "start" URI query parameter. Specification: RFC 7808, Sections 5.3 and 5.4 Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org> Index value: N/A.10.4.6. Registration of invalid-end Error URN
The following URN has been registered in the "tzdist Identifiers" registry. URN: urn:ietf:params:tzdist:error:invalid-end Description: Error code for incorrect use of the "end" URI query parameter. Specification: RFC 7808, Sections 5.3 and 5.4 Repository: http://www.iana.org/assignments/tzdist-identifiers Contact: IESG <iesg@ietf.org> Index value: N/A.10.4.7. Registration of invalid-pattern Error URN
The following URN has been registered in the "tzdist Identifiers" registry. URN: urn:ietf:params:tzdist:error:invalid-pattern Description: Error code for incorrect use of the "pattern" URI query parameter. Specification: RFC 7808, Section 5.5 Repository: http://www.iana.org/assignments/tzdist-identifiers Contact: IESG <iesg@ietf.org> Index value: N/A.
10.5. iCalendar Property Registrations
This document defines the following new iCalendar properties, which have been added to the "Properties" registry under "iCalendar Element Registries" [RFC5545]: +----------------+----------+------------------------+ | Property | Status | Reference | +----------------+----------+------------------------+ | TZUNTIL | Current | RFC 7808, Section 7.1 | | TZID-ALIAS-OF | Current | RFC 7808, Section 7.2 | +----------------+----------+------------------------+11. References
11.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, <http://www.rfc-editor.org/info/rfc4985>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, <http://www.rfc-editor.org/info/rfc5545>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>. [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321, August 2011, <http://www.rfc-editor.org/info/rfc6321>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>. [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <http://www.rfc-editor.org/info/rfc6557>. [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>. [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>. [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>. [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2014, <http://www.rfc-editor.org/info/rfc7265>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>. [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <http://www.rfc-editor.org/info/rfc7807>.11.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.Acknowledgements
The authors would like to thank the members of the Calendaring and Scheduling Consortium's Time Zone Technical Committee, and the participants and chairs of the IETF tzdist working group. In particular, the following individuals have made important contributions to this work: Steve Allen, Lester Caine, Stephen Colebourne, Tobias Conradi, Steve Crocker, Paul Eggert, Daniel Kahn Gillmor, John Haug, Ciny Joy, Bryan Keller, Barry Leiba, Andrew McMillan, Ken Murchison, Tim Parenti, Arnaud Quillaud, Jose Edvaldo Saraiva, and Dave Thewlis. This specification originated from work at the Calendaring and Scheduling Consortium, which has supported the development and testing of implementations of the specification.
Authors' Addresses
Michael Douglass Spherical Cow Group 226 3rd Street Troy, NY 12180 United States Email: mdouglass@sphericalcowgroup.com URI: http://sphericalcowgroup.com Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States Email: cyrus@daboo.name URI: http://www.apple.com/