Re: [TICTOC] [ntpwg] Cipher suites for NTS?

Danny Mayer <mayer@pdmconsulting.net> Mon, 28 March 2016 16:23 UTC

Return-Path: <mayer@pdmconsulting.net>
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 9802B12DB8A for <tictoc@ietfa.amsl.com>; Mon, 28 Mar 2016 09:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bLPeh7aHzOQ9 for <tictoc@ietfa.amsl.com>; Mon, 28 Mar 2016 09:23:52 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9678B12DB74 for <tictoc@ietf.org>; Mon, 28 Mar 2016 09:23:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 195BBB82D for <tictoc@ietf.org>; Mon, 28 Mar 2016 16:23:52 +0000 (UTC)
Received: from [10.2.184.134] (unknown [198.22.153.130]) by chessie.everett.org (Postfix) with ESMTPSA id BACBEB80E; Mon, 28 Mar 2016 16:23:50 +0000 (UTC)
References: <CAMbs7kvo80z0vVd5WvCkj876mEbUO8cu-Op6sYOGVxU9ykgFEg@mail.gmail.com>
To: Aanchal Malhotra <aanchal4@bu.edu>, ntpwg@lists.ntp.org, "tictoc@ietf.org" <tictoc@ietf.org>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <56F95A95.3000105@pdmconsulting.net>
Date: Mon, 28 Mar 2016 12:23:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAMbs7kvo80z0vVd5WvCkj876mEbUO8cu-Op6sYOGVxU9ykgFEg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Mon Mar 28 16:23:51 2016
X-DSPAM-Confidence: 1.0000
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: 7205,56f95a97829938278752509
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/aAK5B1e183RQqHqpkYs9IaVoOR0>
Subject: Re: [TICTOC] [ntpwg] Cipher suites for NTS?
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mayer@pdmconsulting.net
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: Mon, 28 Mar 2016 16:23:55 -0000

On 3/26/2016 2:29 PM, Aanchal Malhotra wrote:
> Hey All,
> 
> From implementation point of view AFAWK, [1], [2] does not explicitly
> mention the  * cipher suites * to be used in NTS. [1] mentions the
> following:
> /
> /
> /*Â /The server MUST NOT include HMAC with a SHA-1 or weaker algorithms*
> /*Â /The server MUST include HMAC with SHA-256 or stronger algorithms */Â /
> /
> /
> We believe that the NTS draft should be more specific/explicit about the
> cipher suites that should be used. Both for authenticating timing
> requests and for the KE.   This is a standard practice: TLS and DNSSEC
> both specify their cipher suites in their drafts.  (For
> example, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, etc) 
> 
>        
> 
> It is not a good idea to leave this up to implementors, because it leads
> to interoperability issues (like those that have plagued IPsec [3]).  
> 
> For instance the language above says "SHA-256 OR stronger".  What if
> one  vendor decides to implement HMAC-SHA-256 and another HMAC-SHA3? 
> Both implementations satisfy the spec but the implementations will not
> interoperate.   
> 
> Section 8.1 of the TLS1.3 draft gives a good example of how this could
> be done [4]. Â  All ciphersuites that MUST or SHOULD or MAY be used are
> specified. 
> 
> This is also a security issue. Various attacks on older versions of
> protocols like TLS [5] resulted from the inclusion of weak crypto
> primitives.  This has lead the community to drop several cipher suites
> in TLS v 1.3 [6].   
> 
> Since we are trying to build NTP security from scratch we should be wary
> about what crypto we want to use!
> 

We have to be careful here. I agree that at least some  cipher suites
should be specified as a minimal subset in the draft but we also need
flexibility as new ciphers come out and older ones are found to be
vunerable. Otherwise we will need to create new RFC's to update the RFC
for either of these scenarios. I'm sure that there are other
implementations that have run into this problem and we should see how
they handle it.

Danny

> Thanks,
> Aanchal.
> 
> [1]Â http://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-05.txt
> [2]Â https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-13
> [3]Â http://dx.doi.org/10.1109/ICCOMM.2010.5509093
> [4]Â https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-8
> [4]Â https://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf
> [5]Â https://www.ietf.org/mail-archive/web/tls/current/msg11621.html
> 
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg@lists.ntp.org
> http://lists.ntp.org/listinfo/ntpwg
>