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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 03 June 2021 07:31 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 D1EE93A2E24 for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 00:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_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 ag6-A1LeqAqp for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 00:31:48 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.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 9015B3A2E22 for <ntp@ietf.org>; Thu, 3 Jun 2021 00:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622705506; 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=D/x/JDwiePbz+Fb48rjRkPbj4P8W0nkMTEbpR66dExM=; b=U5jNVhhza1Z1bwon2j6cH4U5WqsJZtGzlIB2/YZL+UC5wgjwpT6J6am2r9ELI6nKyEpoZz IkLxquibpg/WfSbisu4HMMvGN1Pd3a1XNwpS4aTwVDX+PgO+x88l7bKvGW080kgMy52k5D 9kqNQJTPQjnKGV2rpLP/Y19CmQd56EQ=
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-333-FCuA30CyPVSZjI5aeQBlMw-1; Thu, 03 Jun 2021 03:31:45 -0400
X-MC-Unique: FCuA30CyPVSZjI5aeQBlMw-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3B15C107ACCD; Thu, 3 Jun 2021 07:31:44 +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 8A57160BE5; Thu, 3 Jun 2021 07:31:42 +0000 (UTC)
Date: Thu, 3 Jun 2021 09:31:41 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YLiFXYPBOCIsCHDq@localhost>
References: <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de> <YLeFyqZp6bZY9nY9@localhost> <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de>
MIME-Version: 1.0
In-Reply-To: <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
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/vBQEtil-zZgVsY8uU3VjncWYZbI>
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: Thu, 03 Jun 2021 07:31:51 -0000

On Wed, Jun 02, 2021 at 06:12:28PM +0200, Heiko Gerstung wrote:
> Well, I tried to describe how it compares to all the alternatives that you and others brought up. Please excuse my confusion, but I am not sure how to proceed from here. I was told numerous times in the past that if I wanted other people to discuss a proposal of mine, then I should come up with a draft. This is exactly what I did with NTS4UPTP.

I'm glad you wrote the draft and we can discuss it.

> But instead of discussing my proposal, people start to propose alternative approaches (by mentioning them in a sentence or two, most of the time claim that this alternative is either already available or requires only a very short and compact document to describe it and matches or exceeds the security gain of our proposal). 

I think that's expected. People try to convince you their ideas are
better and you try to convince them they are not, or accept their
suggestions and rework your draft.

NTS4NTP took many years to form. IIRC it was redesigned three times
from scratch. As we seem to agree, PTP is nothing like the
client/server NTP mode that NTS4NTP protects and cannot be reused as
a whole. I hope you didn't expect this would go smoothly right with
the first submitted proposal.

I think there are basically three different issues discussed:
- Does it make sense for PTP to have a public-key based
  authentication?
- Does it make sense for unicast PTP to have something different than
  the rest of PTP?
- Does it make sense to reuse something from NTS4NTP?

> The first question was why not using MACsec or IPsec. I explained that it will not work because of the loss of the hardware timestamping capabilities. 

That's ok, but it needs to be explained in the draft as those are
solutions mentioned in IEEE1588.

> * DTLS: Asymmetric cryptography would have to be required to be carried out by every PTP server separately for each client (even if this happens only once at the beginning to initialize the DTLS communication). This requires a major modification to the PTP software on the server side and is also requiring more processing power on each PTP instance

I didn't realize this was a requirement. I think with (D)TLS you can
move the session between servers to avoid the slow crypto. I hope
someone who actually understands DTLS will correct me if I'm wrong. A
new TLV could be introduced to tell the client to move a different
server and the client would try to resume the session there. An
advantage over your proposal is that it could do that on each unicast
renewal and not only when the cookie expires, so it could be more
dynamic.

> * DTLS: would require to protect delay responses and announce messages from the server (in the packet transmission phase)
> * NTS4UPTP: only requires to use the integrated PTP security mechanism in phase 3 for all message types

I don't see that as a disadvantage.

> Not sure if this is more like what you would like to see from me in regards to a comparison. 

Yes, that's great and I'd like to see other people comment on those
points.

> At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol.

Having NTS in the name is not the main concern for me.

It's the use of NTS-KE and NTS cookies that doesn't make much sense to
me. It's possible I missed some important point. In NTS4NTP cookies
are meant to offload the server state to the client, so it can be
stateless, but in unicast PTP you already have to keep some
client-specific state, so why would you need to offload some part of
the state?

> I do not think that this is reasonable, it has been mentioned numerous times now that there are quite a number of users operating both NTP and PTP sync infrastructure in parallel and I am still convinced they appreciate to be able to set up one NTS-KE server infrastructure that handles both NTS4NTP and our proposal. And: ee wanted to use the latest and greatest key exchange protocol that has been designed by security experts and time sync specialists. 

The key exchange comes from TLS. You don't need NTS-KE for that.
Sharing one port with NTP and PTP might have some advantages, but I
suspect it's more likely that people will want to use two different
implementations that cannot share the port.

-- 
Miroslav Lichvar