Subject: [Ntp] Shorter NTS packets?

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 9 Dec 2021 10:52:43 +0100

>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:

https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/

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

---

From: "Langer, Martin" <[email-masked]>
Date: Thu, 9 Dec 2021 15:06:42 +0000

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.

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

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.

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.

best regards,

Martin

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

________________________________
Von: ntp <[email-masked]> im Auftrag von Miroslav Lichvar <[email-masked]>
Gesendet: Donnerstag, 9. Dezember 2021 10:52:43
An: [email-masked]
Betreff: [Ntp] Shorter NTS packets?

Does this make sense?

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 9 Dec 2021 16:35:50 +0100

> 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 t…

Those are less common and would need to always be padded.

>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

---

From: Daniel Franke <[email-masked]>
Date: Thu, 9 Dec 2021 10:36:44 -0500

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.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 9 Dec 2021 16:47:47 +0100

> think Scott Fluhrer suggested this at some point).

All three sound good to me.
> packet deliverability they'd best wait for NTPv5.

We need to save at least 32 octets. With two halved keys in the cookie
that is exactly right?

Thanks,

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Thu, 09 Dec 2021 13:57:46 -0800

How much of the problem will shorter packets solve?

NTS-KE includes a port number.  Can each server just pick
a local port?

---

From: James Browning <[email-masked]>
Date: Fri, 10 Dec 2021 08:00:00 -0800

> NTS-KE includes a port number.  Can each server just pick

I would jokingly suggest udp port 4460, at least until the PHBs have it
hard blocked.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 13 Dec 2021 10:35:14 +0100

> How much of the problem will shorter packets solve?

In cases where the network blocks all NTP messages of >=204 bytes,
NTS didn't work at all. With shorter messages it should work well
until a packet is dropped for some other reason and the client
requests two or more cookies. When the client runs out of cookies, it
will restart NTS-KE and work again until a packet is dropped.

In cases where the network blocks all NTP messages between 204 and 452
bytes, NTS worked only once every four requests. With shorter messages
it should work well until a packet is dropped. Then it won't get a
response until it requests four or more cookies. Maybe clients could
implement some heuristic to detect this case and go straight from 1 to
4 cookies.

> NTS-KE includes a port number.  Can each server just pick

Yes, that is possible. The problem is that different servers could be
using different ports and the ports might be blocked in a local
firewall, so users would need to ask their admins to unblock them to
get NTS working.

Ideally, there would be only one port other than 123 and NTS-KE
servers would provide both ports to the clients at the same time, so
clients behind restrictive firewalls can still use the port 123 as
before.

The Port Negotiation NTS-KE record can contain only one port, but
it seems there can be multiple records of this type in a single NTS-KE
message. This should be added to the alternative-port draft if there
is a chance it will move forward.

-- 
Miroslav Lichvar