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