Re: [Ntp] Shorter NTS packets?
"Langer, Martin" <mart.langer@ostfalia.de> Thu, 09 December 2021 15:06 UTC
Return-Path: <mart.langer@ostfalia.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6553A09FB for <ntp@ietfa.amsl.com>; Thu, 9 Dec 2021 07:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S890fnic3JQH for <ntp@ietfa.amsl.com>; Thu, 9 Dec 2021 07:06:49 -0800 (PST)
Received: from mx1.sonia.de (mx1.sonia.de [141.41.1.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D45D3A09F2 for <ntp@ietf.org>; Thu, 9 Dec 2021 07:06:48 -0800 (PST)
Received: from mx1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28B191C80325 for <ntp@ietf.org>; Thu, 9 Dec 2021 16:06:43 +0100 (CET)
Received: from exchange08.resource.sonia.de (exchange08.resource.sonia.de [141.41.8.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.sonia.de (Postfix) with ESMTPS id 24FAA1C802DE for <ntp@ietf.org>; Thu, 9 Dec 2021 16:06:43 +0100 (CET)
From: "Langer, Martin" <mart.langer@ostfalia.de>
To: "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] Shorter NTS packets?
Thread-Index: AQHX7OKSf6Ov94t4L0Cka0hGjNLUwqwqQox7
Date: Thu, 09 Dec 2021 15:06:42 +0000
Message-ID: <e1c1672983304c8f9933df53a1f2ef02@ostfalia.de>
References: <YbHR69xnXYUR3NY3@localhost>
In-Reply-To: <YbHR69xnXYUR3NY3@localhost>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.41.8.54]
Content-Type: multipart/alternative; boundary="_000_e1c1672983304c8f9933df53a1f2ef02ostfaliade_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/fM_P5-8UR7f-R3nX4vrKKz8MkwA>
Subject: Re: [Ntp] Shorter NTS packets?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2021 15:06:54 -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 <ntp-bounces@ietf.org> im Auftrag von Miroslav Lichvar <mlichvar@redhat.com> Gesendet: Donnerstag, 9. Dezember 2021 10:52:43 An: ntp@ietf.org Betreff: [Ntp] Shorter NTS packets? >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
- [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Langer, Martin
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Daniel Franke
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Hal Murray
- Re: [Ntp] Shorter NTS packets? James Browning
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar