[Ntp] Late-stage feedback on Roughtime draft - Clarification and potential revisions needed

[[e-mail]]

Dear Aanchal, Adam, Watson, and Marcus, dear NTP WG members,

we hope you're all well. 
We apologize in advance for bringing this to your attention at such a late 
stage in the process, but there are a few points about the Roughtime draft 
that my colleague and I felt compelled to share. These thoughts were 
triggered by a recent paper [1] we read, which conveyed certain 
implications about Roughtime's capabilities that we found puzzling, such 
as "cold start" synchronization.
This paper is not the only source where we noticed these tendencies and 
implications, but demonstrates them pretty clearly.

[1] Marco Spanghero and Panos Papadimitratos
Detecting GNSS misbehavior leveraging secure heterogeneous time sources 
(
https://www.researchgate.net/publication/370594116_Detecting_GNSS_misbehavior_leveraging_secure_heterogeneous_time_sources
)

Intrigued by the paper's assertions, we delved into the draft to better 
understand the protocol's functionalities and potential advantages. 
However, the more we studied, the more we found ourselves questioning some 
elements of the draft, which appeared to diverge from the descriptions we 
had previously encountered in various talks, blog posts, and indeed, the 
aforementioned paper.

Before going into specifics, I want to stress that we appreciate the 
tremendous effort that has gone into developing Roughtime and writing this 
draft. We understand that creating a protocol and its accompanying 
documentation is a complex and time-consuming task. Our intention in 
providing this feedback is to contribute constructively to the ongoing 
work, and to help ensure that the final draft accurately reflects 
Roughtime's features, capabilities, and potential applications.

We have noted four main areas where we believe the draft (as of 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-roughtime-07) could 
benefit from further clarification and/or revision. 


1. Lack of Clarity on the Meaning of "Rough" and its Implications:
The Roughtime draft lacks clarity regarding the meaning of "rough" and its 
implications, failing to specify the degree of accuracy or imprecision it 
aims to achieve, and not highlighting potential use cases for this level 
of time synchronization. The document may inadvertently misrepresent the 
trade-offs involved, potentially leading to misconceptions about the level 
of precision and security offered by Roughtime compared to other 
protocols. Additionally, it gives the misleading impression that Roughtime 
could effectively handle a "cold start" synchronization, fostering 
incorrect expectations about its capability to solve the inherent 
chicken-and-egg problem in reliable time synchronization.

2. Lack of Description of Reporting Mechanism and its Impact:
The Roughtime draft inadequately explains its unique feature, the 
client-side cryptographic proof of server misbehavior, leaving questions 
about how this proof is generated, verified, reported, and handled. The 
draft fails to clarify how this reporting system, which seems more focused 
on accountability than accuracy, directly benefits time clients who are 
primarily interested in obtaining accurate time. Furthermore, the draft 
fails to address details such as potential abuse by malicious clients, who 
could intentionally skew their local clocks to falsely implicate servers, 
leading to potential distrust or blacklisting. 

3. Lack of Explanation of Security Model: 
Roughtime's security model, relying on a majority of servers to provide 
accurate times, lacks sufficient explanation and could be vulnerable to 
coordinated attacks. The protocol doesn't adequately address potential 
threats related to the Byzantine Generals Problem, such as botnet attacks, 
undermining its overall security integrity.

4. Insufficient Explanation of Protocol's Security Measures:
Roughtime's security measures are not clearly explained, with clients' 
time verification relying on possibly unreliable local clocks, and the 
protocol failing to prevent smaller time manipulations by servers. 
Furthermore, the accuracy of the protocol is contingent on precise radius 
estimation by servers, creating potential for errors in accepting or 
rejecting responses.
We understand that addressing this feedback may require significant 
effort, and we apologize for the late timing of these comments. We hope 
that our insights will be helpful as you continue to refine the draft, and 
we would be happy to discuss these points further if it would be 
beneficial.

Thanks for your understanding, and we look forward to your response.
(We will both be business travelling in the upcoming week, responses might 
take longer then)


Besten Gruß / Kind regards,
Kristof Teichel and Martin Langer








APPENDIX (below)
More detailed version of our feedback for the four areas.

