docs: remove extra security policy item (aws#4248)

docs/USAGE-GUIDE.md

@@ -167,7 +167,7 @@ s2n-tls provides multiple different methods to get the TLS protocol version of t
 `s2n_config` objects are used to change the default settings of a s2n-tls connection. Use `s2n_config_new()` to create a new config object. To associate a config with a connection call `s2n_connection_set_config()`. A config should not be altered once it is associated with a connection as this will produce undefined behavior. It is not necessary to create a config object per connection; one config object should be used for many connections. Call `s2n_config_free()` to free the object when no longer needed. _Only_ free the config object when all connections using it have been freed.
 
 Calling `s2n_config_new()` can have a performance cost during config creation due to loading
-default system certificates into the trust store (see [Configuring the Trust Store](#configuring-the-trust-store)). 
+default system certificates into the trust store (see [Configuring the Trust Store](#configuring-the-trust-store)).
 For increased performance, use `s2n_config_new_minimal()` when system certificates are not needed
 for certificate validation.
 
@@ -218,12 +218,10 @@ The following chart maps the security policy version to protocol version and cip
 The "default", "default_tls13", and "default_fips" versions are special in that they will be updated with future s2n-tls changes and ciphersuites and protocol versions may be added and removed, or their internal order of preference might change. Numbered versions are fixed and will never change.
 In general, customers prefer to use numbered versions for production use cases to prevent impact from library updates.
 
-"20230317" offers more limited but more secure options than "default". It only supports TLS1.2 and TLS1.3 and is FIPS compliant. Choose this policy if you don't need or want to support less secure legacy options like TLS1.1 or SHA1.
+"20230317" is a FIPS compliant policy. It offers more limited but more secure options than "default". It only supports TLS1.2 and TLS1.3. Consider this policy if you plan to enable FIPS mode or don't need or want to support less secure legacy options like TLS1.1 or SHA1.
 
 "20160411" follows the same general preference order as "default". The main difference is it has a CBC cipher suite at the top. This is to accommodate certain Java clients that have poor GCM implementations. Users of s2n-tls who have found GCM to be hurting performance for their clients should consider this version.
 
-"20170405" is a FIPS compliant cipher suite preference list based on approved algorithms in the [FIPS 140-2 Annex A](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf). Similarly to "20160411", this preference list has CBC cipher suites at the top to accommodate certain Java clients. Users of s2n-tls who plan to enable FIPS mode should consider this version.
-
 "rfc9151" is derived from [Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3](https://datatracker.ietf.org/doc/html/rfc9151). This policy restricts the algorithms allowed for signatures on certificates in the certificate chain to RSA or ECDSA with sha384, which may require you to update your certificates.
 
 s2n-tls does not expose an API to control the order of preference for each ciphersuite or protocol version. s2n-tls follows the following order:
@@ -345,7 +343,7 @@ blocks the thread while waiting for more IO. In non-blocking mode, multiple conn
 can make progress by returning control while waiting for more IO using methods like
 [`poll`](https://linux.die.net/man/2/poll) or [`select`](https://linux.die.net/man/2/select).
 
-To use s2n-tls in non-blocking mode, set the underlying file descriptors as non-blocking. 
+To use s2n-tls in non-blocking mode, set the underlying file descriptors as non-blocking.
 For example:
 ```c
 int flags = fcntl(fd, F_GETFL, 0);
@@ -388,7 +386,7 @@ After the TLS handshake, an application can send and receive encrypted data.
 Although most s2n-tls APIs are not thread-safe, `s2n_send()` and `s2n_recv()`
 may be called simultaneously from two different threads. This means that an
 application may have one thread calling `s2n_send()` and one thread calling `s2n_recv()`,
-but NOT multiple threads calling `s2n_recv()` or multiple threads calling `s2n_send()`. 
+but NOT multiple threads calling `s2n_recv()` or multiple threads calling `s2n_send()`.
 
 Even if an application only intends to send data or only intends to receive data,
 it should implement both send and receive in order to handle alerts and post-handshake
@@ -447,7 +445,7 @@ socket, `s2n_recv()` will return `S2N_FAILURE`, and `s2n_error_get_type()` will
 `S2N_ERR_T_BLOCKED`. To ensure that all data on the socket is properly received, applications
 should continue calling `s2n_recv()` until it returns an `S2N_ERR_T_BLOCKED` error. After an
 `S2N_ERR_T_BLOCKED` error is returned, applications should call `s2n_recv()` again only after the
-socket has received more data. This can be determined by using methods like 
+socket has received more data. This can be determined by using methods like
 [`poll`](https://linux.die.net/man/2/poll) or [`select`](https://linux.die.net/man/2/select).
 
 Unlike OpenSSL, repeated calls to `s2n_recv()` should not duplicate the original parameters,
@@ -518,7 +516,7 @@ the connection or closing the read side of the underlying transport.
 By default, s2n-tls sends and receives data using a provided file descriptor
 (usually a socket) and the read/write system calls. To change this default behavior,
 an application can implement custom send and receive methods using `s2n_connection_set_recv_cb()`
-and `s2n_connection_set_send_cb()`. 
+and `s2n_connection_set_send_cb()`.
 The application can pass inputs (such as a file descriptor or destination buffer)
 to the custom IO methods by using `s2n_connection_set_recv_ctx()` and `s2n_connection_set_send_ctx()`.
 s2n-tls will call the custom IO methods with the custom context instead of calling
@@ -1048,6 +1046,6 @@ int s2n_early_data_cb_async_impl(struct s2n_connection *conn, struct s2n_offered
 # Examples
 
 To understand the API it may be easiest to see examples in action. s2n-tls's [bin/](https://github.com/aws/s2n-tls/blob/main/bin/) directory
-includes an example client (`s2nc`) and server (`s2nd`). 
+includes an example client (`s2nc`) and server (`s2nd`).
 
 **Note:** `s2nc` and `s2nd` are intended for testing purposes only, and should not be used in production.