Re: [TICTOC] [ntpwg] WGLC on NTS: Why not run over IPsec?

Dieter Sibold <dieter.sibold@ptb.de> Thu, 24 March 2016 10:04 UTC

Return-Path: <dieter.sibold@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB612D6CD for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 03:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 gOyKM6_qaHNQ for <tictoc@ietfa.amsl.com>; Thu, 24 Mar 2016 03:04:49 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B89612D707 for <tictoc@ietf.org>; Thu, 24 Mar 2016 03:04:39 -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 u2OA4YD7011261-u2OA4YD9011261 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 11:04:34 +0100
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id B37FC3D353; Thu, 24 Mar 2016 11:04:34 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dieter Sibold <dieter.sibold@ptb.de>
In-Reply-To: <20160323172740.GA28288@roeckx.be>
Date: Thu, 24 Mar 2016 11:04:32 +0100
Message-Id: <E3855B06-5302-41E0-AC57-E3A1C12FD4CD@ptb.de>
References: <CAJHGrrQH0Ce+UFTy6m=SrzTk0AWmBFywC88HccHy0+WG16ibdQ@mail.gmail.com> <20160323172740.GA28288@roeckx.be>
To: Kurt Roeckx <kurt@roeckx.be>
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="Apple-Mail=_4C08D1FF-FF0A-45A5-A19A-41C648BEF4E6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/ilPcHDrZUUr6Jj_zmHUdQcoajhc>
Cc: Sharon Goldberg <goldbe@cs.bu.edu>, ntpwg@lists.ntp.org, tictoc@ietf.org
Subject: Re: [TICTOC] [ntpwg] WGLC on NTS: Why not run over IPsec?
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 10:04:53 -0000

> Am 23.03.2016 um 18:27 schrieb Kurt Roeckx <kurt@roeckx.be>:
> 
> On Wed, Mar 23, 2016 at 04:01:41AM -0400, Sharon Goldberg wrote:
>> Dear WG,
>> 
>> Another question, and please forgive me if this was discussed already and I
>> missed it.
>> 
>> It would be helpful to know why NTS is not just just running over IPsec. (I
>> can see why running NTP over TLS makes little sense, since TLS runs over
>> TCP while NTP runs over UDP so everything would probably
>> break.) But NTP runs over IP. I suppose there are some performance
>> hits to using IPsec? What are they?
> 
> I think the main problem is that they don't want that many IPsec
> tunnels at the same time.  As far as I understand it, the design
> wants to avoid storing this much state information on the server
> side.  I'm not sure I agree with this design decision.
> 
> It could also use DTLS instead of TLS, which does work over UDP.

At the time we discovered that we cannot use NTP’s autokey approach we also considered to use DTLS. However at this time there has been hardly any implementation of it. Also we learned from  [1] that DTLS is not target for an application with a communication pattern like NTP. 

"Note that the requirement to create a session means that DTLS is primarily suited for long- lived “connection-oriented” protocols as opposed to to- tally connectionless ones like DNS. Connectionless proto- cols are better served by application layer object-security protocols.“  

It might be that today DTLS’ scope has broadened. 

I also want to point out that last year Florian Weimer proposed to utilize DTLS for the key exchange. We regarded his suggestion and moved the CMS based key exchange into an appendix. In the normative part of the document we specified the requirements that have to be meet during the initial phase of NTS. See 6.1.1 in https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-12 <https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-12>
The NTS for NTP draft requires that the CMS-based key exchange is to be implemented. However it allows also the implementation of an alternative key exchange, e.g. DTLS, see 4.1 in https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-04 <https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-04>


> 
> (D)TLS can already store the session on the client side, and
> give that to the server on "resumption".  But maybe that would
> require too many packets?
> 
> I'm also worried about the soundness of the crypto.  I have a
> feeling this is designed by people that don't have enough
> background to design something like this.  I think it needs to be
> looked at by several people who do.  I've asked about this before
> but nobody ever replied to it.
> 

We frequently invited people to review the documents. So did the chair of NTP’s working group. Also Kristof gave a presentation of the documents in the SAAG session of 91st IETF. 

> 
> Kurt
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> http://lists.ntp.org/listinfo/ntpwg