Improve comments

Signed-off-by: Ronald Cron <ronald.cron@arm.com>

library/ssl_msg.c

@@ -3264,8 +3264,8 @@ int mbedtls_ssl_prepare_handshake_record(mbedtls_ssl_context *ssl)
         /*
          * When establishing the connection, the client may go through a series
          * of ClientHello and HelloVerifyRequest requests and responses. The
-         * server does not keep any trace of these initial round trips as
-         * intended: minimum allocated ressources as long as the reachability
+         * server intentionally does not keep trace of these initial round
+         * trips: minimum allocated ressources as long as the reachability
          * of the client has not been confirmed. When receiving the "first
          * ClientHello" from server perspective, we may thus need to adapt
          * the next expected `message_seq` for the incoming and outgoing

library/ssl_tls12_server.c

@@ -914,10 +914,11 @@ static int ssl_parse_client_hello(mbedtls_ssl_context *ssl)
 
     /*
      * Fetch the expected ClientHello handshake message. Do not ask
-     * mbedtls_ssl_read_record() to update the handshake digest, to align
-     * with cases where the ClientHello may already have been fetched in
-     * ssl_tls13_process_client_hello() or as a post-handshake message
-     * (renegotiation).
+     * mbedtls_ssl_read_record() to update the handshake digest, because the
+     * ClientHello may already have been read in ssl_tls13_process_client_hello()
+     * or as a post-handshake message (renegotiation). In those cases we need
+     * to update the digest ourselves, and it is simpler to do so
+     * unconditionally than to track whether it is needed.
      */
     if ((ret = mbedtls_ssl_read_record(ssl, 0)) != 0) {
         MBEDTLS_SSL_DEBUG_RET(1, "mbedtls_ssl_read_record ", ret);