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.
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, email@example.com, 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 firstname.lastname@example.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 email@example.com and firstname.lastname@example.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 <email@example.com> Contact: IETF Chair <firstname.lastname@example.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 <email@example.com> Contact: IETF Chair <firstname.lastname@example.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 <email@example.com> 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 <firstname.lastname@example.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 <email@example.com> 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 <firstname.lastname@example.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 <email@example.com> 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 <firstname.lastname@example.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 <email@example.com> 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>.
[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.