doc: fix incorrect README references

README.md

@@ -126,8 +126,8 @@ s2n_config_set_cipher_preferences(config, "20150306")
 
 Internally s2n-tls takes a systematic approach to data protection and includes several mechanisms designed to improve safety.
 
-##### Small and auditable code base
-Ignoring tests, blank lines and comments, s2n-tls is about 6,000 lines of code. s2n's code is also structured and written with a focus on reviewability. All s2n-tls code is subject to code review, and we plan to complete security evaluations of s2n-tls on an annual basis.
+##### Auditable code base
+s2n-tls's code is structured and written with a focus on reviewability. All s2n-tls code is subject to code review, and we plan to complete security evaluations of s2n-tls on an annual basis.
 
 To date there have been two external code-level reviews of s2n-tls, including one by a commercial security vendor. s2n-tls has also been shared with some trusted members of the broader cryptography, security, and Open Source communities. Any issues discovered are always recorded in the s2n-tls issue tracker.
 
@@ -148,7 +148,7 @@ s2n-tls encrypts or erases plaintext data as quickly as possible. For example, d
 s2n-tls uses operating system features to protect data from being swapped to disk or appearing in core dumps.
 
 ##### Minimalist feature adoption
-s2n-tls avoids implementing rarely used options and extensions, as well as features with a history of triggering protocol-level vulnerabilities. For example there is no support for session renegotiation or DTLS.
+s2n-tls avoids implementing rarely used options and extensions, as well as features with a history of triggering protocol-level vulnerabilities. For example, there is no support for DTLS.
 
 ##### Compartmentalized random number generation
 The security of TLS and its associated encryption algorithms depends upon secure random number generation. s2n-tls provides every thread with two separate random number generators. One for "public" randomly generated data that may appear in the clear, and one for "private" data that should remain secret. This approach lessens the risk of potential predictability weaknesses in random number generation algorithms from leaking information across contexts.

crypto/s2n_sequence.c

@@ -30,8 +30,7 @@ int s2n_increment_sequence_number(struct s2n_blob *sequence_number)
             break;
         }
 
-        /* RFC 5246 6.1: If a TLS implementation would need to wrap a sequence number, it must
-         * renegotiate instead. We don't support renegotiation. Caller needs to create a new session.
+        /* If a sequence number would exceed the maximum value, then we need to start a new session.
          * This condition is very unlikely. It requires 2^64 - 1 records to be sent.
          */
         S2N_ERROR_IF(i == 0, S2N_ERR_RECORD_LIMIT);

tls/s2n_connection.h

@@ -70,8 +70,7 @@ struct s2n_connection {
     /* Connection can be used by a QUIC implementation */
     unsigned quic_enabled : 1;
 
-    /* s2n does not support renegotiation.
-     * RFC5746 Section 4.3 suggests servers implement a minimal version of the
+    /* RFC5746 Section 4.3 suggests servers implement a minimal version of the
      * renegotiation_info extension even if renegotiation is not supported.
      * Some clients may fail the handshake if a corresponding renegotiation_info
      * extension is not sent back by the server.

tls/s2n_handshake_io.c

@@ -1389,8 +1389,7 @@ static S2N_RESULT s2n_handshake_app_data_recv(struct s2n_connection *conn)
  * types to be interleaved at the record layer. We may get an alert message
  * during the handshake phase, or messages of types that we don't support (e.g.
  * HEARTBEAT messages), or during renegotiations we may even get application
- * data messages that need to be handled by the application. The latter is punted
- * for now (s2n does not support renegotiations).
+ * data messages that need to be handled by the application.
  */
 static int s2n_handshake_read_io(struct s2n_connection *conn)
 {