Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Miroslav Lichvar <mlichvar@redhat.com> Tue, 01 June 2021 13:35 UTC

Return-Path: <mlichvar@redhat.com>
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 5B7D33A1845 for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 06:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level:
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 2ctiP0B5bgij for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 06:35:04 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 A80473A1846 for <ntp@ietf.org>; Tue, 1 Jun 2021 06:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622554503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S41iKPBE28/HD6/7NOc3RA6Kuozdft1LjlZ45u0pSls=; b=M5rm2kcsAWjbPVKku8MXbvFb/bdMPoxwY16bOGXogDV+3zKgUo7ZXj2IKWuSHd8gzt3iYH VECMsiC7iRb+ywMQdki3Eehkh4VSOpZQi+5gA6Q409nrMOQ4oAzMBXdC/g9I+wHWOcSdqM VegQtYPqN2XKK8OHs4hGYtwQgq3+Lt4=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-8-exWXrUemMLyS4xXMjduYQw-1; Tue, 01 Jun 2021 09:34:59 -0400
X-MC-Unique: exWXrUemMLyS4xXMjduYQw-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B2C3D1926DB3; Tue, 1 Jun 2021 13:34:57 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0168961F5E; Tue, 1 Jun 2021 13:34:56 +0000 (UTC)
Date: Tue, 1 Jun 2021 15:34:55 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Heiko Gerstung <heiko.gerstung@meinberg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YLY3f2/5k1Hjebf7@localhost>
References: <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de>
MIME-Version: 1.0
In-Reply-To: <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4il2A7NAcsUCgInINuSPOvDhEvw>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Tue, 01 Jun 2021 13:35:10 -0000

On Tue, Jun 01, 2021 at 02:48:32PM +0200, Heiko Gerstung wrote:
> > Am 01.06.21, 14:01 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>om>:
> > Can you please elaborate? My (limited) understanding of DTLS is that
> > it would address the attacks. It has a 48-bit sequence number to
> > protect against replays and client authentication comes from TLS.
> 
> I understood that you want to use DTLS to exchange the symmetric keys used to calculate the ICV of the unencrypted event messages. This unfortunately does not address the replay/amplification vulnerability of the unicast negotiation protocol itself, it just protects against replaying the DTLS messages.

The idea is that DTLS protects everything except the sync and delay
request messages. The unicast negotiation would be protected, of
course.

> I most probably know much less about DTLS than you, Miroslav. For example, I do not know whether this requires asymmetric cryptography in every message or just at the beginning in the handshake. However, I am pretty sure that DTLS can be used to securely exchange the symmetric keys instead of using TLS in the NTS-KE phase. 

DTLS is just a datagram-based version of TLS. Asymmetric crypto is
needed only on start. Performance would certainly not be an issue. I
suspect you are already reinventing some of its wheels, like the
replay protection.

> As I tried to explain earlier, our intention with this draft was to stay close to NTS4NTP to enable implementors to re-use code and allow users to combine the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other protocols and security mechanisms would do the trick as well, but I believe that the name "Network Time Security" indicates that it has a good chance of being a better fit for securing a network time sync protocol. And, according to our research and our experience regarding network time synchronization, we came to the conclusion that this is the case for unicast PTP. 

Ok, if you need as much of NTS4NTP as possible and at the same time
keep accuracy provided by hardware timestamping as is supported in
current hardware, I think the solution is simple: NTS4NTP over PTP.

You can wrap NTP messages in a PTP event message to get hardware
timestamps and keep all the benefits of NTS4NTP. It seems your plan is
to provide NTS4NTP in any case. Do you see any disadvantages?

This would be a very short draft and it would be useful even for
plain NTP without NTS. I think I'll give it a shot.

-- 
Miroslav Lichvar