IETF Logo Mail Archive

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

kristof.teichel@ptb.de Tue, 16 April 2019 07:10 UTC

Return-Path: <kristof.teichel@ptb.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 AE0E6120147 for <ntp@ietfa.amsl.com>; Tue, 16 Apr 2019 00:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qlRK3zU6syMh for <ntp@ietfa.amsl.com>; Tue, 16 Apr 2019 00:10:35 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (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 DA64F120134 for <ntp@ietf.org>; Tue, 16 Apr 2019 00:10:34 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id x3G7AV1P012745-x3G7AV1R012745 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL); Tue, 16 Apr 2019 09:10:31 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 176017B2647; Tue, 16 Apr 2019 09:10:31 +0200 (CEST)
In-Reply-To: <CACsn0c=rWPFu5Y-EkJCyqZG56nrniYM+kGmxrgTDkyaR3TBQ_g@mail.gmail.com>
References: <CACsn0c=rWPFu5Y-EkJCyqZG56nrniYM+kGmxrgTDkyaR3TBQ_g@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: NTP WG <ntp@ietf.org>
MIME-Version: 1.0
Message-ID: <OFCEF6F67F.7D13AC6D-ONC12583DE.0025CC54-C12583DE.00276987@ptb.de>
From: kristof.teichel@ptb.de
Date: Tue, 16 Apr 2019 09:10:53 +0200
Content-Type: multipart/alternative; boundary="=_alternative 00276987C12583DE_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/LDuh7z-8FHG38heipX_GJHXvKYc>
Subject: [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 07:10:39 -0000

Hey all, hey Watson,

I can't speak for everyone of course, but personally, I felt that I 
couldn't comment on the suggestion because I didn't feel I understood 
enough of what it entailed.
Would you care to elaborate a bit on how you propose this would  work?

On the issues I think I understood enough to comment:
- End the use of all non-EF MACs: I agree that use of EF-MACs is 
preferable, but I don't know that just forbidding use of the non-EF MAC 
fixes everything (and I'm unsure what document to even place such a 
regulation in)
- Using NTS (-KE) for any and all capability negotiation: I agree insofar 
that it is preferable over using potentially unsecured fields for this 
(because unsecured negotiation seems like a bad idea generally), but am 
not convinced that this is a good issue for normative language. For one, 
it would seem to kill the option to use anything other than NTS forever 
(at least without first using NTS to communicate that one wishes to use an 
alternative to NTS)

One concrete question: In your comment about a v5, what exactly is the 
"that" that you propose to negotiate via NTS?

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?


Best regards,
Kristof





Von:    "Watson Ladd" <watsonbladd@gmail.com>
An:     "NTP WG" <ntp@ietf.org>
Datum:  06.04.2019 18:08
Betreff:        [Ntp] No more options for NTP
Gesendet von:   "ntp" <ntp-bounces@ietf.org>



Dear all,

This might be a terrible idea, but now that we have NTS-KE with protocol 
negotiation I propose we use that for all capability negotiation to 
encourage adoption of NTS and to avoid the issues with NTP extensions.. 
Also kill the MAC. 

If we want a v5 I think that should be negotiated via NTS for flexibility.

Sincerely,
Watson_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email