Network Time Protocols G. McCollum Internet-Draft Cisco Systems Intended status: Informational 28 July 2025 Expires: 29 January 2026 Time Synchronization over QUIC draft-mccollum-tsq-03 Abstract This document proposes a modern, secure, and extensible time synchronization protocol designed to operate over the QUIC transport protocol. Known as TSQ (Time Synchronization over QUIC), this protocol aims to address the limitations of traditional NTP by leveraging QUIC's encryption, widespread UDP/443 acceptance, and multiplexed stream capabilities. TSQ is designed for contemporary deployment environments, including enterprise networks, cloud-native systems, containers, and mobile devices, where traditional UDP-based NTP struggles with security, scalability, or operational reliability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components McCollum Expires 29 January 2026 [Page 1] Internet-Draft TSQ July 2025 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Security and Threat Model . . . . . . . . . . . . . . . . . . 3 5. Scalability Considerations . . . . . . . . . . . . . . . . . 3 6. Message Format (TLV) . . . . . . . . . . . . . . . . . . . . 3 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Comparison to Existing Protocols . . . . . . . . . . . . . . 4 9. QUIC Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 10. Clarification of Mobile Support . . . . . . . . . . . . . . . 5 11. Clarification of Precision Mode . . . . . . . . . . . . . . . 5 12. Explanation of Server Time Field . . . . . . . . . . . . . . 5 13. QUIC Multiplexing and Port 443 . . . . . . . . . . . . . . . 5 14. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 5 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 16. Relationship to Roughtime . . . . . . . . . . . . . . . . . . 6 17. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 17.1. Cryptographic Considerations . . . . . . . . . . . . . . 6 17.2. Packet Symmetry . . . . . . . . . . . . . . . . . . . . 7 17.3. QUIC Datagram Considerations . . . . . . . . . . . . . . 7 17.4. Session Models and State . . . . . . . . . . . . . . . . 7 17.5. Deployment Assumptions . . . . . . . . . . . . . . . . . 7 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Time synchronization is foundational to modern computing. It underpins authentication systems, log correlation, distributed transactions, and more. NTP, the current standard, was designed in a different era and brings challenges related to security, deployment compatibility, and extensibility. TSQ is proposed as a new protocol built directly on top of QUIC, leveraging its modern transport features to provide secure, authenticated, and operationally-friendly time synchronization. 2. Scope and Goals TSQ is intended to: * Provide secure and authenticated time synchronization McCollum Expires 29 January 2026 [Page 2] Internet-Draft TSQ July 2025 * Support modern deployment scenarios * Operate in environments where UDP/123 is blocked * Be extensible and future-proof * Scale for enterprise and cloud TSQ is _not_ intended to: * Replace NTP in ultra-precise or constrained devices * Replace public NTP infrastructure without optimization 3. Protocol Overview TSQ uses QUIC as its transport, establishing secure, short-lived connections. A typical exchange: 1. Client opens a QUIC connection to the TSQ server (UDP/443). 2. Client sends a TSQ Request with nonce and timestamp request. 3. Server replies with timestamps, echoed nonce, and metadata. 4. Client calculates RTT and adjusts clock accordingly. 4. Security and Threat Model TSQ relies on QUIC’s handshake for mutual authentication, confidentiality, and replay protection. Optional Ed25519 or HMAC signatures can be added if auditability is required. By default, QUIC session integrity suffices. 5. Scalability Considerations Short-lived connections, session resumption, and optional stateless design support scalability. TSQ is suitable for enterprise and cloud deployments. 6. Message Format (TLV) *TSQ Request* * Type: 0x01 * Nonce (16 bytes) McCollum Expires 29 January 2026 [Page 3] Internet-Draft TSQ July 2025 * Optional extensions *TSQ Response* * Type: 0x02 * Echoed Nonce * Server Time * Receive Timestamp * Send Timestamp * Optional metadata and signature 7. Use Cases * Cloud/container infrastructure * Mobile clients * Firewalled enterprise networks * High-precision timing visibility 8. Comparison to Existing Protocols The following table highlights key differences between traditional NTP, NTS, and the proposed TSQ protocol: +================+=====+=========+================+ | Feature | NTP | NTS | TSQ | +================+=====+=========+================+ | Transport | UDP | UDP+TLS | QUIC (UDP/443) | +----------------+-----+---------+----------------+ | Encryption | No | Yes | Always | +----------------+-----+---------+----------------+ | Extensibility | Low | Medium | High | +----------------+-----+---------+----------------+ | Mobile Support | No | No | Yes | +----------------+-----+---------+----------------+ | Precision Mode | No | No | Yes | +----------------+-----+---------+----------------+ Table 1 McCollum Expires 29 January 2026 [Page 4] Internet-Draft TSQ July 2025 9. QUIC Overview QUIC is a UDP-based transport protocol that provides multiplexed, stream-based delivery with built-in encryption and connection migration. It combines transport and cryptographic handshake layers, simplifying deployment behind firewalls. TSQ builds on QUIC to inherit its confidentiality, integrity, and path-resilience characteristics. 10. Clarification of Mobile Support Mobile support in TSQ leverages QUIC's connection ID and migration capabilities. When a mobile device changes IP addresses (e.g. Wi-Fi to LTE), the QUIC connection remains valid as long as the connection ID is preserved, enabling uninterrupted time synchronization. 11. Clarification of Precision Mode Precision Mode refers to TSQ’s optional support for fixed-length packets and constant-time processing. This reduces jitter introduced by variable processing times and packet sizes, improving accuracy in latency-sensitive environments. 12. Explanation of Server Time Field The Server Time field in TSQ responses provides a consistent reference for clients even when timestamp echoing is used. Including it explicitly simplifies validation and debugging, particularly when clock discrepancies or replay concerns are involved. 13. QUIC Multiplexing and Port 443 TSQ can coexist with other protocols over QUIC on port 443 using Application-Layer Protocol Negotiation (ALPN). This avoids conflicts and enables unified endpoint services, allowing TSQ to blend with HTTPS or other QUIC-based services on the same port. 14. Next Steps * Solicit feedback on sync behavior and design * Improve trust and crypto model * Implement prototype in QUIC * Submit official Internet-Draft if interest grows McCollum Expires 29 January 2026 [Page 5] Internet-Draft TSQ July 2025 15. Acknowledgments Thanks to contributors from the QUIC and NTP working groups for input on timing accuracy and protocol design. 16. Relationship to Roughtime Roughtime [ROUGHTIME] is a secure time authentication protocol designed to provide coarse-grained time (typically accurate within a few seconds) using cryptographic proofs. It is particularly useful in scenarios where a system needs to verify that its clock is reasonably accurate before performing sensitive operations such as certificate validation. Unlike TSQ, which aims to deliver secure and precise time synchronization suitable for continuous use in enterprise, mobile, and containerized environments, Roughtime focuses on bootstrapping trust in time from potentially untrusted states. Roughtime servers are stateless and optimized for high-throughput, low-complexity validation rather than tight synchronization. As such, TSQ and Roughtime serve complementary purposes. Roughtime may help systems establish an initial level of temporal trust, while TSQ provides ongoing synchronization over a secure and extensible transport protocol. 17. Considerations 17.1. Cryptographic Considerations TSQ relies on QUIC’s TLS 1.3-based transport layer for encryption and authentication. These cryptographic operations are not eliminated, they are performed per packet at the transport layer, but they are not duplicated at the application level for each time exchange, unlike NTS for NTP, which often executes separate AEAD operations per request (e.g. decrypt cookie, authenticate request, encrypt new cookie, sign response). While this offloading does not make QUIC “free” from a cryptographic standpoint, it enables session reuse and amortization of crypto costs over time. This can benefit TSQ in high-churn or mobile environments where maintaining lightweight, persistent connections is important. Future revisions aim to provide data-driven comparisons between TSQ and NTS in terms of cryptographic cost and performance. McCollum Expires 29 January 2026 [Page 6] Internet-Draft TSQ July 2025 17.2. Packet Symmetry To reduce timing variance, TSQ recommends matching the sizes of request and response packets. Even though QUIC encrypts and pads its payloads, maintaining symmetry at the application layer helps minimize round-trip delay bias. 17.3. QUIC Datagram Considerations TSQ may also use QUIC datagrams for lighter-weight synchronization. These are encrypted and authenticated using the same keys as QUIC streams but provide unreliable delivery. By using transport-level encryption, TSQ avoids additional per-packet cryptographic overhead at the application layer while preserving confidentiality and integrity. 17.4. Session Models and State NTS establishes session state via cookie exchanges, while TSQ inherits QUIC’s session management and connection reuse. QUIC enables stream multiplexing, bidirectional communication, and connection migration—capabilities useful in mobile and cloud-native environments. The key difference lies not in the existence of state, but in how that state is maintained and leveraged. 17.5. Deployment Assumptions TSQ is designed for modern deployment scenarios such as enterprise, mobile, and cloud networks, especially those operating behind firewalls. It is not intended to replace the global NTP stratum hierarchy or public time pools directly but may complement them in environments where UDP-based NTP has limitations. 18. References [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, . [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, . McCollum Expires 29 January 2026 [Page 7] Internet-Draft TSQ July 2025 [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, . [RFC9308] Kühlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", RFC 9308, . [ROUGHTIME] Ladd, W. and M. Dansarie, "Roughtime", Work in Progress, Internet-Draft, draft-ietf-ntp-roughtime-14, . Appendix A. IANA Considerations This document has no IANA actions. Author's Address Garrett McCollum Cisco Systems Email: gmccollu@cisco.com McCollum Expires 29 January 2026 [Page 8]