< draft-ietf-ntp-roughtime-04.txt   draft-ietf-ntp-roughtime-05.txt >
Internet Engineering Task Force A. Malhotra Internet Engineering Task Force A. Malhotra
Internet-Draft Boston University Internet-Draft Boston University
Intended status: Informational A. Langley Intended status: Informational A. Langley
Expires: August 25, 2021 Google Expires: 21 November 2021 Google
W. Ladd W. Ladd
Cloudflare Cloudflare
M. Dansarie M. Dansarie
February 21, 2021 20 May 2021
Roughtime Roughtime
draft-ietf-ntp-roughtime-04 draft-ietf-ntp-roughtime-05
Abstract Abstract
This document specifies Roughtime - a protocol that aims to achieve This document specifies Roughtime - a protocol that aims to achieve
rough time synchronization while detecting servers that provide rough time synchronization while detecting servers that provide
inaccurate time and providing cryptographic proof of their inaccurate time and providing cryptographic proof of their
malfeasance. malfeasance.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 25, 2021. This Internet-Draft will expire on 21 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. The Guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. int32 . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.4. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 6 5.1.5. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1.1. VER . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1.2. NONC . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. SIG . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 11 6.2.2. VER . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Validity of Response . . . . . . . . . . . . . . . . . . 12 6.2.3. NONC . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Integration into NTP . . . . . . . . . . . . . . . . . . . . 12 6.2.4. PATH . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.5. SREP . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 13 6.2.6. CERT . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6.2.7. INDX . . . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 12
11.1. Service Name and Transport Protocol Port Number Registry 13 6.3.1. Root Value Validity Check Algorithm . . . . . . . . . 12
11.2. Roughtime Version Registry . . . . . . . . . . . . . . . 14 6.4. Validity of Response . . . . . . . . . . . . . . . . . . 13
11.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 14 7. Integration Into NTP . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 9. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 17 11.1. Service Name and Transport Protocol Port Number
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 18 Registry . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Roughtime Version Registry . . . . . . . . . . . . . . . 15
11.3. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Time synchronization is essential to Internet security as many Time synchronization is essential to Internet security as many
security protocols and other applications require synchronization security protocols and other applications require synchronization
[RFC7384] [MCBG]. Unfortunately widely deployed protocols such as [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as
the Network Time Protocol (NTP) [RFC5905] lack essential security the Network Time Protocol (NTP) [RFC5905] lack essential security
features, and even newer protocols like Network Time Security (NTS) features, and even newer protocols like Network Time Security (NTS)
[RFC8915] lack mechanisms to ensure that the servers behave [RFC8915] lack mechanisms to ensure that the servers behave
correctly. Authenticating time servers prevents network adversaries correctly. Authenticating time servers prevents network adversaries
from modifying time packets, but an authenticated time server still from modifying time packets, but an authenticated time server still
has full control over the contents of the time packet and may go has full control over the contents of the time packet and may
rogue. The Roughtime protocol provides cryptographic proof of transmit incorrect time. The Roughtime protocol provides
malfeasance, enabling clients to detect and prove to a third party a cryptographic proof of malfeasance, enabling clients to detect and
server's attempts to influence the time a client computes. prove to a third party a server's attempts to influence the time a
client computes.
+==============+======================+=============================+
| Protocol | Authenticated Server | Server Malfeasance Evidence |
+==============+======================+=============================+
| NTP, | N | N |
| Chronos | | |
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
| Protocol | Authenticated Server | Server Malfeasance Evidence | | NTP-MAC | Y* | N |
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
| NTP, Chronos | N | N | | NTP-Autokey | Y** | N |
| NTP-MD5 | Y* | N | +--------------+----------------------+-----------------------------+
| NTP-Autokey | Y** | N | | NTS | Y | N |
| NTS | Y | N | +--------------+----------------------+-----------------------------+
| Roughtime | Y | Y | | Roughtime | Y | Y |
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
Security Properties of current protocols Table 1: Security Properties of current protocols.
Table 1
Y* For security issues with symmetric-key based NTP-MD5 Y* For security issues with symmetric-key based NTP-MAC
authentication, please refer to RFC 8573 [RFC8573]. authentication, please refer to RFC 8573 [RFC8573].
Y** For security issues with Autokey Public Key Authentication, refer Y** For security issues with Autokey Public Key Authentication, refer
to [Autokey]. to [Autokey].
o If a server's timestamps do not fit into the time context of other * If a server's timestamps do not fit into the time context of other
servers' responses, then a Roughtime client can cryptographically servers' responses, then a Roughtime client can cryptographically
prove this misbehavior to third parties. This helps detect "bad" prove this misbehavior to third parties. This helps detect
servers. dishonest or malfunctioning servers.
o A Roughtime client can roughly detect (with no absolute guarantee) * A Roughtime client can roughly detect (with no absolute guarantee)
a delay attack [DelayAttacks] but can not cryptographically prove a delay attack [DelayAttacks] but can not cryptographically prove
this to a third party. However, the absence of proof of this to a third party. However such attacks expand the round trip
malfeasance should not be considered a proof of absence of time between request and response.
malfeasance. So Roughtime should not be used as a witness that a
server is overall "good".
o Note that delay attacks cannot be detected/stopped by any * Note that delay attacks cannot be detected/stopped by any
protocol. Delay attacks can not, however, undermine the security protocol. Delay attacks can not, however, undermine the security
guarantees provided by Roughtime. guarantees provided by Roughtime.
o Although delay attacks cannot be prevented, they can be limited to * Although delay attacks cannot be prevented, they can be limited to
a predetermined upper bound. This can be done by defining a a predetermined upper bound. This can be done by defining a
maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a
Roughtime client is willing to accept. A Roughtime client can Roughtime client is willing to accept. A Roughtime client can
measure the RTT of every request-response handshake and compare it measure the RTT of every request-response handshake and compare it
to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding server to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding
is assumed to be a falseticker. When this approach is used the measurement is discarded. When this approach is used, the maximal
maximal time error that can be caused by a delay attack is MAX- time error that can be caused by a delay attack is MAX-RTT/2. It
RTT/2. It should be noted that this approach assumes that the should be noted that this approach assumes that the nature of the
nature of the system is known to the client, including reasonable system is known to the client, including reasonable upper bounds
upper bounds on the RTT value. on the RTT value.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Overview 3. Protocol Overview
Roughtime is a protocol for rough time synchronization that enables Roughtime is a protocol for rough time synchronization that enables
clients to provide cryptographic proof of server malfeasance. It clients to provide cryptographic proof of server malfeasance. It
does so by having responses from servers include a signature with a does so by having responses from servers include a signature over a
certificate rooted in a long-term public/private key pair over a value derived from a nonce in the client request. This provides
value derived from a nonce provided by the client in its request. cryptographic proof that the timestamp was issued after the server
This provides cryptographic proof that the timestamp was issued after received the client's request. The derived value included in the
the server received the client's request. The derived value included server's response is the root of a Merkle tree which includes the
in the server's response is the root of a Merkle tree which includes hash of the client's nonce as the value of one of its leaf nodes.
the hash of the client's nonce as the value of one of its leaf nodes.
This enables the server to amortize the relatively costly signing This enables the server to amortize the relatively costly signing
operation over a number of client requests. operation over a number of client requests.
Single server mode: At its most basic level, Roughtime is a one round Single server mode: At its most basic level, Roughtime is a one round
protocol in which a completely fresh client requests the current time protocol in which a completely fresh client requests the current time
and the server sends a signed response. The response includes a and the server sends a signed response. The response includes a
timestamp and a radius used to indicate the server's certainty about timestamp and a radius used to indicate the server's certainty about
the reported time. For example, a radius of 1,000,000 microseconds the reported time. For example, a radius of 1,000,000 microseconds
means the server is absolutely confident that the true time is within means the server is absolutely confident that the true time is within
one second of the reported time. one second of the reported time.
The server proves freshness of its response as follows: The client's The server proves freshness of its response as follows. The client's
request contains a nonce. The server incorporates the nonce into its request contains a nonce which the server incorporates into its
signed response so that the client can verify the server's signatures signed response. The client can verify the server's signatures and -
covering the nonce issued by the client. Provided that the nonce has provided that the nonce has sufficient entropy - this proves that the
sufficient entropy, this proves that the signed response could only signed response could only have been generated after the nonce.
have been generated after the nonce.
4. The Guarantee 4. The Guarantee
A Roughtime server guarantees that a response to a query sent at t_1, A Roughtime server guarantees that a response to a query sent at t_1,
received at t_2, and with timestamp t_3 has been created between the received at t_2, and with timestamp t_3 has been created between the
transmission of the query and its reception. If t_3 is not within transmission of the query and its reception. If t_3 is not within
that interval, a server inconsistency may be detected and used to that interval, a server inconsistency may be detected and used to
impeach the server. The propagation of such a guarantee and its use impeach the server. The propagation of such a guarantee and its use
of type synchronization is discussed in Section 7. No delay attacker of type synchronization is discussed in Section 7. No delay attacker
may affect this: they may only expand the interval between t_1 and may affect this: they may only expand the interval between t_1 and
skipping to change at page 5, line 25 skipping to change at page 5, line 39
5. Message Format 5. Message Format
Roughtime messages are maps consisting of one or more (tag, value) Roughtime messages are maps consisting of one or more (tag, value)
pairs. They start with a header, which contains the number of pairs, pairs. They start with a header, which contains the number of pairs,
the tags, and value offsets. The header is followed by a message the tags, and value offsets. The header is followed by a message
values section which contains the values associated with the tags in values section which contains the values associated with the tags in
the header. Messages MUST be formatted according to Figure 1 as the header. Messages MUST be formatted according to Figure 1 as
described in the following sections. described in the following sections.
Messages may be recursive, i.e. the value of a tag can itself be a Messages MAY be recursive, i.e. the value of a tag can itself be a
Roughtime message. Roughtime message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of pairs (uint32) | | Number of pairs (uint32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. N-1 offsets (uint32) . . N-1 offsets (uint32) .
skipping to change at page 5, line 52 skipping to change at page 6, line 29
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Values . . Values .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Roughtime Message Format Figure 1: Roughtime Message Format
5.1. Data Types 5.1. Data Types
5.1.1. int32 5.1.1. int32
An int32 is a 32 bit signed integer. It is serialized in sign- An int32 is a 32 bit signed integer. It is serialized least
magnitude representation with the sign bit in the most significant significant byte first in sign-magnitude representation with the sign
bit. It is serialized least significant byte first. The negative bit in the most significant bit. The negative zero value
zero value (0x80000000) MUST NOT be used. (0x80000000) MUST NOT be used and any message with it is
syntactically invalid and MUST be ignored.
5.1.2. uint32 5.1.2. uint32
A uint32 is a 32 bit unsigned integer. It is serialized with the A uint32 is a 32 bit unsigned integer. It is serialized with the
least significant byte first. least significant byte first.
5.1.3. uint64 5.1.3. uint64
A uint64 is a 64 bit unsigned integer. It is serialized with the A uint64 is a 64 bit unsigned integer. It is serialized with the
least significant byte first. least significant byte first.
5.1.4. Tag 5.1.4. Tag
Tags are used to identify values in Roughtime messages. A tag is a Tags are used to identify values in Roughtime messages. A tag is a
uint32 but may also be listed as a sequence of up to four ASCII uint32 but may also be listed in this document as a sequence of up to
characters [RFC0020]. ASCII strings shorter than four characters can four ASCII characters [RFC0020]. ASCII strings shorter than four
be unambiguously converted to tags by padding them with zero bytes. characters can be unambiguously converted to tags by padding them
For example, the ASCII string "NONC" would correspond to the tag with zero bytes. For example, the ASCII string "NONC" would
0x434e4f4e and "PAD" would correspond to 0x00444150. correspond to the tag 0x434e4f4e and "PAD" would correspond to
0x00444150. Note that when encoded into a message the ASCII values
will be in the corresponding order.
5.1.5. Timestamp 5.1.5. Timestamp
A timestamp is a uint64 interpreted in the following way. The most A timestamp is a uint64 interpreted in the following way. The most
significant 3 bytes contain the integer part of a Modified Julian significant 3 bytes contain the integer part of a Modified Julian
Date (MJD). The least significant 5 bytes is a count of the number Date (MJD). The least significant 5 bytes is a count of the number
of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] of microseconds since midnight on that day.
since midnight on that day.
The MJD is the number of UTC days since 17 November 1858 The MJD is the number of UTC days since 17 November 1858
[ITU-R_TF.457-2]. It is useful to note that 1 January 1970 is 40,587 [ITU-R_TF.457-2]. It is useful to note that 1 January 1970 is 40,587
days after 17 November 1858. days after 17 November 1858.
Note that, unlike NTP, this representation does not use the full Note that, unlike NTP, this representation does not use the full
number of bits in the fractional part and that days with leap seconds number of bits in the fractional part and that days with leap seconds
will have more or fewer than the nominal 86,400,000,000 microseconds. will have more or fewer than the nominal 86,400,000,000 microseconds.
5.2. Header 5.2. Header
skipping to change at page 7, line 21 skipping to change at page 7, line 47
Offsets refer to the positions of the values in the message values Offsets refer to the positions of the values in the message values
section. All offsets MUST be multiples of four and placed in section. All offsets MUST be multiples of four and placed in
increasing order. The first post-header byte is at offset 0. The increasing order. The first post-header byte is at offset 0. The
offset array is considered to have a not explicitly encoded value of offset array is considered to have a not explicitly encoded value of
0 as its zeroth entry. The value associated with the ith tag begins 0 as its zeroth entry. The value associated with the ith tag begins
at offset[i] and ends at offset[i+1]-1, with the exception of the at offset[i] and ends at offset[i+1]-1, with the exception of the
last value which ends at the end of the message. Values may have last value which ends at the end of the message. Values may have
zero length. zero length.
Tags MUST be listed in the same order as the offsets of their values. Tags MUST be listed in the same order as the offsets of their values
A tag MUST NOT appear more than once in a header. Tags MUST also be and MUST also be sorted in ascending order by numeric value. A tag
sorted in ascending order by numeric value. MUST NOT appear more than once in a header.
6. Protocol 6. Protocol Details
As described in Section 3, clients initiate time synchronization by As described in Section 3, clients initiate time synchronization by
sending requests containing a nonce to servers who send signed time sending requests containing a nonce to servers who send signed time
responses in return. Roughtime packets can be sent between clients responses in return. Roughtime packets can be sent between clients
and servers either as UDP datagrams or via TCP streams. Servers and servers either as UDP datagrams or via TCP streams. Servers
SHOULD support the UDP transport mode, while TCP transport is SHOULD support the UDP transport mode, while TCP transport is
OPTIONAL. OPTIONAL.
A Roughtime packet MUST be formatted according to Figure 2 and as A Roughtime packet MUST be formatted according to Figure 2 and as
described here. The first field is a uint64 with the value described here. The first field is a uint64 with the value
skipping to change at page 8, line 38 skipping to change at page 9, line 5
servers MAY send responses out of order. The connection SHOULD be servers MAY send responses out of order. The connection SHOULD be
closed by the client when it has no more requests to send and has closed by the client when it has no more requests to send and has
received all expected responses. Either side SHOULD close the received all expected responses. Either side SHOULD close the
connection in response to synchronization, format, implementation- connection in response to synchronization, format, implementation-
defined timeouts, or other errors. defined timeouts, or other errors.
All requests and responses MUST contain the VER tag. It contains a All requests and responses MUST contain the VER tag. It contains a
list of one or more uint32 version numbers. The version of Roughtime list of one or more uint32 version numbers. The version of Roughtime
specified by this memo has version number 1. specified by this memo has version number 1.
For testing drafts of this memo, a version number of 0x80000000 plus NOTE TO RFC EDITOR: remove this paragraph before publication. For
the draft number is used. testing drafts of this memo, a version number of 0x80000000 plus the
draft number is used.
6.1. Requests 6.1. Requests
A request MUST contain the tags NONC and VER. A request MUST contain the tags VER and NONC. Tags other than NONC
and VER SHOULD be ignored by the server. A future version of this
protocol may mandate additional tags in the message and asign them
semantic meaning.
The value of the NONC tag is a 64 byte nonce. It SHOULD be generated The size of the request message SHOULD be at least 1024 bytes when
in a manner indistinguishable from random. the UDP transport mode is used. To attain this size the PAD tag
SHOULD be added to the message. Its value SHOULD be all zeros.
Responding to requests shorter than 1024 bytes is OPTIONAL and
servers MUST NOT send responses larger than the requests they are
replying to.
6.1.1. VER
In a request, the VER tag contains a list of versions. The VER tag In a request, the VER tag contains a list of versions. The VER tag
MUST include at least one Roughtime version supported by the client. MUST include at least one Roughtime version supported by the client.
The client MUST ensure that the version numbers and tags included in The client MUST ensure that the version numbers and tags included in
the request are not incompatible with each other or the packet the request are not incompatible with each other or the packet
contents. contents.
Tags other than NONC and VER SHOULD be ignored by the server. 6.1.2. NONC
The size of the request message SHOULD be at least 1024 bytes when The value of the NONC tag is a 32 byte nonce. It SHOULD be generated
the UDP transport mode is used. To attain this size the PAD tag in a manner indistinguishable from random. BCP 106 contains specific
SHOULD be added to the message. Its value SHOULD be all zeros. guidelines regarding this [RFC4086].
Responding to requests shorter than 1024 bytes is OPTIONAL and
servers MUST NOT send responses larger than the requests they are
replying to.
6.2. Responses 6.2. Responses
A response MUST contain the tags CERT, INDX, NONC, PATH, SIG, SREP, A response MUST contain the tags SIG, VER, NONC, PATH, SREP, CERT,
and VER. and INDX.
The SIG tag is a signature over the SREP value using the public key 6.2.1. SIG
contained in CERT, as explained below.
The SREP tag contains a time response. Its value is a Roughtime In general, a SIG tag value is a 64 byte Ed25519 signature [RFC8032]
message with the tags ROOT, MIDP, and RADI. The server MAY include over a concatenation of a signature context ASCII string and the
any of the tags DUT1, DTAI and LEAP in the contents of the SREP tag. entire value of a tag. All context strings MUST include a
terminating zero byte.
The NONC tag contains the nonce of the message being responded to. The SIG tag in the root of a response MUST be a signature over the
SREP value using the public key contained in CERT. The context
string MUST be "RoughTime v1 response signature".
The ROOT tag contains a 32 byte value of a Merkle tree root as 6.2.2. VER
In a response, the VER tag MUST contain a single version number. It
SHOULD be one of the version numbers supplied by the client in its
request. The server MUST ensure that the version number corresponds
with the rest of the packet contents.
6.2.3. NONC
The NONC tag MUST contain the nonce of the message being responded
to.
6.2.4. PATH
The PATH tag value MUST be a multiple of 32 bytes long and represent
a path of 32 byte hash values in the Merkle tree used to generate the
ROOT value as described in Section 6.3. In the case where a response
is prepared for a single request and the Merkle tree contains only
the root node, the size of PATH MUST be zero.
6.2.5. SREP
The SREP tag contains a time response. Its value MUST be a Roughtime
message with the tags ROOT, MIDP, and RADI. The server MAY include
any of the tags DUT1, DTAI, and LEAP in the contents of the SREP tag.
The ROOT tag MUST contain a 32 byte value of a Merkle tree root as
described in Section 6.3. described in Section 6.3.
The MIDP tag value is a timestamp of the moment of processing. The MIDP tag value MUST be timestamp of the moment of processing.
The RADI tag value is a uint32 representing the server's estimate of The RADI tag value MUST be a uint32 representing the server's
the accuracy of MIDP in microseconds. Servers MUST ensure that the estimate of the accuracy of MIDP in microseconds. Servers MUST
true time is within (MIDP-RADI, MIDP+RADI) at the time they compose ensure that the true time is within (MIDP-RADI, MIDP+RADI) at the
the response message. time they transmit the response message.
The DUT1 tag value is an int32 indicating the predicted difference The DUT1 tag value MUST be an int32 indicating the predicted
between UT1 and UTC (UT1 - UTC) in milliseconds as given by the difference between UT1 and UTC (UT1 - UTC) in milliseconds as given
International Earth Rotation and Reference Systems Service (IERS). by the International Earth Rotation and Reference Systems Service
(IERS).
The DTAI tag value is an int32 indicating the current difference The DTAI tag value MUST be an int32 indicating the current difference
between International Atomic Time (TAI) and UTC (TAI - UTC) in between International Atomic Time (TAI) and UTC (TAI - UTC) in
milliseconds as published in the International Bureau of Weights and milliseconds as published in the International Bureau of Weights and
Measures' (BIPM) Circular T. Measures' (BIPM) Circular T.
The LEAP tag contains zero or more int32 values, each representing a The LEAP tag MUST contain zero or more int32 values, each
past or future leap second event. Positive values represent the representing a past or future leap second event. Positive values
addition of a second and negative values represent the removal of a represent the addition of a second and negative values represent the
second. The absolute value represents the MJD of the second after removal of a second. The absolute value represents the MJD of the
the leap second event, i.e., the first second with a new UTC - TAI day that begins immediately after the leap second event.
difference. The leap second events MUST be sorted in reverse
chronological order and the first item MUST be the last (past or
future) leap second event that the server knows about. A LEAP tag
with zero int32 values indicates that the server does not hold any
updated leap second information.
The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a By way of illustration, there was a leap second 31 December 2016
signature context concatenated with the entire value of a DELE or 23:59:60. This event would be represented by the tag with numeric
SREP tag. Signatures of DELE tags MUST use the ASCII string value 57754. The positive sign represents that there was an
"RoughTime v1 delegation signature--" and signatures of SREP tags additional second inserted, the numeric value indicates 1 January
MUST use the ASCII string "RoughTime v1 response signature" as 2017, the following day that began at midnight after the addition.
signature context. Both strings MUST include a terminating zero
byte. The leap second events MUST be sorted in reverse chronological order
and the first item MUST be the last (past or future) leap second
event that the server knows about. A LEAP tag with zero int32 values
indicates that the server does not hold any updated leap second
information.
6.2.6. CERT
The CERT tag contains a public-key certificate signed with the The CERT tag contains a public-key certificate signed with the
server's long-term key. Its value is a Roughtime message with the server's long-term key. Its value is a Roughtime message with the
tags DELE and SIG, where SIG is a signature over the DELE value. tags DELE and SIG, where SIG is a signature over the DELE value. The
context string used to generate SIG MUST be "RoughTime v1 delegation
signature--".
The DELE tag contains a delegated public-key certificate used by the The DELE tag contains a delegated public-key certificate used by the
server to sign the SREP tag. Its value is a Roughtime message with server to sign the SREP tag. Its value is a Roughtime message with
the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to
enable separation of a long-term public key from keys on devices enable separation of a long-term public key from keys on devices
exposed to the public Internet. exposed to the public Internet.
The MINT tag is the minimum timestamp for which the key in PUBK is The MINT tag is the minimum timestamp for which the key in PUBK is
trusted to sign responses. MIDP MUST be more than or equal to MINT trusted to sign responses. MIDP MUST be more than or equal to MINT
for a response to be considered valid. for a response to be considered valid.
The MAXT tag is the maximum timestamp for which the key in PUBK is The MAXT tag is the maximum timestamp for which the key in PUBK is
trusted to sign responses. MIDP MUST be less than or equal to MAXT trusted to sign responses. MIDP MUST be less than or equal to MAXT
for a response to be considered valid. for a response to be considered valid.
The PUBK tag contains a temporary 32 byte Ed25519 public key which is The PUBK tag contains a temporary 32 byte Ed25519 public key which is
used to sign the SREP tag. used to sign the SREP tag.
6.2.7. INDX
The INDX tag value is a uint32 determining the position of NONC in The INDX tag value is a uint32 determining the position of NONC in
the Merkle tree used to generate the ROOT value as described in the Merkle tree used to generate the ROOT value as described in
Section 6.3. Section 6.3.
The PATH tag value is a multiple of 32 bytes long and represents a
path of 32 byte hash values in the Merkle tree used to generate the
ROOT value as described in Section 6.3. In the case where a response
is prepared for a single request and the Merkle tree contains only
the root node, the size of PATH is zero.
In a response, the VER tag MUST contain a single version number. It
SHOULD be one of the version numbers supplied by the client in its
request. The server MUST ensure that the version number corresponds
with the rest of the packet contents.
6.3. The Merkle Tree 6.3. The Merkle Tree
A Merkle tree is a binary tree where the value of each non-leaf node A Merkle tree is a binary tree where the value of each non-leaf node
is a hash value derived from its two children. The root of the tree is a hash value derived from its two children. The root of the tree
is thus dependent on all leaf nodes. is thus dependent on all leaf nodes.
In Roughtime, each leaf node in the Merkle tree represents the nonce In Roughtime, each leaf node in the Merkle tree represents the nonce
of one request that a response message is sent in reply to. Leaf in one request. Leaf nodes are indexed left to right, beginning with
nodes are indexed left to right, beginning with zero. zero.
The values of all nodes are calculated from the leaf nodes and up The values of all nodes are calculated from the leaf nodes and up
towards the root node using the first 32 bytes of the output of the towards the root node using the first 32 bytes of the output of the
SHA-512 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is SHA-512 hash algorithm [SHS]. For leaf nodes, the byte 0x00 is
prepended to the nonce before applying the hash function. For all prepended to the nonce before applying the hash function. For all
other nodes, the byte 0x01 is concatenated with first the left and other nodes, the byte 0x01 is concatenated with first the left and
then the right child node value before applying the hash function. then the right child node value before applying the hash function.
The value of the Merkle tree's root node is included in the ROOT tag The value of the Merkle tree's root node is included in the ROOT tag
of the response. of the response.
The index of a request's nonce node is included in the INDX tag of The index of a request's nonce node is included in the INDX tag of
the response. the response.
The values of all sibling nodes in the path between a request's nonce The values of all sibling nodes in the path between a request's nonce
node and the root node is stored in the PATH tag so that the client node and the root node is stored in the PATH tag so that the client
can reconstruct and validate the value in the ROOT tag using its can reconstruct and validate the value in the ROOT tag using its
nonce. nonce. These values are each 32 bytes and are stored one after the
other with no additional padding or structure. The order in which
they are stored is described in Section 6.3.1
6.3.1. Root Value Validity Check Algorithm 6.3.1. Root Value Validity Check Algorithm
One starts by computing the hash of the NONC value from the request, We describe how to compute the hash of the Merkel tree from the
with 0x00 prepended. Then one walks from the least significant bit values in the tags PATH, INDX, and NONC. Our algorithm maintains a
of INDX to the most significant bit, and also walks towards the end current hash value. The bits of INDX are ordered from least to most
of PATH. significant in this algorithm.
If PATH ends then the remaining bits of the INDX MUST be all zero. At initialization hash is set to H(0x00 || nonce).
This indicates the termination of the walk, and the current value
MUST equal ROOT if the response is valid.
If the current bit is 0, one hashes 0x01, the current hash, and the If no more entries remain in PATH the current hash is the hash of the
value from PATH to derive the next current value. Merkel tree. All remaining bits of INDX must be zero.
If the current bit is 1 one hashes 0x01, the value from PATH, and the Otherwise let node be the next 32 bytes in PATH. If the current bit
current hash to derive the next current value. in INDX is 0 then hash = H(0x01 || node || hash), else hash =
H(0x01 || hash || node).
6.4. Validity of Response 6.4. Validity of Response
A client MUST check the following properties when it receives a A client MUST check the following properties when it receives a
response. We assume the long-term server public key is known to the response. We assume the long-term server public key is known to the
client through other means. client through other means.
o The signature in CERT was made with the long-term key of the * The signature in CERT was made with the long-term key of the
server. server.
o The DELE timestamps and the MIDP value are consistent. * The DELE timestamps and the MIDP value are consistent.
o The INDX and PATH values prove NONC was included in the Merkle * The INDX and PATH values prove NONC was included in the Merkle
tree with value ROOT using the algorithm in Section 6.3.1. tree with value ROOT using the algorithm in Section 6.3.1.
o The signature of SREP in SIG validates with the public key in * The signature of SREP in SIG validates with the public key in
DELE. DELE.
A response that passes these checks is said to be valid. Validity of A response that passes these checks is said to be valid. Validity of
a response does not prove the time is correct, but merely that the a response does not prove the time is correct, but merely that the
server signed it, and thus guarantees that it began to compute the server signed it, and thus promises that it began to compute the
signature at a time in the interval (MIDP-RADI, MIDP+RADI). signature at a time in the interval (MIDP-RADI, MIDP+RADI).
7. Integration into NTP 7. Integration Into NTP
We assume that there is a bound PHI on the frequency error in the We assume that there is a bound PHI on the frequency error in the
clock on the machine. Given a measurement taken at a local time t1, clock on the machine. Given a measurement taken at a local time t,
we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. we know the true time is in (t-delta-sigma, t-delta+sigma). After d
After d seconds have elapsed we know the true time is within [ t1- seconds have elapsed we know the true time is within (t-delta-sigma-
delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way d*PHI, t-delta+sigma+d*PHI). A simple and effective way to mix with
to mix with NTP or PTP discipline of the clock is to trim the NTP or PTP discipline of the clock is to trim the observed intervals
observed intervals in NTP to fit entirely within this window or in NTP to fit entirely within this window or reject measurements that
reject measurements that fall to far outside. This assumes time has fall to far outside. This assumes time has not been stepped. If the
not been stepped. If the NTP process decides to step the time, it NTP process decides to step the time, it MUST use Roughtime to ensure
MUST use Roughtime to ensure the new truetime estimate that will be the new truetime estimate that will be stepped to is consistent with
stepped to is consistent with the true time. the true time.
Should this window become too large, another Roughtime measurement is Should this window become too large, another Roughtime measurement is
called for. The definition of "too large" is implementation defined. called for. The definition of "too large" is implementation defined.
Implementations MAY use other, more sophisticated means of adjusting Implementations MAY use other, more sophisticated means of adjusting
the clock respecting Roughtime information. the clock respecting Roughtime information. Other applications such
as X.509 verification may wish to
8. Grease 8. Grease
Servers MAY send back a fraction of responses that are syntactically Servers MAY send back a fraction of responses that are syntactically
invalid or contain invalid signatures as well as incorrect times. invalid or contain invalid signatures as well as incorrect times.
Clients MUST properly reject such responses. Servers MUST NOT send Clients MUST properly reject such responses. Servers MUST NOT send
back responses with incorrect times and valid signatures. Either back responses with incorrect times and valid signatures. Either
signature MAY be invalid for this application. signature MAY be invalid for this application.
9. Roughtime Servers 9. Roughtime Servers
NOTE TO RFC EDITOR: remove this section before publication.
The below list contains a list of servers with their public keys in The below list contains a list of servers with their public keys in
Base64 format. These servers may implement older versions of this Base64 format. These servers may implement older versions of this
specification. specification.
address: roughtime.cloudflare.com address: roughtime.cloudflare.com
port: 2002 port: 2002
long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo=
address: roughtime.int08h.com address: roughtime.int08h.com
port: 2002 port: 2002
skipping to change at page 13, line 31 skipping to change at page 14, line 39
address: roughtime.sandbox.google.com address: roughtime.sandbox.google.com
port: 2002 port: 2002
long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ=
address: roughtime.se address: roughtime.se
port: 2002 port: 2002
long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI=
10. Acknowledgements 10. Acknowledgements
Thomas Peterson corrected multiple nits. Peter Loethberg (Lothberg), Thomas Peterson corrected multiple nits. Peter Loethberg, Tal
Tal Mizrahi, Ragnar Sundblad, Kristof Teichel, and the other members Mizrahi, Ragnar Sundblad, Kristof Teichel, and the other members of
of the NTP working group contributed comments and suggestions. the NTP working group contributed comments and suggestions.
11. IANA Considerations 11. IANA Considerations
11.1. Service Name and Transport Protocol Port Number Registry 11.1. Service Name and Transport Protocol Port Number Registry
IANA is requested to allocate the following entry in the Service Name IANA is requested to allocate the following entry in the Service Name
and Transport Protocol Port Number Registry [RFC6335]: and Transport Protocol Port Number Registry [RFC6335]:
Service Name: Roughtime Service Name: Roughtime
skipping to change at page 13, line 45 skipping to change at page 15, line 4
11. IANA Considerations 11. IANA Considerations
11.1. Service Name and Transport Protocol Port Number Registry 11.1. Service Name and Transport Protocol Port Number Registry
IANA is requested to allocate the following entry in the Service Name IANA is requested to allocate the following entry in the Service Name
and Transport Protocol Port Number Registry [RFC6335]: and Transport Protocol Port Number Registry [RFC6335]:
Service Name: Roughtime Service Name: Roughtime
Transport Protocol: tcp,udp Transport Protocol: tcp,udp
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: Roughtime time synchronization Description: Roughtime time synchronization
Reference: [[this memo]] Reference: [[this memo]]
Port Number: [[TBD1]], selected by IANA from the User Port range Port Number: [[TBD1]], selected by IANA from the User Port range
11.2. Roughtime Version Registry 11.2. Roughtime Version Registry
IANA is requested to create a new registry entitled " Roughtime IANA is requested to create a new registry entitled "Roughtime
Version Registry " Entries shall have the following fields: Version Registry". Entries shall have the following fields:
Version ID (REQUIRED): a 32-bit unsigned integer Version ID (REQUIRED): a 32-bit unsigned integer
Version name (REQUIRED): A short text string naming the version Version name (REQUIRED): A short text string naming the version
being identified. being identified.
Reference (REQUIRED): A reference to a relevant specification Reference (REQUIRED): A reference to a relevant specification
document. document.
The policy for allocation of new entries SHOULD be: IETF Review. The policy for allocation of new entries SHOULD be: IETF Review.
The initial contents of this registry shall be as follows: The initial contents of this registry shall be as follows:
+-----------------------+------------------------------+------------+ +=======================+======================+===============+
| Version ID | Version name | Reference | | Version ID | Version name | Reference |
+-----------------------+------------------------------+------------+ +=======================+======================+===============+
| 0x0 | Reserved | [[this | | 0x0 | Reserved | [[this memo]] |
| | | memo]] | +-----------------------+----------------------+---------------+
| 0x1 | Roughtime version 1 | [[this | | 0x1 | Roughtime version 1 | [[this memo]] |
| | | memo]] | +-----------------------+----------------------+---------------+
| 0x2-0x7fffffff | Unassigned | | | 0x2-0x7fffffff | Unassigned | |
| 0x80000000-0xffffffff | Reserved for Private or | [[this | +-----------------------+----------------------+---------------+
| | Experimental use | memo]] | | 0x80000000-0xffffffff | Reserved for Private | [[this memo]] |
+-----------------------+------------------------------+------------+ | | or Experimental use | |
+-----------------------+----------------------+---------------+
Table 2: Roughtime version assignments.
11.3. Roughtime Tag Registry 11.3. Roughtime Tag Registry
IANA is requested to create a new registry entitled "Roughtime Tag IANA is requested to create a new registry entitled "Roughtime Tag
Registry". Entries SHALL have the following fields: Registry". Entries SHALL have the following fields:
Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format.
ASCII Representation (OPTIONAL): The ASCII representation of the ASCII Representation (OPTIONAL): The ASCII representation of the
tag in accordance with Section 5.1.4 of this memo, if applicable. tag in accordance with Section 5.1.4 of this memo, if applicable.
Reference (REQUIRED): A reference to a relevant specification Reference (REQUIRED): A reference to a relevant specification
document. document.
The policy for allocation of new entries in this registry SHOULD be: The policy for allocation of new entries in this registry SHOULD be:
Specification Required. Specification Required.
The initial contents of this registry SHALL be as follows: The initial contents of this registry SHALL be as follows:
+------------+----------------------+---------------+ +============+======================+===============+
| Tag | ASCII Representation | Reference | | Tag | ASCII Representation | Reference |
+------------+----------------------+---------------+ +============+======================+===============+
| 0x00444150 | PAD | [[this memo]] | | 0x00444150 | PAD | [[this memo]] |
+------------+----------------------+---------------+
| 0x00474953 | SIG | [[this memo]] | | 0x00474953 | SIG | [[this memo]] |
+------------+----------------------+---------------+
| 0x00524556 | VER | [[this memo]] | | 0x00524556 | VER | [[this memo]] |
+------------+----------------------+---------------+
| 0x31545544 | DUT1 | [[this memo]] | | 0x31545544 | DUT1 | [[this memo]] |
+------------+----------------------+---------------+
| 0x434e4f4e | NONC | [[this memo]] | | 0x434e4f4e | NONC | [[this memo]] |
+------------+----------------------+---------------+
| 0x454c4544 | DELE | [[this memo]] | | 0x454c4544 | DELE | [[this memo]] |
+------------+----------------------+---------------+
| 0x48544150 | PATH | [[this memo]] | | 0x48544150 | PATH | [[this memo]] |
+------------+----------------------+---------------+
| 0x49415444 | DTAI | [[this memo]] | | 0x49415444 | DTAI | [[this memo]] |
+------------+----------------------+---------------+
| 0x49444152 | RADI | [[this memo]] | | 0x49444152 | RADI | [[this memo]] |
+------------+----------------------+---------------+
| 0x4b425550 | PUBK | [[this memo]] | | 0x4b425550 | PUBK | [[this memo]] |
+------------+----------------------+---------------+
| 0x5041454c | LEAP | [[this memo]] | | 0x5041454c | LEAP | [[this memo]] |
+------------+----------------------+---------------+
| 0x5044494d | MIDP | [[this memo]] | | 0x5044494d | MIDP | [[this memo]] |
+------------+----------------------+---------------+
| 0x50455253 | SREP | [[this memo]] | | 0x50455253 | SREP | [[this memo]] |
+------------+----------------------+---------------+
| 0x544e494d | MINT | [[this memo]] | | 0x544e494d | MINT | [[this memo]] |
+------------+----------------------+---------------+
| 0x544f4f52 | ROOT | [[this memo]] | | 0x544f4f52 | ROOT | [[this memo]] |
+------------+----------------------+---------------+
| 0x54524543 | CERT | [[this memo]] | | 0x54524543 | CERT | [[this memo]] |
+------------+----------------------+---------------+
| 0x5458414d | MAXT | [[this memo]] | | 0x5458414d | MAXT | [[this memo]] |
+------------+----------------------+---------------+
| 0x58444e49 | INDX | [[this memo]] | | 0x58444e49 | INDX | [[this memo]] |
+------------+----------------------+---------------+ +------------+----------------------+---------------+
Table 3: Roughtime tags.
12. Security Considerations 12. Security Considerations
Since the only supported signature scheme, Ed25519, is not quantum Since the only supported signature scheme, Ed25519, is not quantum
resistant, the Roughtime version described in this memo will not resistant, the Roughtime version described in this memo will not
survive the advent of quantum computers. survive the advent of quantum computers.
Maintaining a list of trusted servers and adjudicating violations of Maintaining a list of trusted servers and adjudicating violations of
the rules by servers is not discussed in this document and is the rules by servers is not discussed in this document and is
essential for security. Roughtime clients MUST update their view of essential for security. Roughtime clients MUST regularly update
which servers are trustworthy in order to benefit from the detection their view of which servers are trustworthy in order to benefit from
of misbehavior. the detection of misbehavior.
Validating timestamps made on different dates requires knowledge of Validating timestamps made on different dates requires knowledge of
leap seconds in order to calculate time intervals correctly. leap seconds in order to calculate time intervals correctly.
Servers carry out a significant amount of computation in response to Servers carry out a significant amount of computation in response to
clients, and thus may experience vulnerability to denial of service clients, and thus may experience vulnerability to denial of service
attacks. attacks.
This protocol does not provide any confidentiality, and given the This protocol does not provide any confidentiality. Given the nature
nature of timestamps such impact is minor. of timestamps such impact is minor.
The compromise of a PUBK's private key, even past MAXT, is a problem The compromise of a PUBK's private key, even past MAXT, is a problem
as the private key can be used to sign invalid times that are in the as the private key can be used to sign invalid times that are in the
range MINT to MAXT, and thus violate the good behavior guarantee of range MINT to MAXT, and thus violate the good behavior guarantee of
the server. the server.
Servers MUST NOT send response packets larger than the request Servers MUST NOT send response packets larger than the request
packets sent by clients, in order to prevent amplification attacks. packets sent by clients, in order to prevent amplification attacks.
13. Privacy Considerations 13. Privacy Considerations
skipping to change at page 16, line 39 skipping to change at page 19, line 9
Recommendation TF.457-2, October 1997. Recommendation TF.457-2, October 1997.
[ITU-R_TF.460-6] [ITU-R_TF.460-6]
ITU-R, "Standard-Frequency and Time-Signal Emissions", ITU-R, "Standard-Frequency and Time-Signal Emissions",
ITU-R Recommendation TF.460-6, February 2002. ITU-R Recommendation TF.460-6, February 2002.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4, Hash Standard", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4,
August 2015. August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.
14.2. Informative References 14.2. Informative References
[Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures",
2012, <https://zero-entropy.de/autokey_analysis.pdf>. 2012, <https://zero-entropy.de/autokey_analysis.pdf>.
[DelayAttacks] [DelayAttacks]
Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks
Against Time Synchronization Protocols", Against Time Synchronization Protocols",
DOI 10.1109/ISPCS.2012.6336612, 2012, DOI 10.1109/ISPCS.2012.6336612, 2012,
skipping to change at page 18, line 5 skipping to change at page 20, line 14
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 18, line 30 skipping to change at page 20, line 44
DOI 10.17487/RFC8573, June 2019, DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>. <https://www.rfc-editor.org/info/rfc8573>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>. <https://www.rfc-editor.org/info/rfc8915>.
Appendix A. Terms and Abbreviations Appendix A. Terms and Abbreviations
ASCII American Standard Code for Information Interchange ASCII American Standard Code for Information Interchange
IANA Internet Assigned Numbers Authority
JSON JavaScript Object Notation [RFC8259] IANA Internet Assigned Numbers Authority
MJD Modified Julian Date JSON JavaScript Object Notation [RFC8259]
NTP Network Time Protocol [RFC5905] MJD Modified Julian Date
NTS Network Time Security [RFC8915] NTP Network Time Protocol [RFC5905]
NTS Network Time Security [RFC8915]
TAI International Atomic Time (Temps Atomique International) TAI International Atomic Time (Temps Atomique International)
[ITU-R_TF.460-6] [ITU-R_TF.460-6]
TCP Transmission Control Protocol [RFC0793] TCP Transmission Control Protocol [RFC0793]
UDP User Datagram Protocol [RFC0768] UDP User Datagram Protocol [RFC0768]
UT Universal Time [ITU-R_TF.460-6] UT Universal Time [ITU-R_TF.460-6]
UTC Coordinated Universal Time [ITU-R_TF.460-6] UTC Coordinated Universal Time [ITU-R_TF.460-6]
Authors' Addresses Authors' Addresses
Aanchal Malhotra Aanchal Malhotra
Boston University Boston University
111 Cummington Mall 111 Cummington Mall
Boston 02215 Boston, MA 02215
USA United States of America
Email: aanchal4@bu.edu Email: aanchal4@bu.edu
Adam Langley Adam Langley
Google Google
Email: Email: agl@google.com
agl@google.com
Watson Ladd Watson Ladd
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco San Francisco, CA 94107
USA United States of America
Email: watsonbladd@gmail.com Email: watsonbladd@gmail.com
Marcus Dansarie Marcus Dansarie
Sweden
Email: marcus@dansarie.se Email: marcus@dansarie.se
URI: https://orcid.org/0000-0001-9246-0263 URI: https://orcid.org/0000-0001-9246-0263
 End of changes. 110 change blocks. 
235 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/