Prohibit reading 1-RTT before handshake complete

This was never explicit for the client as it is usually not possible.

Closes #3855 in a way that perhaps was not anticipated.

draft-ietf-quic-tls.md

@@ -1255,7 +1255,7 @@ handshake messages from a client, it is missing assurances on the client state:
 - Any received 0-RTT data that the server responds to might be due to a replay
   attack.
 
-Therefore, the server's use of 1-RTT keys MUST be limited to sending data before
+Therefore, the server's use of 1-RTT keys is limited to sending data before
 the handshake is complete.  A server MUST NOT process incoming 1-RTT protected
 packets before the TLS handshake is complete.  Because sending acknowledgments
 indicates that all frames in a packet have been processed, a server cannot send
@@ -1280,6 +1280,10 @@ A server could receive packets protected with 0-RTT keys prior to receiving a
 TLS ClientHello.  The server MAY retain these packets for later decryption in
 anticipation of receiving a ClientHello.
 
+A client generally receives 1-RTT keys at the same time as the handshake
+completes.  However, a client also MUST NOT process incoming 1-RTT protected
+packets before the TLS handshake is complete.
+
 
 ## Retry Packet Integrity {#retry-integrity}