Skip to main content

IETF Last Call Review of draft-ietf-ntp-roughtime-15
review-ietf-ntp-roughtime-15-secdir-lc-reddyk-2026-01-12-00

Request Review of draft-ietf-ntp-roughtime
Requested revision No specific revision (document currently at 19)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-01-07
Requested 2025-12-17
Authors Watson Ladd , Marcus Dansarie
I-D last updated 2026-05-20 (Latest revision 2026-03-17)
Completed reviews Secdir IETF Last Call review of -15 by Tirumaleswar Reddy.K (diff)
Genart IETF Last Call review of -15 by Christer Holmberg (diff)
Tsvart IETF Last Call review of -15 by Colin Perkins (diff)
Opsdir IETF Last Call review of -15 by Nick Buraglio (diff)
Artart IETF Last Call review of -15 by John R. Levine (diff)
Httpdir IETF Last Call review of -15 by Mark Nottingham (diff)
Artart Telechat review of -17 by John R. Levine (diff)
Assignment Reviewer Tirumaleswar Reddy.K
State Completed
Request IETF Last Call review on draft-ietf-ntp-roughtime by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Be5ebaLWPvZVzpOdQkODV7LoCDk/
Reviewed revision 15 (document currently at 19)
Result Not ready
Completed 2026-01-04
review-ietf-ntp-roughtime-15-secdir-lc-reddyk-2026-01-12-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving security requirements
and considerations in IETF drafts. Comments not addressed in the last call
may be included in AD reviews during the IESG review.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Reviewer: Tirumaleswar Reddy
Review result:  Not ready

Summary:  draft-ietf-ntp-roughtime specifies Roughtime, a lightweight,
cryptographically authenticated time protocol that allows clients to obtain
time from one or more servers. It provides authenticity and freshness of
time responses and enables detection of inconsistent server behavior.

Comments below:

1) The draft specifies a single signature algorithm and provides no
mechanism to support alternative or future signature algorithms. This does
not offer cryptographic agility and complicates migration if the algorithm
is deprecated. The combination of fixed algorithm and unclear key lifecycle
management would most likely limit the protocol’s long-term security and
deployability.

2) The draft does not specify how clients are initially provisioned with
authentic server public keys, nor does it clearly state the assumed trust
model for key distribution.

3) There is no guidance on how servers rotate signing keys, how clients
learn about new keys, or how key compromise is handled.

4) The draft does not clearly explain how clients should act on detected
malfeasance (e.g., blacklisting servers, reporting, or retry behavior).

5)  It detects conflicting time responses but does not define how clients
should select or trust a time value when multiple responses are available,
for example when some server time intervals overlap while others do not.

Best Regards,
-Tiru