Thank you for good comments.
The only issue I see, which I'm sure you already thought about, is that by stripping the server MAC it may become possible to do some kind of content injection MITM attack on the live connection...
Edit: to clarify, the issue is that in this architecture the auditor possesses the master secret in real time, ie. the MS of the live connection...
Yes, this is THE weakness of tlsnotary for which there is no mitigation. If the attacker is the auditor (or the attacker has compromised the auditor's machine) AND the attacker is controlling the auditee's home router, then It's a full-on MITM attack. The attacker can channel modified or unmodified traffic to-from the bank and on top of that he can inject any kind of HTML. Even after the auditee stops the "recording" and logs out, the attacker can spoof the logout page and still have a functioning connection to the auditee's bank and can do whatever he wants.
Is there a risk of k-lining or attacks if using IRC for rendezvous? IRC is typically unauthenticated. I wonder if direct ip to ip with STUN would be feasible.
Ideally of course, the auditor and the auditee should exchange their public keys via some alternative channel and only then meet on IRC. Each message between them must be digitally signed. Then the possibility of an attack is mitigated.
STUN is possible, but someone must be running the STUN server and get paid for that. That's why IRC was my first choice. Besides, I also thought that having an independent third-party logging the IRC channel may serve as an extra safeguard if one of the counterparties breaks the protocol. This way even if the auditor and the auditee don't trust each other to even follow the protocol, they still can meet on IRC and invite an arbiter to monitor the channel.