[Git][NTPsec/ntpsec][master] 6 commits: nts.adoc: Capitalize a MUST

Matt Selsky gitlab at mg.gitlab.com
Fri Feb 8 00:26:27 UTC 2019 

Matt Selsky pushed to branch master at NTPsec / ntpsec


Commits:
bfcf2d38 by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Capitalize a MUST

- - - - -
a5b4eb27 by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Explain cipher selection

The documentation now contains a NTPHonorCipherOrder option, so this is
not TBD.

- - - - -
37aed16e by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Unsplit NTPCipherSuite

The TLS 1.2 "ciphers" vs. TLS 1.3 "ciphersuites" thing is specific to
TLS.  It does not apply to AEAD.  AFAIK, there is no built-in support
for AEAD cipher strings anyway.

- - - - -
1de1752f by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Fix the purpose of NTPHonorCipherOrder

NTPHonorCipherOrder controls the negotiation of the AEAD cipher which is
used for NTP traffic.  The cipher used for the cookie is entirely
separate and at the whim of the server.

- - - - -
dc2827a3 by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Make AEAD_AES_SIV_CMAC_256 not implicit

If the user specifies a NTPCipherSuite string, they need to include
AEAD_AES_SIV_CMAC_256 if they want it.  Otherwise, if it is implicit,
as the document previous said, this would preclude the user from
disabling AEAD_AES_SIV_CMAC_256 in the future, should that become
necessary.

- - - - -
2220ca31 by Richard Laager at 2019-02-07T18:42:59Z
nts.adoc: Add nonce discussion and limitations

- - - - -


1 changed file:

- devel/nts.adoc


Changes:

=====================================
devel/nts.adoc
=====================================
@@ -200,8 +200,8 @@ Those slots will be returned with new cookies.
 
 The AEAD algorithm used for authentication is set up to encrypt some
 data as well.  For the request, the encrypted data is empty.  For the
-response, it contains a new cookie (or cookies). AEAD also needs a nonce.
-
+response, it contains a new cookie (or cookies). AEAD also needs a nonce;
+see below for discussion and security concerns.
 
 == Configuration
 
@@ -218,11 +218,44 @@ This SHOULD be provided as an OpenSSL cipher string.
 The NTS-KE server SHOULD have a configuration parameter to specify
 its preferred AEAD algorithms for the NTPD connection in preference
 order.  This SHOULD be provided as an OpenSSL cipher string.
-AEAD_AES_SIV_CMAC_256 [RFC5297] must be supported[4.1.5]
+AEAD_AES_SIV_CMAC_256 [RFC5297] MUST be supported[4.1.5].
+
+The nonce situation has impacts on algorithm choice.  There are two ways
+to generate a nonce: randomly or as a counter.  Given the hard
+requirement that the server be stateless, the only place for the server
+to store state is in the cookie.  Clients are allowed to reuse cookies,
+so the server cannot use the cookie to store nonce state.  No matter what
+state the server stores in the cookie, if the client replays a cookie,
+the server would replay the nonce.
+
+Unless the AEAD algorithm is specifically designed to be nonce-misuse
+resistant, then reusing the nonce catastrophically breaks the security.
+For example, the AES-GCM RFC [RFC5116] says, "
+   The inadvertent reuse of the same nonce by two invocations of the GCM
+   encryption operation, with the same key, but with distinct plaintext
+   values, undermines the confidentiality of the plaintexts protected in
+   those two invocations, and undermines all of the authenticity and
+   integrity protection provided by that key.  For this reason, GCM
+   should only be used whenever nonce uniqueness can be provided with
+   assurance."
+
+So we might as well generate the nonce randomly rather than jumping
+through hoops to try to implement a counter-based nonce that will fail
+anyway under cookie reuse.  A random nonce also prevents the client from
+gaining some advantage by reusing the cookie maliciously.  But a
+randomly-generated nonce also does not _guarantee_ that nonce reuse will
+not happen.  Thus, absent contrary guidance from a cryptography expert,
+the AEAD algorithm MUST be nonce-misuse resistant.  The only current AEAD
+algorithms with this property are AEAD_AES_SIV_CMAC in 256, 384, and 512
+variants and AEAD_AES_128_GCM_SIV in 128 and 256 variants.  This can be
+verified by checking each AEAD algorithm's specification.
 
 Honoring the NTS-KE client's AEAD preference order for the NTPD
