Ericsson's very good bad quarter, Mozilla encrypts SNI, new TIP projects, and more

Coming off a long string of losses, Ericsson probably hoped to turn in some good news, but at its latest financial results, the company announced the sacking of 50 people in response to a corruption scandal. This is in relation to an ongoing US Department of Justice and the US Securities and Exchange Commission (SEC) probe …

[Anonymous Coward]

"At this stage, only Cloudflare supports encrypted SNI requests, but Rescorla said Mozilla hopes other DNS hosts will come to the party."

What has SNI got to do with DNS lookups? If you are encrypting SNI, the web host would need to support it, not the DNS host/server.

[batfastad]

The public key (frequently rotated) which is used to encrypt the ESNI message in the TLS ClientHello is published in a DNS TXT record. More info in the RFC draft https://tools.ietf.org/html/draft-rescorla-tls-esni-00

[Time Waster]

Given the public key for this is shared via DNS, prior to the TLS connection, why not encrypt the whole handshake with it? Presumably this would help protect against downgrade attacks and the like as well? As it stands, this seems a lot of effort to encrypt just one of the many fields in a client hello. Especially when, in the vast majority of cases, that field is (and will continue to be) announced in a cleartext DNS request. Also, unless I am completely misreading that draft, there appears to be no suggestion of encrypting the server certificate, meaning that this will likely also be observable in the CN / SAN returned by the server, which would appear to make the whole venture rather pointless?

[Anonymous Coward]

It almost doesn't matter, because it seems to need DNS over HTTPS, the standard way for that will be to host it from the same server that already serves your HTTP traffic anyway (I swear there was an httpd module that already served DNS because it knew the configured IPs and VHost names), and the certificate for that will be secured by :shuffles paper: look, a three-headed monkey!

Seriously, I don't think this will fly. Short-lived keys don't work well with caching. Rotating and publishing keys automatically is surprisingly hard (Thunderbird update servers failed their Let'sEncrypt two or three times in a row, they only noticed after the in-production cert expired; dnssec-tools.org ran with expired certs for months). Standards like HPKP died (removed in Chrome) before born (adopted in Edge) because deploying them safely requires a bit of thinking.

There is a current trend to shift everything to DNS records because people believe it's miraculously safe there. However, this is probably only true because it serves a fairly narrow purpose. Once every net service you offer needs access to an automated interface to set DNS records, these servers will be just as vulnerable, if not more so, as web servers.

Interesting reading: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/

[ThatOne]

> you can hear law enforcement and spooks wondering how to draft legislation to ban excessively secure protocols

Best way is to ban secure protocols: Think of the children! Yes, yes, I'm being sarcastic, not visionary (I hope).

[Anonymous Coward]

They could just establish an authoritative DoH server and slurp all the traffic they want.

[Charles 9]

"Best way is to ban secure protocols"

Then do what the Chinese do: ban and gum up any unsanctioned encryption (read: anything they can't already decode).