RFC: Tlsnotary-as-a-service

rfctaas.md

RFC: Tlsnotary-as-a-service

The following are assumed to already exist:

1. A webserver W with high availability, and strongly hardened. A second server C for holding a private key for signing, only communicating with W
2. A tlsnotary browser addon installable by any user on Linux/MacOS/Win with a single toolbar button ('audit button'); configured to use W as auditor without additional setup or configuration, and knowing C's public key.

Process for user:

The user experience should be: Browse to a webpage, click a button, get an audit file within a few seconds (experiments indicate 5-10 seconds is easily achievable). Use that audit file later, more than once if necessary.

1. User X has at some point in the past installed the addon, and it is enabled in his browser.
2. X decides that he wants a proof of existence of page P on site S. He clicks the 'audit' button on seeing P in his browser.
3. Audit is performed with webserver W as auditor and X as auditee. Peer communication between the two is passed over the existing http or https connection between X and W; it does not need an additional encryption/authentication layer.
4. The steps of tlsnotary audit performed, when X clicks 'audit', are:
5. Prepare PMS with pubkey oracle site(s) (note: here W creates a pms2, second half of premaster secret).
6. TLS handshake with S (involves passing messages between X and W).
7. X sends request for P to S and stores encrypted response.
8. X sends commitment hash to W.
9. W constructs data: M=[commitment hash + pubkey of S (U) + pms2] and sends M to C, who signs remotely to produce and return signature I.
10. W sends (M, I) to X. W's role is complete.
11. X verifies (M,I,U). X reconstructs P using PMS2 to get master secret, and from that decrypted the server response. If this process fails in some way, X simply abandons the audit or tries again; it is of no interest to W.
12. At some point in the future, X decides he wants to prove the contents of P to auditor A.
13. He sends to A a *.audit file containing the following data: C's pubkey + signature (M,I) + encrypted server response + client_random + server_random + cipher_suite + pms1 + pms2 + server_modulus + server_modulus + server_exponent + server_domain_name + tls_version + original_tls_version
14. The auditor experience is: he receives a file, runs a script, if it verifies OK he is shown the page P with a message indicating validity (he may need to perform some manual steps to verify the certificate). Otherwise he is shown a failure message. Here is what happens under the hood:
15. A first verifies that his copy of C's pubkey matches that in the audit file. If not, the error is flagged, as the audit cannot be carried out.
16. A verifies the signature I for M using C's pubkey. If the signature does not verify, the audit is invalid.
17. A then computes sha256(encrypted server response) and compares with the committed hash found in the signed M. If the hashes do not match, the audit is invalid.
18. Then, A runs decryption (using the provided secret material) and views page P. If there are any errors (such as HMAC errors) in doing the decryption, the audit is invalid.
19. Finally, A either programmatically (using Javascript) or manually (using a browser GUI) confirms that the certificate C provided in the signed message M is indeed trusted.
20. If there are no errors, A trusts that P was delivered to X by S.

Advantages

• No logins or credentials for users
• Webserver W is made as 'dumb' as possible. Never holds master secrets, premaster secrets or any part of the key expansion. Never holds user info (see above). The only identifying information held temporarily is the pubkey of the server S for the audit. Never holds audit session encrypted or decrypted response from S.
• No synchronisation requirement between notarization of P and audit of P.
• Lower technical requirement for auditor. Only needs a small script (Python or other, perhaps Javascript). Needs a little technical knowledge to understand how to validate a *.audit file.
• Much lower (essentially zero) technical requirement for auditee; no key management for communicating with auditor, no Python script management. Only interacts directly with browser GUI.
• Signature of W is transferrable. Audits are not one-use-only.

Disadvantages

• Introduction of an additional trust point into the architecture. Everything depends on (a) the integrity of W's private key and (b) non-collusion of W with X. A more complex architecture involving mutliple, possibly randomised servers W could mitigate this weakness.

Open questions

• Rate-limiting. Not sure if a practical idea, but API type access might be a paid service, and could be implemented with rate limiting (possible application: large scale auditing of fiat balances).
• Session management / concurrency for users of W. Use TLS to aid session management? Multithreading, etc.
• Server configuration for W.

point 6 says - expanded key material. Why? The auditor can calculate those himself from the *.audit file's pms1,pms2,sr,cr

I agree, that's wrong, will edit it out.

Why are there two auditors? Aren't W and A the same?