-connection is OPTIONAL[4.1.5].  How we reconcile the NTS-KE client
-and NTS-KE server preference order is TBD.
+connection is OPTIONAL[4.1.5].  The typical approach is to honor the
+client's order by default (i.e. pick the first algorithm in the client's
+list which is supported by the server), unless a configuration option has
+been set on the server to reverse that (i.e. pick the first algorithm in
+the server's list which is supported by the client).
 
 The NTS-KE server SHOULD have a configuration parameter to specify
 the TLS key, certificate, and intermediate certificate bundles.
@@ -242,8 +275,10 @@ library and the remote both support. If the remote can't cope, you
 abort.
 
 To avoid having to hand-configure ciphers offered to the remote, we
-can initially have a list of common known-good ones wired in.
-Eventually, look into how openssl-ciphers does this and autoconfigure.
+can initially have a list of common known-good ones wired in.  Eventually,
+this list should be configurable.  For the reasons discussed above in the
+server section, the client's default list of ciphers SHOULD be restricted
+to only those algorithms known to be nonce-misuse resistant.
 
 == NTS-KE Server Configuration parameters
 
@@ -279,13 +314,30 @@ TLSCipherSuite TLS1.3 cipher-spec
 ....
 
 A colon-separated cipher-spec string consisting of OpenSSL AEAD cipher
-specifications to configure the Cipher Suite for the NTS cookie.  TLS1.2
-and TLS1.3 must be specified separately. AEAD_AES_SIV_CMAC_256 is
-mandatory, and need not be specified.
+specifications to configure the cipher suite for the NTP traffic.
+
+Therefore, the server MUST restrict the list of AEAD algorithms to only
+those algorithms known to be nonce-misuse resistant.
+
+For the reasons discussed above, the server MUST limit the accepted AEAD
+algorithms in this to only those algorithms known to be nonce-misuse
+resistant.  Maybe this should be downgraded to a SHOULD, because a new
+nonce-misuse resistant algorithm could be added to OpenSSL and ntpd would
+not know about it.  If it is possible to just pass a cipher string to
+OpenSSL and let it filter the list of AEAD algorithms (as is possible with
+TLS), that makes sense.  But if the NTS-KE server implementation has to
+parse this list itself and switch-case on the value, then it would have to
+be updated for new algorithms anyway, and it makes sense to leave this at
+a MUST.
+
+If no list is specified, the default list MUST include
+AEAD_AES_SIV_CMAC_256.  However, if the user specifies a list, the server
+MUST NOT add AEAD_AES_SIV_CMAC_256 to that list implicitly, as this would
+preclude the user from disabling AEAD_AES_SIV_CMAC_256 in the future,
+should that become necessary.
 
 ....
-NTPCipherSuite TLS1.2 cipher-spec
-NTPCipherSuite TLS1.3 cipher-spec
+NTPCipherSuite cipher-spec
 ....
 
 Option to prefer the server's cipher preference order for the TLS connection.
@@ -295,7 +347,7 @@ Default on.
 TLSHonorCipherOrder on|off
 ....
 
-Option to prefer the server's cipher preference order for the cookie.
+Option to prefer the server's cipher preference order for the NTP packets.
 Default on.
 
 ....



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/b2291b01876f85edb37b7eb83a1e2b712f51bdf6...2220ca314ff12a6cf1f17ccf09123d1cfd5f09b1

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/b2291b01876f85edb37b7eb83a1e2b712f51bdf6...2220ca314ff12a6cf1f17ccf09123d1cfd5f09b1
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190208/d9d43863/attachment-0001.html>

More information about the vc mailing list