Some editorial tweaks suggested by Mike Bishop

The first is somewhat more substantial than the comment implied, but I
think that the change in focus allowed me to make this easier to read as
a result.

Author: martinthomson

draft-ietf-tls-keylogfile.md

@@ -129,10 +129,10 @@ client_random:
 
 : The 32-byte value of the Random field from the ClientHello message that
   established the TLS connection.  This value is encoded as 64 hexadecimal
-  characters.  Including this field allows a single file to include secrets from
-  multiple connections and for the secrets to be applied to the correct
-  connection, though this depends on being able to match records to the correct
-  ClientHello message.
+  characters.  In a log that can include secrets from multiple connections, this
+  field is used to correlate multiple secrets from the same connection.  This
+  allows secrets to be matched to the correct connection, provided that records
+  can be matched to the correct ClientHello message.
 
 secret:
 
@@ -212,7 +212,7 @@ will log secrets strictly in this order.
 
 ## Secret Labels for TLS 1.2
 
-An implementation of TLS 1.2 {{!TLS12}} (and also earlier versions) use the
+Implementations of TLS 1.2 {{!TLS12}} (and also earlier versions) use the
 label "CLIENT_RANDOM" to identify the "master" secret for the connection.
 
 ## Secret Labels for ECH
@@ -414,7 +414,7 @@ Specification Required procedure {{?RFC8126}}. The role of the designated expert
 in {{Section 17 of ?RFC8447}}. The designated expert {{RFC8126}} ensures that the specification is
 publicly available.  It is sufficient to have an Internet-Draft (that is posted and never published
 as an RFC) or to cite a document from another standards body, industry consortium, or any other location.
-An expert may provide more in depth reviews, but their approval should not be taken as an endorsement
+An expert may provide more in-depth reviews, but their approval should not be taken as an endorsement
 of the SSLKEYLOGFILE label.
 
 --- back