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 >
