Even more from #CloudflareResearch🔬 today. This time we have a deep dive into our paper at ACM SIGCOMM about disentangling the mess of conventions around IP addresses, hostnames, and sockets. Plus, two posts about the future of our "favorite" authentication mechanism: passwords.
Historically, most Internet systems assigned IP addresses to hosts based on which server a service is running on. Cloudflare was designed to be more flexible. In theory, there is no reason IP addresses have to correspond to individual machines or even to hostnames.
To take theory to practice, we ran an experiment to see the impact of taking advantage of the freedom and flexibility brought by this combination of technologies: anycast, SNI, and bpf_sk_lookup. The results were promising.
Research runs the gamut at Cloudflare. Not only do we dig into the lower layers of the Internet to help make improvements, we also work at the application layer. Authentication is especially interesting as it brings humans into the mix.
Privacy can be better at the authentication layer. As part of the CAP project, we created some new work in zero-knowledge proofs (published in Selected Areas in Cryptography 2021), to help improve privacy in WebAuthn. Passwords need a similar treatment.
So, we are announcing a public demo of a service called Might I Get Pwnd (MIGP), a privacy-preserving compromised credential checking service. With fancy cryptography, we can tell you if your password has been compromised without learning your password!
Last year we spoke about OPAQUE as a safer protocol for password-based authentication. It has the advantage over traditional systems in that the server never sees the user's plaintext password. We love systems like this that are privacy-first by design.
Taking data away from a server can impact other security mechanisms, so we're investigating how useful plaintext passwords are to servers in the real world. This study will inform ways to use both OPAQUE and MIGP to build safe and secure password systems.
Networking and performance stories today!
- A repeatable and probe-free methodology for measuring CDN performance (@Cloudflare wins, btw)
- A debugging story about global TLS termination
- How we identify multi-user IPs to improve our security services
We know @Cloudflare is fast (the fastest in most places) and have the scans to prove it. However, most techniques that use active scanning to measure performance aren't verifiable, so as great as our scans are, they aren't enough to convince skeptics.
Enter research.
It turns out that performance can be predicted given a comprehensive map of the Internet's topology. By combining public data sources on Internet eXchange Points (IXPs), off-net caches, BGP, and geodata with smart path prediction algorithms, you can make an educated guess.
The Internet is not simply a loose federation of companies and billions of dollars of deployed hardware; it’s a network of relationships governed by technical standards that form the connective tissue that allows us to build important aspects of modern society on the Internet.
Today on the @Cloudflare blog, we are sharing several articles that highlight how research and standards development intersect to help the Internet evolve into a more secure, more private, more reliable, and trustworthy technology.
The Internet Engineering Task Force (@ietf) is an open, international community that, with the Internet Architecture Board (@intarchboard) and the Internet Research Task Force (@inretafo), publishes technical documents (the RFC series) to influence the evolution of the Internet.
One of the perks of working at @Cloudflare is that technical people are encouraged to share their voice with the public on the company blog. Generous coworkers donate time, energy, and expertise to enable these amazing builders to teach and explain for the benefit of all.
Some of these posts are timeless, some are extremely timely, and more than a few of them are deep. Very deep.
I'm going to highlight a few of my favorites from the last several years in this thread.
The post-mortem is a staple of the blog. In this one, @jgrahamc explores how an incorrect assumption about how time works caused a serious outage and how a single character was the fix.
I was chatting with a friend of mine who hires engineers who told me that in their company's hiring process they have an explicit focus on assessing the candidate's "grit" during the interview process.
Specifically, they try to determine 1) how willing the candidate is to do the thankless grunt work that is needed for team success 2) how likely are they to spend their time reducing the amount of gruntwork their teammates have to do
They consider it an explicit red flag if an engineer is only focused on doing "the hard/fun stuff" or high-visibility projects and expecting their peers to pick up the slack. Such engineers tend to be more interested in their own career progress than the team's success.
Richard Barnes (@rlbarnes) just kicked off #RealWorldCrypto with a great overview of MLS, a new proposed standard for group message encryption. There’s still time to contribute: mlswg.github.io
Joanne Woodage (@joannewoodage) outlines a really cool attack on Facebook’s abuse reporting mechanism for encrypted messages. A great example of how popular schemes like AES-GCM can be easily misused. #RealWorldCrypto
The team also came up with a new one-pass authenticated encryption scheme based only on collision-resistant hash functions. It’s somewhat reminiscent of the Keccac team’s Keyac encryption based the a sponge construction: keccak.team/keyak.html
Crypto 2018 has affiliated events this year, which is fun. I’m currently attending the Quantum-safe Cryptography for Industry event, a big focus of mine lately. crypto.iacr.org/2018/affevents…
@Cloudflare is a sponsor of Crypto this year, so come see me if you want a webcam cover!
We just heard from Adrian Stanger from the NSA. There is high confidence in the NIST process and no plans to invest in QKD. Algorithm recommendations (key agreement and signatures) to be made around 2023-24. There are no plans to replace AES-256 or SHA2-384.
Brian LaMacchia of @MSFTResearch gives an overview of the cryptographic algorithm transitions we’ve gone through so far in the 21st century.