Modify notarization format where full TLS keys are not revealed to the verifier.

[themighty1]

Currently in TLSNotary, the Client reveals fully all TLS keys to the verifier of the notarization. This approach is not compatible with the Client's privacy since the verifier gets full access to both the plaintext request and the server response.

The notarization format must be carefully modified in a way that preserves the session integrity while at the same time withholding full TLS keys from the verifier.

Here are all the steps which the verifier takes: https://github.com/tlsnotary/PageSigner/blob/bca431a91e9cad1b145bcaac975efe1aa3683bce/core/Main.js#L741

[themighty1]

Here is one way of doing it. It is not THE only way, there are various ways to achieve it. To simplify, I assumed that there is no private data in the server response.

PHASE 1. The protocol. The protocol has to be modified as follows:

Step 1. For all PUBLIC data in the client's request (CR) to the webserver, the following 2PC circuit is run (for each 16-byte block of data):

inputs:

• TLS key shares from both C and N
• nonce, counter

output which goes both to C and N:

• encrypted counter block (ECB)

Recall, that ECB is xored to the plaintext block in order to get the ciphertext block.

Step 2. For all PRIVATE data in CR, another 2PC circuit is run (for each 16-byte block of data):

inputs:

• TLS key shares from both C and N
• nonce, counter
• plaintext

output which goes both to C and N:

• ciphertext

Step 3. The TLS PRF circuit must be modified to output the hash of the full server_write_key/iv (swk/siv).

What remains unchanged from the current TLSNotary protocol: C sends the whole ciphertext to N in order to compute the MAC in 2PC.

PHASE 2. Signing.

Notary signs the following:

1. Webserver's ephemeral EC pubkey (that's the key used to obtain PMS via ECDHE)
2. All ECBs from Step1
3. All ciphertext from Step 2
4. Ciphertext used to compute MAC in 2PC.
5. hash of swk/siv from Step 3.
6. N's share of swk/siv

Client forms the notarization documents, containing the following:

7. Notary's sig over 1,2,3,4,5,6
8. TLS cert chain
9. RSA signature over ephemeral EC key from the Server Key Exchange TLS message
10. Public data from the request
11. C's share of swk/siv
12. server response with MAC

PHASE 3. Verification.

Verifier (V) verifies that:

• Notary's sig (7) is valid
• the RSA pubkey from the cert in (8) was used to create sig (9)
• RSA sig (9) is indeed a sig over EC pubkey (1)

Then V xors public data (10) with all ECBs (2) to get public ciphertext. V checks that (public ciphertext | private ciphertext(3)) matches ciphertext (4). V checks that (N's swk/siv(6) + C's swk/siv(11)) hash into (5). V proceeds to authenticate and decrypt the server response (12).

[themighty1]

Closing, since full TLS keys will never be revealed to the Verifier anyway. Instead zk proofs about the properties of the plaintext will be used.