add section on server identity privacy (#122)

* add section on server identity privacy

* Update src/protocol/server_identity_privacy.md

Co-authored-by: sinu.eth <65924192+sinui0@users.noreply.github.com>

* remove notes

---------

Co-authored-by: sinu.eth <65924192+sinui0@users.noreply.github.com>

src/SUMMARY.md

@@ -21,6 +21,7 @@
 - [Notarization](./protocol/notarization.md)
     - [Commit Strategy](./protocol/commit_strategy.md)
 - [Verification](./protocol/verification.md)
+- [Server Identity Privacy](./protocol/server_identity_privacy.md)
 - [Selective Disclosure]()
 
 # MPC

src/protocol/server_identity_privacy.md

@@ -0,0 +1,34 @@
+# Server identity privacy
+
+To maximize `Prover` privacy, the server identity is not revealed to the `Verifier` by default. 
+The TLSNotary protocol mitigates the threat of a malicious `Verifier` attempting to infer the server identity from the messages they receive during MPC-TLS. 
+The exact low-level details are outlined below.
+
+## Handshake hash
+
+During the MPC-TLS handshake, the `Verifier` learns the hash digest of all handshake messages
+(see "Verify Data" in https://tls12.xargs.org/#client-handshake-finished/annotated). 
+If the hashed message lacks sufficient randomness that is unknown to the `Verifier`, they could collect all TLS certificates in existence and attempt a dictionary attack on the digest.
+
+## Sources of handshake randomness
+
+The randomness in a handshake comes from `client random`, `server random`, and the `signature` (see "Signature" in https://tls12.xargs.org/#server-key-exchange/annotated). For optimization, both `client random` and `server random` are revealed to the `Verifier` during MPC-TLS. We argue that the `signature` contains sufficient randomness unknown to the `Verifier` to prevent the dictionary attack described above.
+
+Note that the signed message **is known** to the `Verifier`. This message is computed as H(`client_random` + `server_random` + kx_params), where 
+- H is a hash function, usually SHA256
+- kx_params are ECDHE key exchange parameters known to the `Verifier`
+
+## Signature unforgeability
+
+Unforgeability is a key property of signature schemes that ensures that even if the attacker (the `Verifier` in this case) knows both the message the public key of the signer, it is computationally infeasible to forge a valid signature for that message.
+
+>We follow the terminology from the signature forgery taxonomy here: https://crypto.stackexchange.com/questions/44188/what-do-the-signature-security-abbreviations-like-euf-cma-mean/44210#44210
+> - `EF-CMA`: Existential Forgery under Chosen-Message Attack
+> - `UF-KMA`: Universal Forgery under Known-Message Attack
+
+All TLS signature schemes are EF-CMA-secure, but we argue that even the weaker UF-KMA security would suffice for our scenario where an attacker is given:
+- an arbitrary message,
+- a public key, and
+- many arbitary messages and their signatures collected from previous server interactions.
+
+This scenario fits precisely within the UF-KMA model. Since UF-KMA is a subset of EF-CMA, we conclude that our approach is secure.