Re: [Ntp] Shorter NTS packets?

[Miroslav Lichvar <[e-mail]>]

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: https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/). 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