idnits 2.17.1 draft-mathewson-no-gmtunixtime-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '... MUST by default set the entire valu...' RFC 2119 keyword, line 169: '...me, we recommend that implementors MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 05, 2013) is 3788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2246' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 191, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC5906' is defined on line 206, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group N. Mathewson 3 Internet-Draft Tor 4 Intended status: Standards Track B. Laurie 5 Expires: June 08, 2014 Google 6 December 05, 2013 8 Deprecating gmt_unix_time in TLS 9 draft-mathewson-no-gmtunixtime-00 11 Abstract 13 This memo deprecates the use of the gmt_unix_time field for sending 14 the current time in all versions of the TLS protocol's handshake. A 15 rationale is provided for this decision, and alternatives are 16 discussed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 08, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. The current behavior of gmt_unix_time . . . . . . . . . . 2 54 1.2. gmt_unix_time is an undesirable client fingerprint . . . 2 55 1.3. gmt_unix_time is undesirable on servers as well . . . . . 3 56 1.4. gmt_unix_time is neither adequate nor necessary for its 57 intended purpose . . . . . . . . . . . . . . . . . . . . 3 58 2. Deprecating gmt_unix_time . . . . . . . . . . . . . . . . . . 4 59 3. Security considerations . . . . . . . . . . . . . . . . . . . 4 60 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 4.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 Current versions of the TLS protocol, dating back to the SSL 3.0, 68 describe a gmt_unix_time field, sent in the clear, as part of the TLS 69 handshake. While the exact format of this field is not strictly 70 specified, typical implementations fill it with the time since the 71 Unix epoch (Jan 1, 1970) in seconds. This practice is neither 72 necessary nor safe. 74 1.1. The current behavior of gmt_unix_time 76 According to RFC 2246 ("The TLS Protocol Version 1.0"), gmt_unix_time 77 holds "The current time and date in standard UNIX 32-bit format 78 (seconds since the midnight starting Jan 1, 1970, GMT) according to 79 the sender's internal clock. Clocks are not required to be set 80 correctly by the basic TLS Protocol; higher level or application 81 protocols may define additional requirements." This text is retained 82 unchanged in RFC 4346 and in RFC 5246. 84 The gmt_unix_time field was first introduced in SSL 3.0, the 85 predecessor to TLS 1.0. The field was meant to preserve the 86 protocol's robustness in the presence of unreliable random number 87 generators that might generate the same random values more than once. 88 If this happened, then SSL would be vulnerable to various attacks 89 based on the non-uniqueness of the Random fields in the ClientHello 90 and ServerHello messages. Using the time value in this way was meant 91 to prevent the same Random value from being sent more than once, even 92 in the presence of misbehaved random number generators. 94 1.2. gmt_unix_time is an undesirable client fingerprint 96 Despite the late date, much of the world is still not synchronized to 97 the second via an ntp-like service. This means that different 98 clients have different views of the current time. By declaring their 99 view of the time in the gmt_unix_time field, clients provide 100 eavesdroppers a fingerprint that helps to track and distinguish them. 101 This fingerprint is useful for tracking mobile clients as they move 102 around from network to network. It can also distinguish clients who 103 would otherwise be anonymized by using a VPN, NAT, or privacy 104 network. 106 Even when clocks are synchronized to within a second, an eavesdropper 107 who can observe multiple gmt_unix_time values over time can build a 108 statistical profile of when within a single second a client 109 transitions from one second to another, and thereby distinguish such 110 clients. 112 Finally, an active packet-forging attacker who can forge NTP replies 113 to a targeted client can introduce anomalies in that client's view of 114 the current time. By (say) slowly advancing a client a fixed 115 interval into the future, the attacker can set a time-based plaintext 116 "cookie" that will persist on the user's TLS connections for so long 117 as the user's view of the current time remains skewed. (The system 118 of RFC 5906 prevents this attack by authenticating NTP replies, but 119 it is not universally used.) 121 1.3. gmt_unix_time is undesirable on servers as well 123 While some protocol designs retain a clear separation between 124 (nominally anonymous, possibly privacy-seeking) clients, and (well 125 known, easy to find) servers, there are several counterexamples in 126 which the responder to a TLS connection (the "Server" in the language 127 of the TLS specification) also wishes to avoid fingerprinting. These 128 include services provided through an anonymizing service, and 129 participation in some peer-to-peer network designs. 131 1.4. gmt_unix_time is neither adequate nor necessary for its intended 132 purpose 134 One might argue that the problems discussed above are real, but that 135 the benefit of the gmt_unix_time field outweighs them. But in fact, 136 the field provides no actual benefit. 138 The purpose of gmt_unix_time is to render repeated PRNG output values 139 survivable. But other portions of the TLS protocol -- for example, 140 the ephemeral key ciphersuites -- remove this alleged benefit. If an 141 implementation is prone to repeating the same ClientHello.Random 142 values when it starts up, it is also likely prone to repeating those 143 same values as Diffie-Hellman private keys, thereby rendering its 144 connections insecure. 146 Even if the ephemeral key ciphersuites are not in use, it's not 147 unusual in practice on a modern computer for multiple TLS clients or 148 servers to initiate handshakes around the same second. A one-second 149 time value is insufficient to ensure uniqueness. 151 Further, even if gmt_unix_time were adequate, it would not be 152 necessary. Given an even minimally cryptographically adequate PRNG, 153 and a non-repeating clock, implementors can ensure that the PRNG 154 generates non-repeated values by adding the current (high resolution) 155 time to the PRNG state when seeding it. This is not enough to ensure 156 that the PRNG is unpredictable by an attacker, but it does ensure 157 that the PRNG will not generate duplicate values even in the presence 158 of inadequate entropy sources. Most cryptographic libraries and 159 operating system PRNGs take this approach today. 161 2. Deprecating gmt_unix_time 163 For the reasons we discuss above, we recommend that TLS implementors 164 MUST by default set the entire value the ClientHello.Random and 165 ServerHello.Random fields, including gmt_unix_time, to a 166 cryptographically random sequence. 168 If existing users of a TLS implementation may rely on gmt_unix_time 169 containing the current time, we recommend that implementors MAY 170 provide the ability to set gmt_unix_time as an option only, off by 171 default. 173 Generating cryptographically strong pseudorandom sequences is beyond 174 the scope of this document. Nevertheless, we recommend that 175 implementors who may be concerned about the loss of the benefits of 176 the gmt_unix_time field should ensure that their cryptographic PRNG 177 input includes -- among the entropy that they hope will be strong -- 178 a high-resolution view of the current time. 180 3. Security considerations 182 The entire document is security-related. 184 4. References 186 4.1. Normative References 188 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 189 RFC 2246, January 1999. 191 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 192 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 194 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 195 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 197 4.2. Informative References 199 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 200 Requirements for Security", BCP 106, RFC 4086, June 2005. 202 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 203 Time Protocol Version 4: Protocol and Algorithms 204 Specification", RFC 5905, June 2010. 206 [RFC5906] Haberman, B. and D. Mills, "Network Time Protocol Version 207 4: Autokey Specification", RFC 5906, June 2010. 209 Authors' Addresses 211 Nick Mathewson 212 The Tor Project 214 Email: nickm@torproject.org 216 Ben Laurie 217 Google 219 Email: benl@google.com