IETF Logo Mail Archive

[Ntp] NTS4UPTP draft

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 02 June 2021 11:28 UTC

Return-Path: <heiko.gerstung@meinberg.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 E714F3A3FA3 for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 04:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
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 rc5arRHpqpkI for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 04:28:41 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B512F3A3FA1 for <ntp@ietf.org>; Wed, 2 Jun 2021 04:28:40 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 9DB1F71C0918 for <ntp@ietf.org>; Wed, 2 Jun 2021 13:28:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622633318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=hXD0+zLdQVMKlGqNz29TyelOvDWHSIeVjjXlwu60LGk=; b=FVNslyjK3kxbFxY1sYjf0TbKbBrlWe60FiunP+8lDF/pmMNSrcIa9rtRMDpN8L3DcKN2c7 9CuRyMsQlskeWkBKrtI+7VzsXk+kEOSQxLlqTh2VMXUCO8RT818QzsOnYrJ/EEXsUpCcdQ 4BVyYJSfmjijqStZ1LEqsY1QZ9EGn/mo6Z1DjcR8qE4cCMkYV6dXyWMiQHlZS1QFlGESFi +gsXIxf9RLiNgg5f6f2ZVwdCzvHJGgB+VrFbHNGa6CrJoTTyh0eSFGdwo/0DFkR1Z2P7Wp 6MHy37RHh06Ogaf3TVEM1bsu4iBbf3fGas0XK54puANELTLuGFXCnrTUxgW8sA==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS for <ntp@ietf.org>; Wed, 2 Jun 2021 13:28:38 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Wed, 02 Jun 2021 13:28:33 +0200
Message-ID: <C3693A60-E1A0-4570-91C3-876EB584B468@meinberg.de>
Thread-Topic: NTS4UPTP draft
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+Nzc3YzJlM2FkNGYwMmM3ZQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: NTP WG <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----788D5705962ED2A91AE4C2817CB2AC89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/3UER_pkPYE1FoSiftc-6reWPQsQ>
Subject: [Ntp] NTS4UPTP draft
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: Wed, 02 Jun 2021 11:28:46 -0000

So far the feedback regarding our draft is more or less trying to make the point that
instead of securing the currently unsecure protocol B, users should better change the protocol so that it looks almost like secure protocol A
try to use parts of protocol B to enhance protocol A
use protocol A to establish a secure error boundary for protocol B but do not care for all the other possible attack vectors of protocol A. 
 

Apologies for oversimplifying this, but I believe I explained in detail why none of these three approaches is as good as securing protocol B. 

 

I read a few times that other WG members are agreeing that PTP needs to be secured. NTS4UPTP is trying to deliver this for the unicast mode of PTP. Given the experience you went through with NTS4NTP I believe it is a sensible approach to divide the job of securing the two different variants of PTP into two drafts. This will enable us to get to a point where we can secure at least unicast PTP a lot faster compared with one big draft that is trying to cover both unicast and multicast. It is clear that you need two different approaches for those two quite different variants and I propose to do this in two drafts instead of one big draft with two parts. 

 

Regards,

   Heiko

 


-- 

Heiko Gerstung 

Managing Director 

 

MEINBERG® Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone: +49 (0)5281 9309-404 

Fax: +49 (0)5281 9309-9404 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

heiko.gerstung@meinberg.de

Web: 

Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com

 

Do not miss our Time Synchronization Blog: 

https://blog.meinbergglobal.com

 

Connect via LinkedIn: 

https://www.linkedin.com/in/heikogerstung

v2.23.0 | Report a Bug | By Email