Subject: [TICTOC] Cipher suites for NTS?

From: Aanchal Malhotra <[email-masked]>
Date: Sat, 26 Mar 2016 14:29:54 -0400

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!

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

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Mar 2016 12:23:49 -0400

On 3/26/2016 2:29 PM, Aanchal Malhotra wrote:
> 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 */Â /
> /
> /
> 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.Â 
> 
> primitives.Â  This has lead the community to drop several cipher suites
> in TLS v 1.3 [6].Â Â Â 
> 

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
> [email-masked]
> http://lists.ntp.org/listinfo/ntpwg
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Mar 2016 16:04:59 -0400

Danny

---

From: Hal Murray <[email-masked]>
Date: Mon, 28 Mar 2016 21:54:57 -0700

[email-masked] said:
> 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. 

Is there any group in the IETF keeping track of which cyphers are good/weak?

It would be nice if there were something like the assigned numbers role, but 
this is more complicated that just assigning and keeping track of what has 
been assigned.

-- 
These are my opinions.  I hate spam.

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 29 Mar 2016 04:46:27 -0400

On Tuesday, March 29, 2016, Hal Murray <[email-masked]> wrote:

>
> [email-masked] <javascript:;> said:
> should
>  I think the CFRG is the right place to go. If not, I'm sure they can
point to the right place.

https://datatracker.ietf.org/rg/cfrg/charter/

> been

Thanks.
Sharon

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe