Clarify spec.

Author: dvc94ch

README.md

@@ -24,12 +24,18 @@ is converted to an x25519 key using the algorithm as implemented by libsodium.
 NOTE: while it is likely ok to reuse the key for singing and diffie hellman it is strongly advised
 not to reuse the key for other protocols like VRF or threshold signatures.
 
-## Handshake session
+## Crypto algorithms
 
 Using xoodyak (a finalist in the on-going NIST light weight crypto competition), the following
 sequence of operations are performed for deriving the 0rtt-key, 1rtt-key and next-1rtt-key. For
 fast authenticated encryption a chacha8poly1305 cipher is used.
 
+## Session
+
+The initial packet contains the ephemeral client public key, the encrypted client static public key
+and the encrypted client transport parameters. After the initial packet 0-rtt packets can be sent
+using the `initiator-0rtt-key` without having to wait for a response from the server.
+
 ```
 Initial:
   | Cyclist({}, {}, {})
@@ -46,7 +52,13 @@ c | Encrypt(client_transport_parameters)
 t | Squeeze(16)
   | initiator-0rtt-key = SqueezeKey(32)
   | responder-0rtt-key = SqueezeKey(32)
-...
+```
+
+After receiving an initial packet the server produces a handshake packet containing the encrypted
+server ephemeral public key and the encrypted server transport parameters. After the handshake
+packet 1-rtt packets can be sent. Once all 0-rtt packets have been acked the keys are discarded.
+
+```
 Handshake:
 c | Encrypt(e)
   | Absorb(ee)
@@ -55,8 +67,13 @@ c | Encrypt(server_transport_parameters)
 t | Squeeze(16)
   | initiator-1rtt-key = SqueezeKey(32)
   | responder-1rtt-key = SqueezeKey(32)
-...
-Data:
+```
+
+During the transport session the 1-rtt keys might need to be rotated. This happens when approaching
+`u64::MAX` sent packets or if requested by the other party. See the quic spec for details.
+
+```
+Key rotation:
   | Ratchet()
   | initiator-next-1rtt-key = SqueezeKey(32)
   | responder-next-1rtt-key = SqueezeKey(32)
@@ -69,6 +86,18 @@ valid `quinn-noise` version.
 
 - [0] https://github.com/quicwg/base-drafts/wiki/QUIC-Versions
 
+## Header protection
+
+Header protection/obfuscation serves to prevent middle boxes from reading the header. Modification
+is not possible since the header is passed as associated data to the cipher. The idea is that if
+the header changes in a future quic version, middle boxes may drop the packets because they can't
+read the header. But header protection/obfuscation only makes it harder not impossible. Due to
+being questionable if it serves it's purpose it was decided that no header obfuscation is applied.
+
+## Retry mechanism
+
+The retry mechanism is identical to what is specified in the quic-tls spec.
+
 ## License
 
 MIT OR Apache-2.0