One document matched: draft-mathewson-no-gmtunixtime-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC5906 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5906.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-mathewson-no-gmtunixtime-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)"
-->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Deprecating gmt_unix_time in TLS</title>
<!-- add 'role="edi[tor"' below for the editors if appropriate -->
<author fullname="Nick Mathewson" initials="N."
surname="Mathewson">
<organization abbrev="Tor">The Tor Project</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>nickm@torproject.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ben Laurie" initials="B."
surname="Laurie">
<organization>Google</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>benl@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>TLS Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>TLS</keyword>
<keyword>gmt_unix_time</keyword>
<keyword>fingerprinting</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
<section title="The current behavior of gmt_unix_time">
<t>According to RFC 2246 ("The TLS Protocol Version 1.0"), gmt_unix_time
holds
<!-- Is there some way to do a block quotation? - NM -->
"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."
<!-- End blockquote -->
This text is retained unchanged in RFC 4346 and in RFC 5246.
</t>
<t>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.
</t>
</section>
<section title="gmt_unix_time is an undesirable client fingerprint">
<t>Despite the late date, much of the world is still not synchronized to
the second via an ntp-like service. This means that different 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.
</t>
<t>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.
</t>
<t>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.)
</t>
</section>
<section title="gmt_unix_time is undesirable on servers as well">
<t>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.
</t>
</section>
<section title="gmt_unix_time is neither adequate nor necessary for its
intended purpose">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
<section title="Deprecating gmt_unix_time">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<!-- <section title="Impact on existing tools"> -->
<!-- d https://github.com/openssl/openssl/pull/23
and https://github.com/openssl/openssl/pull/29 -->
<!-- https://bugzilla.mozilla.org/show_bug.cgi?id=937976 -->
<!-- </section> -->
<section title="Security considerations">
<t>The entire document is security-related.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2246;
&RFC4346;
&RFC5246;
<!--
<reference anchor="min_ref">
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
-->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC4086;
&RFC5905;
&RFC5906;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:24 |