TLS Working Group                                           N. Mathewson
Internet-Draft                                                       Tor
Intended status: Standards Track                               B. Laurie
Expires: June 08, 2014                                            Google
                                                       December 05, 2013


                    Deprecating gmt_unix_time in TLS
                   draft-mathewson-no-gmtunixtime-00

Abstract

   This memo deprecates the use of the gmt_unix_time field for sending
   the current time in all versions of the TLS protocol's handshake.  A
   rationale is provided for this decision, and alternatives are
   discussed.

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 http://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 June 08, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.



Mathewson & Laurie        Expires June 08, 2014                 [Page 1]


Internet-Draft      Deprecating gmt_unix_time in TLS       December 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  The current behavior of gmt_unix_time . . . . . . . . . .   2
     1.2.  gmt_unix_time is an undesirable client fingerprint  . . .   2
     1.3.  gmt_unix_time is undesirable on servers as well . . . . .   3
     1.4.  gmt_unix_time is neither adequate nor necessary for its
           intended purpose  . . . . . . . . . . . . . . . . . . . .   3
   2.  Deprecating gmt_unix_time . . . . . . . . . . . . . . . . . .   4
   3.  Security considerations . . . . . . . . . . . . . . . . . . .   4
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Current versions of the TLS protocol, dating back to the SSL 3.0,
   describe a gmt_unix_time field, sent in the clear, as part of the TLS
   handshake.  While the exact format of this field is not strictly
   specified, typical implementations fill it with the time since the
   Unix epoch (Jan 1, 1970) in seconds.  This practice is neither
   necessary nor safe.

1.1.  The current behavior of gmt_unix_time

   According to RFC 2246 ("The TLS Protocol Version 1.0"), gmt_unix_time
   holds "The current time and date in standard UNIX 32-bit format
   (seconds since the midnight starting Jan 1, 1970, GMT) according to
   the sender's internal clock.  Clocks are not required to be set
   correctly by the basic TLS Protocol; higher level or application
   protocols may define additional requirements."  This text is retained
   unchanged in RFC 4346 and in RFC 5246.

   The gmt_unix_time field was first introduced in SSL 3.0, the
   predecessor to TLS 1.0.  The field was meant to preserve the
   protocol's robustness in the presence of unreliable random number
   generators that might generate the same random values more than once.
   If this happened, then SSL would be vulnerable to various attacks
   based on the non-uniqueness of the Random fields in the ClientHello
   and ServerHello messages.  Using the time value in this way was meant
   to prevent the same Random value from being sent more than once, even
   in the presence of misbehaved random number generators.

1.2.  gmt_unix_time is an undesirable client fingerprint

   Despite the late date, much of the world is still not synchronized to
   the second via an ntp-like service.  This means that different



Mathewson & Laurie        Expires June 08, 2014                 [Page 2]


Internet-Draft      Deprecating gmt_unix_time in TLS       December 2013


   clients have different views of the current time.  By declaring their
   view of the time in the gmt_unix_time field, clients provide
   eavesdroppers a fingerprint that helps to track and distinguish them.
   This fingerprint is useful for tracking mobile clients as they move
   around from network to network.  It can also distinguish clients who
   would otherwise be anonymized by using a VPN, NAT, or privacy
   network.

   Even when clocks are synchronized to within a second, an eavesdropper
   who can observe multiple gmt_unix_time values over time can build a
   statistical profile of when within a single second a client
   transitions from one second to another, and thereby distinguish such
   clients.

   Finally, an active packet-forging attacker who can forge NTP replies
   to a targeted client can introduce anomalies in that client's view of
   the current time.  By (say) slowly advancing a client a fixed
   interval into the future, the attacker can set a time-based plaintext
   "cookie" that will persist on the user's TLS connections for so long
   as the user's view of the current time remains skewed.  (The system
   of RFC 5906 prevents this attack by authenticating NTP replies, but
   it is not universally used.)

1.3.  gmt_unix_time is undesirable on servers as well

   While some protocol designs retain a clear separation between
   (nominally anonymous, possibly privacy-seeking) clients, and (well
   known, easy to find) servers, there are several counterexamples in
   which the responder to a TLS connection (the "Server" in the language
   of the TLS specification) also wishes to avoid fingerprinting.  These
   include services provided through an anonymizing service, and
   participation in some peer-to-peer network designs.

1.4.  gmt_unix_time is neither adequate nor necessary for its intended
      purpose

   One might argue that the problems discussed above are real, but that
   the benefit of the gmt_unix_time field outweighs them.  But in fact,
   the field provides no actual benefit.

   The purpose of gmt_unix_time is to render repeated PRNG output values
   survivable.  But other portions of the TLS protocol -- for example,
   the ephemeral key ciphersuites -- remove this alleged benefit.  If an
   implementation is prone to repeating the same ClientHello.Random
   values when it starts up, it is also likely prone to repeating those
   same values as Diffie-Hellman private keys, thereby rendering its
   connections insecure.




Mathewson & Laurie        Expires June 08, 2014                 [Page 3]


Internet-Draft      Deprecating gmt_unix_time in TLS       December 2013


   Even if the ephemeral key ciphersuites are not in use, it's not
   unusual in practice on a modern computer for multiple TLS clients or
   servers to initiate handshakes around the same second.  A one-second
   time value is insufficient to ensure uniqueness.

   Further, even if gmt_unix_time were adequate, it would not be
   necessary.  Given an even minimally cryptographically adequate PRNG,
   and a non-repeating clock, implementors can ensure that the PRNG
   generates non-repeated values by adding the current (high resolution)
   time to the PRNG state when seeding it.  This is not enough to ensure
   that the PRNG is unpredictable by an attacker, but it does ensure
   that the PRNG will not generate duplicate values even in the presence
   of inadequate entropy sources.  Most cryptographic libraries and
   operating system PRNGs take this approach today.

2.  Deprecating gmt_unix_time

   For the reasons we discuss above, we recommend that TLS implementors
   MUST by default set the entire value the ClientHello.Random and
   ServerHello.Random fields, including gmt_unix_time, to a
   cryptographically random sequence.

   If existing users of a TLS implementation may rely on gmt_unix_time
   containing the current time, we recommend that implementors MAY
   provide the ability to set gmt_unix_time as an option only, off by
   default.

   Generating cryptographically strong pseudorandom sequences is beyond
   the scope of this document.  Nevertheless, we recommend that
   implementors who may be concerned about the loss of the benefits of
   the gmt_unix_time field should ensure that their cryptographic PRNG
   input includes -- among the entropy that they hope will be strong --
   a high-resolution view of the current time.

3.  Security considerations

   The entire document is security-related.

4.  References

4.1.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.




Mathewson & Laurie        Expires June 08, 2014                 [Page 4]


Internet-Draft      Deprecating gmt_unix_time in TLS       December 2013


   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

4.2.  Informative References

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC5906]  Haberman, B. and D. Mills, "Network Time Protocol Version
              4: Autokey Specification", RFC 5906, June 2010.

Authors' Addresses

   Nick Mathewson
   The Tor Project

   Email: nickm@torproject.org


   Ben Laurie
   Google

   Email: benl@google.com
























Mathewson & Laurie        Expires June 08, 2014                 [Page 5]