Lucas, Thanks Lucas, really appreciate the guidance. I’ll take this over to the time protocol folks and see if there’s appetite to explore a QUIC-based approach. I’ll definitely refer back to the Applicability doc and DoQ spec as I think through the transport mapping. Appreciate the pointer!
Thanks and regards, Garrett McCollum CCIE # 54886 - Security Security Business Group - Technical Leader Email: [email protected] Office: +1 (919) 574-6765 Standard Business Hours: 8:00 AM – 5:00 PM EDT (RTP, North Carolina) From: Lucas Pardue <[email protected]> Date: Thursday, July 10, 2025 at 10:36 PM To: [email protected] <[email protected]> Cc: Garrett McCollum (gmccollu) <[email protected]> Subject: Re: Proposal: TSQ – A Time Synchronization Protocol over QUIC Hi Garrett, It sounds like you're describing an idea for a new application protocol mapping. Our charter [1] says: > Specifications describing how new or existing application protocols use the > QUIC transport layer, called application protocol mappings below, need not be > specified in the QUIC WG, although they can. I'm not an expert on time protocols but that's who I suspect that might be where the heavy lifting of a document would be. So as a first port of call perhaps the NTP WG would be a better audience? We're off course happy to talk about QUIC specific things in this WG, or provide advice to other WGs. I'd recommend reading our Applicability document [2] for guidance how to use QUIC in an application protocol mapping. Good examples of how to write one are HTTP/3 [3] and DoQ [4]. Cheers Lucas [1] - https://datatracker.ietf.org/wg/quic/about/ [2] - https://datatracker.ietf.org/doc/rfc9308/ [3] - https://datatracker.ietf.org/doc/rfc9114 [4] - https://datatracker.ietf.org/doc/rfc9250 On Wed, Jul 9, 2025, at 18:33, Garrett McCollum (gmccollu) wrote: Hi All, I’m exploring an idea for a modern, secure replacement for NTP built on top of QUIC, tentatively called TSQ (Time Sync over QUIC). The idea is to use QUIC streams for timestamp exchange, leveraging its built-in encryption, NAT traversal, and multiplexing benefits. It would avoid the fragility of legacy NTP (UDP/123, no auth, clock jumps), and provide a better time sync layer for modern networks. A rough sketch: - QUIC stream carries a nonce → timestamp request - Server replies with signed timestamp, receive/send timing - Client calculates offset + RTT - Security, clock discipline, and trust model simplified Is anyone aware of prior efforts like this? Would the QUIC WG be a good venue to discuss it further or explore a draft? I’d be happy to share a more detailed draft or early prototype if there’s interest. Thanks, Garrett McCollum