1. Lack of Clarity on the Meaning of "Rough" and its Implications:
1.1 Lack of Clarity on the Meaning and Use Cases: 
The draft fails to clearly define what the "rough" in Roughtime means. 
Without this information, it's difficult to assess the appropriateness of 
Roughtime for different use cases. The term "rough" suggests a level of 
precision that may be less than what protocols like NTP/NTS offer, but the 
exact scale (seconds, tens of seconds, more) is not specified. 
Additionally, the draft does not highlight the potential use cases that 
would require this "rough" level of synchronization. This leaves it 
unclear who the intended users are, and whether the protocol is even 
suitable for those use cases.The draft should clear both of those points 
up.
1.2 Potential Misrepresentation of Trade-Offs: 
The draft may inadvertently give the impression that the "rough" nature of 
Roughtime is either a feature or a trade-off for a feature, such as 
enhanced security. This could lead to misconceptions, such as "NTS is less 
precise than GNSS, but more secure. Therefore, Roughtime, being even less 
precise, must be even more secure". However, this is not necessarily the 
case. The draft should clearly explain the trade-offs involved in using 
Roughtime, and how its level of precision and security compares to other 
time synchronization protocols.
1.3 Misleading Implication Regarding Cold Start Synchronization: 
The draft, along with other materials like blog posts and talks about 
Roughtime, gives the impression that Roughtime could be effectively used 
for a "cold start" synchronization of a device. This implies that 
Roughtime could help solve the chicken-and-egg problem inherent in 
reliable time synchronization: needing secure time to authenticate 
certificates and keys, but also needing those keys and certificates to 
secure time synchronization. However, Roughtime, like all other known 
protocols, cannot truly solve this fundamental issue. Allowing the 
implication that it can is misleading. It's essential for the draft to 
clarify this point and ensure that the protocol's limitations, as well as 
its capabilities, are accurately presented.

2. Reporting Mechanism and its Impact:
2.1 Inadequate Explanation of the Protocol's Unique Feature: 
The primary unique feature of Roughtime, as highlighted in the draft, is 
the client-side cryptographic proof of server malfeasance. However, the 
draft does not provide sufficient detail on how this proof is generated, 
verified, reported, or handled. As this is a critical aspect of the 
protocol (as the draft?s Section 12 ?Security Considerations? also states) 
and its main differentiator from other time synchronization protocols, the 
lack of detail leaves the utility and effectiveness of Roughtime 
uncertain. The draft should provide a comprehensive explanation of this 
feature and how it contributes to secure and reliable time 
synchronization.
2.2 Disconnect between Feature and Client Interests: 
Even with a functioning reporting system, it remains unclear how this 
system would directly benefit a time client. Clients are primarily 
interested in obtaining accurate time, not necessarily in being able to 
report servers that provide inaccurate time. While a reporting system 
could potentially deter servers from providing inaccurate time due to fear 
of being reported, this is a rather indirect and uncertain way of ensuring 
accurate time synchronization. The draft should bridge this logical gap by 
clearly demonstrating how the reporting feature directly contributes to 
the goal of accurate time synchronization.
2.3 Potential for Slanderous Reports: 
The Roughtime protocol provides clients the ability to generate reports 
that demonstrate a server gave an inaccurate time. However, this could 
potentially be abused by a malicious client. A client could intentionally 
skew its local clock to make a server's accurate time appear incorrect, 
and then generate a report claiming that the server is providing 
inaccurate time. This report, which includes a signed response from the 
server, could falsely implicate the server. Given that these reports could 
be used as a basis for distrusting or even blacklisting servers, this 
could be a serious vulnerability in the protocol. But it remains unclear, 
since the reporting system is not specified at all - the draft needs to 
address this.

3. Insufficient Explanation of Security Model:
3.1 Reliance on Multiple Servers: 
To mitigate the risk of accepting incorrect times, a client can compare 
responses from multiple Roughtime servers. However, this requires the 
client to trust that a majority of the servers it communicates with are 
providing accurate times. The draft should recognize and address this.
3.2 Vulnerability to Coordinated Attacks: 
If Roughtime's security largely depends on majority decisions, then it 
could be vulnerable to coordinated attacks, such as those from a botnet. A 
coordinated group of malicious servers could provide false time 
information, and a group of malicious monitoring clients could falsely 
report genuine servers, potentially undermining the protocol's security. 
This issue is related to the Byzantine Generals Problem, a situation where 
agreement must be reached among distributed entities that may not all be 
honest. The draft should discuss how Roughtime addresses this problem and 
what measures are in place to protect against coordinated attacks. 

4. Insufficient Explanation of Protocol's Security Measures:
4.1 Non-Cryptographic Verification: 
While the server's response is signed, the client's verification process 
depends on comparing the server's response to its own view of the current 
time, which is not inherently reliable. The draft should address this.
4.2 Client's Time Uncertainty: 
The effectiveness of Roughtime's robustness against skewed server clocks 
relies on the client's ability to compare the received time interval with 
its own local clock. However, clients might have inaccurate or unreliable 
local clocks to begin with. In such cases, it becomes challenging for the 
client to effectively judge whether the received time from a server is 
accurate or not. This uncertainty could lead to accepting incorrect times 
or rejecting valid ones, undermining the robustness of the protocol.
4.3 Server Small-Scale Misbehavior: 
If a server is intentionally providing slightly incorrect times, 
Roughtime's protocol doesn't prevent this.Minor manipulations might go 
unnoticed.
4.4 Radius Accuracy: 
The effectiveness of the protocol depends on the server accurately 
estimating the radius. If the server's radius is too small, valid 
responses might be incorrectly rejected by the client, and if the radius 
is too large, incorrect times might be accepted.


__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        [phone]
E-Mail:   [e-mail]
__________________________________________