Comment by motohagiography | Hacker News Reader

Comment by motohagiography | Hacker News Reader

motohagiography

It is worth reading the article this posted one is in response to. (http://www.circleid.com/posts/20180225_humming_an_open_inter...)

It has the kind of inflammatory institutional chauvinism one usually expects from bureaucrats defending their turf and moralizing their powers, but it's important to understand the outcomes the people like them are aiming for.

Additionally, ignoring for a moment the usual appeals for intelligence and law enforcement, the coalition of interests the author is referencing includes those interested in enforcing "societal norms," and "support for persons with disabilities."

The first means censorship and those people never seem to go away. But the second has nothing to do with transport layer encryption and appears to be a dogwhistle offering tacit institutional support to political agitators who want to get onside with adding surveillance levers to the internet.

The article could reasonably be interpreted as a threat that if TLS 1.3 is adopted and imposes further costs on pervasive surveillance apparatuses, they will co-operate to further balkanize the internet.

That article was so hard to read. He jumps to so many conclusions without any logical path like the use of TLS will stress the bandwidth of providers, claiming its like "unauthorized taking of the provider's transport network resources". How will TLS vs not TLS meaningfully impact amount of traffic on a network? He doesn't say, just claims it. I'm guessing he means the provider can't throttle/control traffic based on packet inspection as easily? Regardless, this is like saying everyone in the neighborhood running all of their faucets at the same time is like stealing from the water provider. That's literally their only job, to be a pipe for water. People aren't stealing by stressing the network, if anything the network would be stealing for not running as advertised.

"TLS 1.3 significantly facilitates widespread malware distribution" this guy...has to be getting paid by someone to say this, right? Who is this dude, what is CircleID?

There's throttling to consider, but there's also caching. It's been a long time since I've had conversations with any NetOps folks working for ISPs, but it used to be very important for the health of a network to do considerable caching wherever possible. It's why http includes cache control headers. With TLS, only the browser can now honor this TTL, and an ISP can no longer cache a particularly popular webpage. I've long suspected that caching strategies are no longer very useful given how the internet looks today, but I also understand powerlaws and it wouldn't surprise me if caching is just as useful today as it was 20 years ago.

It would shock me if it was useful at all on today's internet - the caching I imagine is useful are the boxes that large video providers install on ISP networks. But so much of the internet is already encrypted (YouTube, Netflix, Facebook, etc) that any ISP operating a transparent cache probably has a very low hit rate.

One of the problems with http is that nobody bothered to implement some kind of integrity check for http content (and make sure that it got wide deployment). There are too many examples of parties messing with http content.

So if people cared about transparent caching, they should have added integrity checks ages ago.

Now it's too late.

It is interesting to compare with DNS. DNSSEC is basically just an integrity check. These days the lack of privacy is considered a serious issue. And DNS is likely to move to TLS as well.

So many popular webpages these days are dynamically generated that it can't possibly make much of a difference. I suspect the bulk of traffic by weight is video these days.

If my ISP can cache my traffic they can censor it - and do. Every now and again I'm reminded by accident that EE mobile are scanning all my URLs for censorship purposes.

If my ISP can cache my traffic they can censor it - and do.

Only if they can forge a cache-hit, or block a cache-miss from passing through. Something content addressable (like IPFS) would allow an untrusted party to provide useful cache. (doesn't solve the privacy aspect of the untrusted party knowing I accessed the content though).

The case for transparent proxies put in place by consumer side ISPs has largely been nullified by the introduction of elected CDN services like Cloudflare.

The privacy implications aren't really any different, but at least it's the webadmin of the website you're choosing to access that gets to decide. They get to ensure that they elect a company that respects their content and provides value to their visitors.

OK I read the article and obviously lack some context. The author goes on and on about the evils of TLS 1.3 but it wasn't clear why TLS 1.3 would cause the world to end as opposed to say, TLS 1.2. Can't companies that want to monitor their employees just stick a bogus certificate on their computers like they can now?

Edit: deleted an incorrect comment about meta info. That was the other thing...

One big difference between TLS 1.3 and 1.2 is that TLS 1.3 mandates forward security.

So with TLS 1.2 a server can be configured to only allow ciphers without forward security. Then a capture of encrypted traffic can be decoded later. Or a middle box can be provided with the server's private key to analyse traffic.

For TLS 1.3 this has to change. Any capture or monitoring device has to either perform the DH exchange itself, or receive the session keys from the server.

Also, in TLS 1.2, even with Forward Secrecy the focus is on protecting the application data, in TLS 1.3 literally the only things going plaintext are the initial ClientHello and the ServerHello finishing up the key exchange.

Because in TLS 1.3 we know we want DH, they do it right up front. The client is like "OK, here's my DH parameters, also I want to talk to www.yahoo.com" and then the server is like "OK, here are my DH parameters" and here's the trick: The server knows that as soon as the client reads that part it has a working DH key agreement, so without waiting the server switches on encryption and continues (encrypted) with its certificate, the signed transcript (proving it owns the certificate) and any other parameters e.g. "please send me a client X.509 certificate with the following policy OIDs set".

Because the DH happens up front, everything else is opaque, and that means less chance for crappy middleboxes to break it. Middleboxes are how ordinary people became Crypto Zealots, absolutely any harmless parameter, setting, or whatever is another opportunity for idiot middlebox vendors to break things, if we encrypt everything they can't do that, hooray. The Internet works better if we encrypt everything, that shouldn't be true, but because middlebox vendors are universally incompetent morons it is.

The CircleID article is full crazy. There's a whole passage about how the IETF "took over the ITU-T/ISO internet TLS" which turns out to mean basically the words "Transport Layer Security" are also used to name one of the dozens of X series standards. That standard, X.274 also involves er, securing a transport layer, like TLS, and so there are some elements we'd recognise - even Diffie-Hellman key exchange (although it's under a different name and hidden in an appendix) but of course it's not an Internet standard and doesn't use Internet nomenclature.

It's like if midway through a rant on how awful Back to the Future is, the author stopped to complain that Huey Lewis and the News is just covering the 1984 Jennifer Rush song... not _quite_ as crazy as saying it's a cover of Deee-Lite's track but still pretty crazy.

Reply on news.ycombinator.com