Re: [ntpwg] Antwort: Re: NTS: DTLS and symmetric mode

Miroslav Lichvar <mlichvar@redhat.com> Thu, 03 August 2017 08:56 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807F12F24E for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Thu, 3 Aug 2017 01:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Ny0rfP9kV7GT for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Thu, 3 Aug 2017 01:56:27 -0700 (PDT)
Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id BCE62126CC4 for <ntp-archives-ahFae6za@lists.ietf.org>; Thu, 3 Aug 2017 01:56:27 -0700 (PDT)
Received: from lists.ntp.org (unknown [127.0.0.235]) by lists.ntp.org (Postfix) with ESMTP id 04BE386DB75 for <ntp-archives-ahFae6za@lists.ietf.org>; Thu, 3 Aug 2017 08:56:27 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id C9CEB86DAB4 for <ntpwg@lists.ntp.org>; Thu, 3 Aug 2017 08:56:22 +0000 (UTC)
Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mlichvar@redhat.com>) id 1ddBvS-0002QZ-FM for ntpwg@lists.ntp.org; Thu, 03 Aug 2017 08:56:22 +0000
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 mx1.redhat.com (Postfix) with ESMTPS id 287643680F; Thu, 3 Aug 2017 08:56:13 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 287643680F
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com
Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BB6F7F801; Thu, 3 Aug 2017 08:56:11 +0000 (UTC)
Date: Thu, 03 Aug 2017 10:56:10 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: dieter.sibold@ptb.de
Message-ID: <20170803085610.GE1206@localhost>
References: <707deca2-9037-c9fc-69bc-71ee80cb4c97@nwtime.org> <CAJm83bBjUU_PHhOcH4Sa7LdE2JEN3wojmXTWv_F_nnnRQz61Rw@mail.gmail.com> <c251d5c2-ae87-7c66-7b08-f3bc68680be8@nwtime.org> <CAJm83bA+vJjq74pKBJKRHbqG2W9rJi3HRU48go=cws92gx6DBw@mail.gmail.com> <20170801073854.GB2346@localhost> <OF0EDC79E2.6AA3BA5D-ONC125816F.004FDACC-C125816F.0052D03C@ptb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <OF0EDC79E2.6AA3BA5D-ONC125816F.004FDACC-C125816F.0052D03C@ptb.de>
User-Agent: Mutt/1.8.0 (2017-02-23)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 03 Aug 2017 08:56:13 +0000 (UTC)
X-SA-Exim-Connect-IP: 209.132.183.28
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: mlichvar@redhat.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] Antwort: Re: NTS: DTLS and symmetric mode
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.24
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Cc: ntpwg <ntpwg@lists.ntp.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

On Tue, Aug 01, 2017 at 05:04:32PM +0200, dieter.sibold@ptb.de wrote:
> > Von: Miroslav Lichvar <mlichvar@redhat.com>
> > Here is the list of issues I posted previously (with no response) [1]:
> > 
> > - no stateless passive mode
> > - problematic pairing of DTLS sessions
> Daniel considered this question. He provided a discussion in Sec. 4 of the 
> current NTS draft (version -09).

That clarifies some of the issues we discussed before, but it seems to
me it still assumes there can be only one NTS peer per IP address.
That wasn't the case with older authentication mechanisms (symmetric
key, autokey).

> >   - won't work with HW which can timestamp only packets on port 123
> >     (or 319)
> Yes, but the vast majority of NTP servers and clients don't use HW based 
> time stamping. Also note, that HW based time stamping is going to be 
> difficult for mode 3 and 4 packets also. This packets are protected by NTS 
> extension fields and HW time stamping NICs are not able to calculate the 
> NTS AEAD information (at least currently).

HW doesn't need to know about NTS, it can still be a SW implementation
of NTP+NTS. The problem is with receiving packets. Some HW can provide
timestamps for all received packets, but apparently in some designs
that would have a significant impact on performance, so there is a
filter to limit timestamps to PTP/NTP packets. I think there is at
least one which can be configured to timestamps packets on UDP port
123 or 319, but not other ports.

> > - won't work with future NTP extensions for delay corrections in
> >   routers/switches
> That is probably true. But I don't see the use case for this. Typically 
> you apply symmetric mode in a closed environment. If you require the 
> additional accuracy of delay corrections in router/switches you would 
> apply PTP which already provide these features. 

PTP doesn't have NTS :). Authentication is not the only reason why
people may want to prefer NTP over PTP in local networks.

Anyway, do we know if anyone is actually interested in implementing
this NTP over DTLS symmetric mode?

I'm wondering if it wouldn't be better to leave it out of the draft
and focus on that later if there is interest. It doesn't specify NTS
for broadcast mode either (which of course would be much more
difficult to do).

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg