Re: [Ntp] [NTP] Using NTS for other negotiations (WAS: No more options for NTP)

Miroslav Lichvar <mlichvar@redhat.com> Tue, 16 April 2019 08:21 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 59FF6120356 for <ntp@ietfa.amsl.com>; Tue, 16 Apr 2019 01:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pywTJasvnKZa for <ntp@ietfa.amsl.com>; Tue, 16 Apr 2019 01:21:31 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2992E120354 for <ntp@ietf.org>; Tue, 16 Apr 2019 01:21:31 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A43FD308793A; Tue, 16 Apr 2019 08:21:30 +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 CD0DD6013B; Tue, 16 Apr 2019 08:21:29 +0000 (UTC)
Date: Tue, 16 Apr 2019 10:21:28 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: kristof.teichel@ptb.de
Cc: Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>
Message-ID: <20190416082128.GJ28203@localhost>
References: <CACsn0c=rWPFu5Y-EkJCyqZG56nrniYM+kGmxrgTDkyaR3TBQ_g@mail.gmail.com> <OFCEF6F67F.7D13AC6D-ONC12583DE.0025CC54-C12583DE.00276987@ptb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFCEF6F67F.7D13AC6D-ONC12583DE.0025CC54-C12583DE.00276987@ptb.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 16 Apr 2019 08:21:30 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/tUg2FFBgWYnmxKjGlItb2y_Pfv4>
Subject: Re: [Ntp] [NTP] Using NTS for other negotiations (WAS: No more options for NTP)
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, 16 Apr 2019 08:21:32 -0000

On Tue, Apr 16, 2019 at 09:10:53AM +0200, kristof.teichel@ptb.de wrote:
> Overall though, I wish there was more discussion on this proposal (I have 
> seen zero, have I missed anything?). 
> If people disagree, stated disagreement seems more useful that silence.
> But as I hinted at, perhaps the lack of discussion is related to the 
> open-endedness of the suggestion?

It's not very clear to me what would be the advantage of not using NTS
after the KE. If the client is complex enough to support TLS, why not
just authenticate the packets? Is an NTS server (e.g. returned in the
server negotiation record) actually required to respond to requests
not authenticated by NTS?

I suspect we would need to distinguish between NTP and NTP+NTS as next
protocols. The plain NTP protocol could be specified in a separate
draft, but in the NTS-for-NTP draft the next protocol #0 would need to
be renamed to something more specific.

-- 
Miroslav Lichvar