Re: [Ntp] Shorter NTS packets?

Miroslav Lichvar <> Thu, 09 December 2021 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98A6D3A0D84 for <>; Thu, 9 Dec 2021 07:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WyiialOg31ag for <>; Thu, 9 Dec 2021 07:35:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86A723A0D80 for <>; Thu, 9 Dec 2021 07:35:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1639064155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u6sD70cPYO3N9a39J+7mLRU4pMKpccuqA19EoasP5ps=; b=AL8ft1hYCYqIItAunejabhcJmYky/Kj39ifHyAtpjK1h03VvV3TXd/DBljwPvEwhnIdiEY VeQkKJgTgLmvm86IJjr9N06AULP2APdRtQa3MkYWuRDT9Qzbip7iH1WVzyiQiQxEYAawfx 4x/skCfWKbnqCzeA9BjSgnfiPF8i9bk=
Received: from ( []) by with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-390-IFQlo1PXP_eeYcyQOeg27g-1; Thu, 09 Dec 2021 10:35:53 -0500
X-MC-Unique: IFQlo1PXP_eeYcyQOeg27g-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 443805F9D3 for <>; Thu, 9 Dec 2021 15:35:52 +0000 (UTC)
Received: from localhost (unknown []) by (Postfix) with ESMTPS id BEE9E4DA21 for <>; Thu, 9 Dec 2021 15:35:51 +0000 (UTC)
Date: Thu, 09 Dec 2021 16:35:50 +0100
From: Miroslav Lichvar <>
Message-ID: <YbIiVu6RHrKvQ2L3@localhost>
References: <YbHR69xnXYUR3NY3@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
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:35:59 -0000

On Thu, Dec 09, 2021 at 03:06:42PM +0000, Langer, Martin wrote:
> Hello Miroslav,
> I think it will not work well. I understand you and basically it is an interesting idea. But there are some problems from my point of view:
> 1. you would outsource a NTS security property to NTP to reduce the amount of data. It seems more like a work-around and would not be a good protocol design.

Yes, it is a workaround for the NTP filtering implemented in the
Internet. We are desperate here. The only other option seems to be
padding of NTP messages to 456 octets, where the length-specific
filtering stops. Would you prefer that?

> 2. if the client requests cookies and uses placeholders, the NTP message will still grow. So it would not solve the problem cleanly.

The idea is to optimize for the typical length with one cookie
encrypted with the shorter AES key. IIRC in all server implementations
the cookie is 100 or 104 octets long. That puts the NTP message length
4-8 octets below the filtering threshold of 204 octets.

> 3. the size of the cookie depends on the AEAD algorithm. Depending on a 256- or 512-bit key, the size grows up to 64 bytes per cookie. Also consider that the server always sends a fresh cookie to the client to ensure unlinkability.

Those are less common and would need to always be padded.
> According to the measurements, the frame size of an unsecured NTP packet is around 90 bytes and for NTS secured packets around 270-920 bytes (see here: I hope I could help a bit.

>From what I have seen in my tests, the filters are dropping NTP
messages that have the UDP payload of 204-452 octets. If we cannot get
below that, we will need to pad to 456 octets.

Miroslav Lichvar