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 > [email protected] > http://lists.ntp.org/listinfo/ntpwg > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
