> From reading related articles, I get the idea its requirements can be implemented in terms of a browsing history, which could point to a date in the internet archive for all the legislator cares.
Good luck doing that with a TLS secured connection. All you see is the TCP stream between the two peers. And thanks to PFS enforced on the server side you can't even go around and force people to escrow their keys.
> I don't see why one would need complete packet traces of the whole thing.
Because that's the only thing an ISP is able to see of a properly encrypted connection.
So ISPs can now be coerced, by law, to allow for MITM in TLS connections. Another reasonable expectation from buyers of DPI products.
Like I said, nothing technically absurd about this law. It is its profound disregard for privacy that we should be discussing, instead of spending our time on technical issues which are solved.
But it's useless to save the encrypted bytes so nobody will do it. It doesn't matter the connection is encrypted - you still get the following information:
Source IP, mapped to customer. Timestamp. Target domain (from SNI or the certificate). Passive system identification (os, browser).
The only thing they're additionally interested in is the link and that's the only thing that encryption hides. I'm not sure they even care about cookies and headers in ICR
Also a few years ago DJB proposed to make a systems hostname the nonce of a key/signature and use secured DNS (DNSSEC or DNSCurve) as a means for establishing a web of trust; a CNAME would be used to for translating www.example.com into ${NONCE}.example.com.
Since DNSSEC (and DNSCurve) allow for signature verfication against a small number of root keys (ATM a single digit number) it'd be trivial to ensure an unbroken chain of trust for name resolution, which essentially completely mitigates a state level MitM attack on DNS.
So by combination of securing DNS and nonceing the hostname into TLS certificates you can throw quite a log into state level crypto circumvention. Of course the critical problem is rolling out all the necessary protocol changes and implementation. And of course DNSSEC is used only homeopathically ATM (and yes, I'm guilty of not having implemented for my stuff as well).
Good luck doing that with a TLS secured connection. All you see is the TCP stream between the two peers. And thanks to PFS enforced on the server side you can't even go around and force people to escrow their keys.
> I don't see why one would need complete packet traces of the whole thing.
Because that's the only thing an ISP is able to see of a properly encrypted connection.