Apply suggestions from code review

Co-authored-by: Rich Trott <[email protected]>
Co-authored-by: Denys Otrishko <[email protected]>

doc/api/tls.md

@@ -147,7 +147,7 @@ ciphers can be retrieved via `openssl ciphers -v 'PSK'`. All TLS 1.3
 ciphers are eligible for PSK but currently only those that use SHA256 digest are
 supported they can be retrieved via `openssl ciphers -v -s -tls1_3 -psk`.
 On the client connection, a custom `checkServerIdentity` should be passed
-since the default one will fail in the absence of a certificate.
+because the default one will fail in the absence of a certificate.
 
 According to the [RFC 4279][], PSK identities up to 128 bytes in length and
 PSKs up to 64 bytes in length must be supported. As of OpenSSL 1.1.0
@@ -156,13 +156,13 @@ maximum identity size is 128 bytes, and maximum PSK length is 256 bytes.
 The current implementation doesn't support asynchronous PSK callbacks due to the
 limitations of the underlying OpenSSL API.
 
-To use TLS-PSK, client and server should specify the `pskCallback` option,
+To use TLS-PSK, client and server must specify the `pskCallback` option,
 a function that returns the PSK to use (which must be compatible with
 the selected cipher's digest).
 
 It will be called first on the client:
 
-* hint: {string} optional message sent from the server to help client
+* hint: {string} optional message sent from the server to help the client
   decide which identity to use during negotiation.
   Always `null` if TLS 1.3 is used.
 * Returns: {Object} in the form
@@ -175,7 +175,7 @@ Then on the server:
 * Returns: {Buffer|TypedArray|DataView} the PSK (or `null`).
 
 A return value of `null` stops the negotiation process and sends an
-"unknown_psk_identity" alert message to the other party.
+`unknown_psk_identity` alert message to the other party.
 If the server wishes to hide the fact that the PSK identity was not known,
 the callback must provide some random data as `psk` to make the connection
 fail with "decrypt_error" before negotiation is finished.