Re: [Ntp] Shorter NTS packets?

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 <mlichvar@redhat.com> 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:
>
> 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
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp