Re: [Ntp] Shorter NTS packets?

Daniel Franke <> Thu, 09 December 2021 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 195B23A0D89 for <>; Thu, 9 Dec 2021 07:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yJty8fclUya3 for <>; Thu, 9 Dec 2021 07:36:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A468B3A0D82 for <>; Thu, 9 Dec 2021 07:36:57 -0800 (PST)
Received: by with SMTP id 133so5377526pgc.12 for <>; Thu, 09 Dec 2021 07:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TLiVcmjJ3yzmYKGqpOGzYKr13V5CqEFjlBKh/XfniMM=; b=n/0Vuh/s4BI8hgxZAPWgT037OZkEktYMKCTT1SqcOXA2mfJ1Ejk+hKXMLs645lYNk/ 35cVN3UwB7psEFB3kc6P85MNURqrg6ahbuNBe+72uJim950H3oZ77/IA90+sPv8iH0Z7 X3X2AczH+sMZtvkuAOxfnUO+GdLOT+o15erShDhXSG6gODVg3RjrOaUlvGPCAFEDPcEZ LbAngH8W0Qgl3g76+4BQFM/UkwVVrRWF8jUj3/rjZvbJrXJKflvcviZeZWJS0JFDB6Tp I6noM4ONVVhgoysrjPQowZ0RiNkAJkSE4w+o2BfLEt6B0cbNiyzlLzvrjw0baWuop6Hf o/qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TLiVcmjJ3yzmYKGqpOGzYKr13V5CqEFjlBKh/XfniMM=; b=3Aq2us+5f0XvKJ6jyC15RV0xaUwTWXMvxkhjHQhc2jq1s2djks+CaGVf7FV6J74FZW QofVTvMxSTau3CR20WfJBMDBkOq97hLL0Sh/8vAYX9tvRMfzy0dknLZfQUJ/e4VSBrVZ DfN3/hL/fQ00olvH615ex62DFwaCAhbOlbb60V16Xsh6l3lvoKP1PIrvy1u7YgMjQkxq KfLrDPRTZRqZo5On/ALFoWcpytjxX1MEUvn3QS3vWIsBmlm/eUv//Qx4aVzxb1luDf5X g093anjAKwKK3K1ZNv5ezEfE7oUyRBRP4NdXAz1zPXU07AQHKSaggJKThCwk5lWWwGi8 Jltg==
X-Gm-Message-State: AOAM5306txRIhKp/lE1pXWycH25ihDsEN4N2GVUwsOQ+L0ILjBajSPLI pT2cQ/947D3cqVwoGhotr3wUmqBGInGQQXTpL1U=
X-Google-Smtp-Source: ABdhPJwigrOYQ7JYMYZ+y6HAwyq7yWuPrbQed/yBKzTRcnmYfsLy65x1qZEo9yLoSHgTt0g1N1OFQ40iZ/Q+hZDm9zc=
X-Received: by 2002:a05:6a00:189d:b0:4ae:da96:e13e with SMTP id x29-20020a056a00189d00b004aeda96e13emr12637471pfh.77.1639064215175; Thu, 09 Dec 2021 07:36:55 -0800 (PST)
MIME-Version: 1.0
References: <YbHR69xnXYUR3NY3@localhost>
In-Reply-To: <YbHR69xnXYUR3NY3@localhost>
From: Daniel Franke <>
Date: Thu, 09 Dec 2021 10:36:44 -0500
Message-ID: <>
To: Miroslav Lichvar <>
Cc: NTP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Ntp] Shorter NTS packets?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Dec 2021 15:37:02 -0000

If I had to make some changes to NTS to shave a few bytes of packet
sizes, the changes I'd make would be:

1. Use AES-GCM-SIV instead of AES-SIV, which halves key sizes for any
given security level.
2. Shorten the unique identifier from 32 bytes to 16. Our choice of 32
was *very* conservative and 16 would be basically fine.
3. Add an extra KDF step, so that we export a common pre-key from TLS
and then derive the C2S and S2C from that. Then the pre-key can go
into the cookie so it only has to carry one key rather than two (I
think Scott Fluhrer suggested this at some point).

#1 can be implemented today. The other two are backward incompatible
so unless they can produce some really night-and-day difference in
packet deliverability they'd best wait for NTPv5.

On Thu, Dec 9, 2021 at 4:53 AM Miroslav Lichvar <> wrote:
> >From the discussion about the alternative port it looks like we might
> be stuck with the UDP port 123 forever.
> There is one relatively simple thing we could potentially do to make
> NTS more reliable without horribly wasting bandwidth. We could make
> the Uniq ID extension field optional in some common cases. That would
> save 36 octets and make the typical NTPv4+NTS packet short enough to
> not be impacted by the length-specific filtering that was described in
> this post:
> The Uniq ID field was added to NTS to avoid any assumptions about
> NTP's susceptibility to replay attacks. However, if we specify some
> requirements for NTP, the Uniq ID could be unnecessary. Support
> for this feature could be negotiated over NTS-KE to avoid
> incompatibilities with existing server implementations following
> RFC 8915, which requires the Uniq ID to be always present.
> The NTP header has the transmit timestamp field (64 bits). It can be
> fully randomized (as was proposed in the data minimization draft). The
> validity of the server NTS key encrypting cookies can be limited (e.g.
> to 1 week) and also the rate of NTP requests can be limited (e.g. to 1
> per second). Clients that need to send requests at a higher rate are
> likely synchronizing over local network, where the filtering is not
> happening, and they could still use the Uniq ID field as before.
> Together these limits limit the number of packets authenticated by a
> C2S/S2C key. With the 1 week / 1s example that's 604800 packets. If
> I'm calculating right that's about 1 in 100 million chance of a
> collision per key.
> If that is not good enough, the transmit timestamp could be used as a
> counter, possibly encrypted to not break the privacy-protecting
> property of NTS. This would require the client to be careful with how
> it saves the NTS keys and cookies to not reuse a transmit timestamp
> after restart, etc.
> Does this make sense?
> --
> Miroslav Lichvar
> _______________________________________________
> ntp mailing list