Ask HN: If the Internet were redesigned today, what changes would you make?
I mean the protocols, networking, connectivity. I don't mean the content of the internet.
Is DNS really a perfect protocol? How can it be improved?
Is DNS really a perfect protocol? How can it be improved?
326 comments
[ 3.4 ms ] story [ 264 ms ] threadBlockchains in a way are such clocks where the ordering of the blocks on the chain provide an implicit counter. But blockchains have too much overhead so by assuming some trust it would be possible to get rid of the proof of work mechanism and just use a signed timestamp from a trusted source.
We should have had DHCP prefix delegation for IPv4 so people wouldn't need NAT.
That's not the worst idea I've ever heard.
Elements that know they're user-editable (images with upload controls attached to them to replace the image that's there, dates that trigger calendar controls when clicked, and inline editing for other elements that actually works and is consistent across browsers).
An offline database in the browser that has the concept of user accounts and resetting passwords baked in, as well as subscription payments, and has a universal API that can be automatically deployed to any hosting platform.
All of this would make building web apps and games trivial for so many more people -- write some basic HTML, upload it to one of a million platforms of your choice with a click, and you have a testing ground for a product that can grow.
It would be a way for anyone on the internet to build something useful and get it out there without learning a thousand technologies with a thousand nuances.
email is a nice way of addressing, but we underuse that address compared to all the balkanized post-email systems.
https://delta.chat/en/ implements encrypted IM over email.
https://jmap.io/spec-calendars.html is the calendaring spec for IMAP's likely successor
https://webfinger.net/ is the (appallingly named) http protocol for finding named people such that social connections can be made and managed. Some extensions exist for services that commonly run with email that provide webfinger services.
Authentication? DKIM, check.
Integrity and confidentiality? SMTP-TLS, check.
Oh, you meant against the provider? S/MIME, check.
Base64 - irrelevant given the size limits most vendors apply to attachments. Email isn't a great file sharing system and trying to optimize it for that might be a bad idea. People use Google Drive etc links these days instead, which works better.
No one was working on an alternative that addresses this problem, so I drafted & implemented "TMTP". It also addresses a variety of other common email problems.
https://mnmnotmail.org/
https://twitter.com/mnmnotmail
While the spam problem is much better than it used to be, that's because there's a whole lot of behind-the-scenes (and expensive) infrastructure devoted to combating it.
That infrastructure has also made it considerably more difficult to run your own mail server. While you can still do it, there are many hoops to jump through if you want to keep your mail from being dropped on the floor by the first overzealous spam filter it encounters. Unless you're big enough to devote a staff just to that (or you have a lot of free time) it's easier (but more expensive) to just use MailGun, MailChimp, or one of their brethren.
I would guess that the annual cost of spam is somewhere in the billions.
Thanks to VoIP, we've seen a surge in phone numbers being spoofed with robocalling. I'd like to see some form of authentication applied to this and to email.
https://www.energy.gov/sites/prod/files/2020/07/f76/QuantumW...
https://apps.dtic.mil/sti/pdfs/AD1096290.pdf
Facebook was famously started and hosted in a dorm room. But this was only possible due to the history of Harvard within the advent of the internet and the fact that they had such an excess of addresses that Zuck could bind to a public IP address. We’ll never know what tiny services could have blown up if people didn’t hit this wall.
I started off with computers by hosting garrysmod servers. My brother started off with computers by hosting a website dedicated to the digital tv switchover in Wisconsin (lol). This was only possible because my dad was a software engineer and paid a bit extra to get us 5 dedicated IP addresses. If he didn’t understand that, who knows what me or my brother would be doing today.
Anyway, I say IPv6.
If I could fix anything, it would be IPv6 itself. The biggest thing preventing it's widespread adoption is it's complicated nature.
An IPv4 with an extra octet or two would have seen complete adoption years ago.
No new/subsummed functionality. Stick with ARP and DHCP, etc.
A better / more actionable upgrade path and plan to get things working so most devices could go v4.1 only quicker, etc.
IPv6 tried to solve too many problems at once. We should've just focused on solving the address exhaustion issue. Instead, we have a very slow roll out of IPv6, and awful stuff like CG-NAT taking permanent hold.
https://news.ycombinator.com/item?id=17344911
ipv4 is a mess in many ways, ARP for instance, is a disaster once you reach a certain scale and many of the ipv4 header fields are unneeded leading to inefficiencies. multicast on ipv4 is a mess, rfc1918 is a neat idea but ipv6 fixes it in a far better way and gets rid of NAT in the process. (and no, NAT does not increase security, ipv6 still has firewalls !)
in my opinion, ipv6 is the far simpler protocol, it is the migration from ipv4 to ipv6 which is resulting in all this complexity, but it is not the fault of ipv4.
and before people ask why not just extend the address space... that only solves half of the problems ipv4 has and not to mention, results in having the same dual stack situation as we have right now. extending address space is simply not possible in a backwards compatible way. and if we have to break compatibility, we might aswell fix all the other issues with ipv4.
Also, forward-compatible address extension is something which is simply not possible with routing protocols in place today, and i highly doubt it will be a possibility in the near or far future considering the enroumous coordination effort required between Core players on the Default-free zone and internet at large.
This sounds interesting. Can you ELI5?
Big research institutions that were present when IP addresses were being allocated got A LOT of IPs by simply asking for them. Apple has the entire 17.0.0.0/8 range. Ford Motor Company has one, the US Gov has a lot [0]. Up until recently MIT had all of 18. (they sold something like half to AWS for a hefty sum not too long ago).
As a student (or visitor), when you joined the network (wired or Wi-Fi) you weren’t allocated some internal IP behind a router but a PUBLIC 18.something that was in the global address space because they had so many IPs available. This meant you could literally host something on the public internet from your dorm room because every device on the network was publicly routable by a unique public IP address.
[0] https://en.m.wikipedia.org/wiki/List_of_assigned_/8_IPv4_add... (see the last section on the original allocation)
As an interesting detail, which seems alien today, is that this was also true at my various employers throughout the 90s. My desktops at work all had public IP addresses and were directly on the Internet, no firewall or anything.
I ran mail and web servers, fully internet accessible, on my work desktops (and lab machines). It was a natural thing to do.
This was awesome for about 3 hours until the worms showed up - because Win98 didn't come with a firewall.
What EvanAnderson said.
The office ethernet network just contained a router, which would be hooked up to the upstream (via multiple T1 lines, IIRC). So everything on the office network had a public IP and was directly on the internet.
The design works just like postal addressing. Your postal address contains the directions to your building from any location on earth. Even if you live in a dormitory building with many other residents, I can still send you a letter directly by adding "door number: 42" to your dorm's postal address.
IP addressing use numbers instead of English terms like "door" and "street". So I can't simply add "door number" to your building's IP address, your building has to be given enough addresses so each resident's computer can have their own. When your computer has a public IP address, I can send Internet packets directly to you.
Harvard was early to the slicing of the IPv4-address pie, so they had enough addresses each of their residents, including Zuck. Anyone with internet could put Zuck's IPv4 address on an Internet packet and it would end up on his computer. Most of these packets would be HTTP requests to facebook.com, to which his computer would reply with a page from the facebook website.
This is the internet working as intended.
But we ran out of IPv4 addresses in 2012, which has forced internet service providers to adopt an address-sharing scheme called network-address-translation (NAT) that makes it impossible to send letters directly to other people's computers. Imagine I wasn't allowed to put any room number or name on my letters. If I sent a letter to your dormitory, the staff there wouldn't know what to do with the letter and would be forced to return-to-sender or discard it. This is what NAT does, and it has turned the glory of the Internet into a centralized monster of control and censorship.
If you want to host a website with a public IPv4, only established cloud providers that obtained enough IPv4 addresses before it was too late can help you (primarily Amazon, Google and Microsoft).
The successor of IPv4, IPv6, brings enough address space for every person, their dog, their dog's fleas, and their dog's flea's microbes. We can go back to hosting websites from our dormitories, sending chat messages directly to our friends (not via Google, Facebook and Microsoft), and start new ISPs that missed out on the IPv4 pie that actually have a chance at competing with the likes of Comcast.
IPv6 reintroduces equity to the internet that facebook benefited from in it's inception.
Except for the fact nobody can type, much less remember any IPv6 address.
I'm looking forward to using `router.local` over `192.168.1.254`.
rfc1918 address space is easily remembered because people use mostly 192.168.xx.xx. but ipv6 has the same idea and when writing it shorthand isnt significantly larger.
Obviously doesn’t scale, but I would assume this was normal back when you only interacted with say <10 servers.
You basically just need a router and an OS from the last two decades and your machines to have a defined host name (which your OS installer takes care of).
I regularly run into instances where local hostname resolution is unreliable.
To improve reliability, I setup a local DNS server to hand out a domain name with the IP address. Even then, whether a client requires a hostname or FQDN to resolve a local address - that can vary over time.
the end-to-end principle is mostly undermined by stateful firewalls and a total lack of secure-by-design in software developement, this will not change with ipv6
There was a time when the Internet was not divided between producers and consumers of content, but everyone was an equal netizen with publishing capabilities. Then came asymmetric connections, and datacenters, and the modern hellhole we all know to well.
It's never too late to act: many "community networks" are doing an amazing job to promote selfhosting and hosting cooperatives.
e.g. Isolating subnets and restricting outbound access. Seems like a useful defence-in-depth mechanism in case of misconfigured firewall rules.
https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
No, it's entirely unrelated to NAT. That's a consequence of the firewall on the router.
IPv6 doesn't get rid of the firewall.
> any default-configuration firewall would achieve the same
OK, but default NAT does achieve it as well, right?
NAT has become too complex and most consumer versions of it are developed for ease of use over security. Don't trust NAT to protect your network, because the device doing NAT in your home network most likely wasn't developed to use it as a security measure.
I went to the NANOG meeting in October 1997. Many (most?) of the people who were responsible for administering the core routers using Internet Protocol at the time were there. During one talk they were talking about IPv4 running out, and mitigations for this - NAT, dynamic IPs, reclaiming allocated IP space, web servers that could serve multiple domains from the same IP address etc. One questioner went to the microphone and asked in a serious manner, "can't we solve all of these problems by rolling out IPv6?" The entire room broke into laughter.
VPS providers such as Linode were around at the time, and they weren't that expensive. $20/mo would have got you enough to get started. Or you just get shared PHP hosting which would have been cheaper or even free (with ads injected). And much simpler to deploy than today, just FTP the files and boom it's live. If you were lucky, your host had cPanel.
What? Have you forgotten what your first time was like?
There is a huge difference between thinking:
> "I build my first shitty website, if i leave my PC on everybody in the world can use it. Who knows what will happen?"
And instead being required to go:
> "I'll spend 20$ a month to maybe entertain a couple of people for a couple of minutes by using someone else's hardware"
Then and now, any second hand hardware will yield more computing power than cheap VMs you can rent. (of course you can rent a dedicated server with 32 cores and 128GB RAM nowadays, this doesn't change that entry level offers are very limited on resources compared to what you can easily find AFK)
It was never a good idea to host a public site on one's personal computer with all the sensitive personal data on it where it could be hacked or DDOSed. Even when IPv4 addresses were easy to get it was a very bad idea.
When you factor buying a separate server, 20$ a month doesn't sound too bad.
Most people getting started are not going to understand systems administration enough to set up a server like that. But they can run software locally.
One of the first projects I was ever a part of was a “WAMP” machine (Windows Apache MySQL & PHP) running Nuke Evolution forum software. I learned a lot from that and would never do it again but it was a useful project for some people and I learned a lot by patching around the source files and learning about MySQL enough to make backups and improvements and so on.
Being able to put up a simple service is but only one of the reasons to be publicly addressable, P2P is also important (things like games, VoIP) but $20 for a VPS is no small barrier.
Not for someone getting started.
This was considered a sophisticated operation because in the late 90s and early 00s basic hosting and email were often included with consumer Internet packages.
Server hacking and DDOSing weren't quite the organised thing they are today.
You could run it in a VM, which is equivalent to what your 20$ host is doing. Or you could run it on a separate machine. Or you can run it on the same machine which was common back in the day... if you use a reputable distro and apply updates regularly then it's really not a concern (i can't remember myself or anyone i know hacked through vulnerable packages, except for Worpress but that's precisely because it's not packaged by Debian).
> 20$ a month doesn't sound too bad
Doesn't it? I guess it's a matter of age and class and nationality. If you're too young to earn money, it's a barrier. If you're in the lower classes of your country, 20$/month can be a lot (that's like food for 30 days for one person). If you're in a "poor" country (i.e. neo-colony depleted of its resources by global north countries), 20$/month can even be considered a decent monthly income.
> buying a separate server
That's the thing. You usually don't have to buy it. It's old hardware lying around or that someone will donate for the purpose of running fun projects.
I was comparing the payment to buying or operating a server (even a free old server has costs, e.g. for electricity). In truth, a proper modern comparison should be to a free plan from one of the cloud providers which is likely to be 0/month.
Sure, but if the machine is already running, it's free. Or if you can stick it in a cupboard at work/university, it's free.
> 0/month
is there actually free cloud hosting? don't they ask for your credit card first before they offer you "credits"?
It still has costs for admin and electricity (via extra CPU load), though I grant these could be marginal.
>Or if you can stick it in a cupboard at work/university, it's free.
This is using someone else's resources, rather dubiously ethical. I suspect IT is going to have a fit when they find out - assuming they didn't block the relevant ports in the first place.
>is there actually free cloud hosting? don't they ask for your credit card first before they offer you "credits"?
There are free plans on Azure/AWS/GCP. Asking for credit card data does not mean you are being charged, I suspect it's really more about identifying users.
It's possible to set up free plans without credit card if one has some other id (e.g. Azure's free plans via MSDN). A prepaid card should work as well.
When I got a job in a supermarket at 16 earning £4/hr I was able to afford a VPS, so bought that and learnt how to administer servers. To me it was a worth-while expense as a fun hobby and education. Today you can get a more powerful VPS for $5/mo, of even free with things like AWS free tier.
I'm not sure that's really applicable to Zuck and Co (it wasn't just him when it launched) though - someone at Harvard with wealthy parents.
I'm fairly certain the version of Facebook that was hosted from Zuckerberg's dorm room was just for Harvard students, and wasn't accessible from outside the campus network. Keep in mind that early FB was rolled out to only select universities on a campus-by-campus basis over the course of a year or two; it wasn't like it was today. Part of the whole appeal of FB early on was its exclusivity.
There were and are lots of places with routable IPv4 addresses that still have various kinds of traffic management and firewalling. My uni handed out real IPv4 addresses in the early 2000s (may still today!), but absolutely didn't allow inbound connections from anywhere outside of the campus network, at least not on well-known ports. You could (and lots of people did) run a server, SMB or AppleTalk file share (so much porn...), etc., but it wasn't accessible to the entire Internet. (Hotline and Carracho servers, OTOH...) I would be absolutely astounded if Harvard didn't have some inbound filtering on its network at the time; keep in mind this was 2004: peak Windows XP era... students would have been getting hacked left and right if they hadn't.
There are still some big companies around with very large IPv4 allocations for historic reasons (HP has at least two /8s I believe, its own original one plus one acquired from DEC; IBM has at least one; Apple has one, etc.) and some of them use routable addresses internally. I know IBM did this in its major offices in the mid to late 2000s. But you couldn't just spin up a server at your desk and hit it from home without going through IT and having them put in a firewall rule for you. This was all pretty standard network security stuff at that point.
It was originally hosted on Harvard's servers, and lasted only a few hours before the administration pulled the plug on facemash, which was basically a 'hot or not' clone.
Then they rented a server for $85/mo. and launched thefacebook.com a few weeks later.
Both sites were on the public internet.
https://www.fastcompany.com/59441/facebooks-mark-zuckerberg-...
Yes, we do not have enough IP address for all IoT devices, for all refrigerators and smart bulbs.
Yes, but some things become tricky:
- SMTP reputation is related with reverse DNS of your public IP
- reverse-proxying TLS-encrypted trafic relies on SNI headers, which not all protocols implement
- some protocols entirely don't have a virtualhost (domain) notion, like gopher or SSH
Overall, it's not so easy and simple. Sure i don't care that IoT devices don't have public addresses. To be honest, i'm firmly against IoT as a dystopian nightmare (good luck breaking into your home when your "smart lock" fails). However, public addresses and symmetric bandwidth are very important politically speaking, because they ensure that everyone is given equal opportunity to publish information.
Before the Internet, we had mostly asymmetrical communications. Newspaper required considerable resources to setup, and radio stations were (and still are) government-approved because there is limited channels available... so people could only consume information, not spread it. The Internet did away with this scarcity by having all IP addresses created equal, and everybody having as much upload than download speed (before xDSL).
Internet was the first network where everybody could create content and actually practice what some people call "freedom of speech" for a marginal cost. If you take away public IPs or introduce asymmetric bandwidth, it's not the Internet anymore: you are creating yet another passive consumption network where big corps and nation states tell you what to think.
I personally think asymmetric DSL is the worst that happened to the Internet so far. It's created the idea that there's different hardware and connectivity for clients (we the people), and for servers (fancy machines in datacenters)... two different classes of devices if you will. Nothing could be further from the truth, but this manipulation by the telco industry gave birth to the centralized hosting hellscape (GAFAM) that we know today.
But also those IPs should be available without an entity having to assign.
And not only that but we would also need a free DNS system so you can't be denied host resolving.
And the domain names shouldn't be controlled by someone entity because you can be denied having one or the issuer can withdraw you domain.
Most censorship I've seen was done by DNS filtering. Also some domain names were withdrawn from their owners even if they didn't do something illegal.
It's not widely implemented because hardware support is lagging behind (Ubiquity being a notorious example in the prosumer space), hardware support isn't being developed because it's not rolled out widely, software support is lacking because of a lack of rollout which is then used as an excuse not to roll out IPv6.
I bet that if people learned IPv6 before they learned about IPv4 the conclusion would be that IPv4 is a mess. In my opinion, DHCP is a stupid protocol for assigning addresses that shouldn't have been necessary, but we've managed to staple some kind of management ideals on top of it (as if someone couldn't just set a static IP on their device) and using SLAAC feels like giving up control for some. Imagine trying to convince people that they have to set up a USBCP server on either their computer or their flash drive to make USB work without address conflicts, or to make Bluetooth work, they'll laugh at you and ask why that stuff isn't done automatically by the underlying protocols instead. DHCP is useful for many other settings, but address negotiation should've never been a problem it needed to solve in the first place.
We've accepted NAT as a fact of life because of ISPs being stingy to hand out addresses years ago when multiple devices started appearing in home networks and now people treat it like some kind of firewall (which it usually isn't!) or absolute necessity because they can't imagine something else.
Ask any console player about what type of NAT they have (NAT type 0? Type 1? Type 2? open? moderate? strict? I've never been able to figute out what these classifications even mean on a technical level!) and they'll shudder with flashbacks of getting basic connections to work with their crappy ISP router. This should never have been a problem, but everyone kept dragging their feet and eventually we decided to accept this mess.
I think part of the reason is that many schools still only teach IPv4 in their networking classes, so when people encounter IPv6 in the real world they're scared and confused by concepts, protocols and mechanisms they were never prepared or trained for.
Why?
My ISP isn't handing out static IPv4 nor IPv6. However IPv4 works just fine while for IPv6 it's a giant pain.
The world isn't static though, so maybe IPv6 is the problem here? Or do you seriously suggest I should manually change all my device IPs just because I switched ISP? Why should I care about which prefix I get?
> In my opinion, DHCP is a stupid protocol for assigning addresses that shouldn't have been necessary, but we've managed to staple some kind of management ideals on top of it (as if someone couldn't just set a static IP on their device)
Even for my puny LAN I've managed to create address conflicts when doing static IP assignments. If I need to keep track of my devices in an Excel sheet, why not just use the DHCP server? I need something ala the DHCP server to hand out DNS and NTP servers etc anyway.
> when people encounter IPv6 in the real world they're scared and confused by concepts
When I went to school and learned about IPv4, IPv6 was just getting started. I'm not scared. Slightly confused yes, it's a non-trivial change from IPv4 after all. But the main issue is missing support, from hardware to software to ISP's.
Causing a conflict in your LAN with address is a problem of IPv4 and the tiny address space it has. It forces you to keep a tight administration and use a bolt on address space management technology like DHCP. IPv6 does not have that problem and you'll have a service less to run.
Indeed, it's not trivial. Many parties will have to do something. I hope they'll get more motivated as the price for IPv4 addresses rises even further. When CGNAT solutions get starved of socket space and adding extra IPv4 addresses gets prohibitively expensive maybe IPv4 will get so slow and unreliable people will give up on it.
The graph of IPv4 address space pricing gives some hope: https://postimg.cc/QKKx847B
That's my point. I don't really care. Yet for IPv6 I suddenly need some way to automatically update the firewall rules etc, because the internal IP is also the public IP.
> IPv6 does not have that problem and you'll have a service less to run.
But how do you distribute DNS and NTP server addresses without something ala DHCP?
Do you have some links on how to configure this?
> Why would you set your own NTP server with DHCP ?
What kind of question is that? Because I have a local NTP server that I want them to use of course.
Having an outbound allow any and incoming deny any should be sufficient for home use (as it is with IPv4).
The whole point of IPv6 is to allow peer-to-peer communication. For that I need to allow certain incoming connections.
If you seriously think that is a non-issue, then what does IPv6 bring over IPv4 (with or without CG-NAT)?
It's out there, creeping up on 50% or just over in a significant chunk of the developed world.
if the current tech is so messed up to warrant a re-build, why would one expect that all the requirements are properly captured?
having said that, stepping back and articulating the existing problems could be a viable first step. Identify and scope the problems before dreaming of solutions. /product engineer and party pooper hat off
ISPs should simply check where the UDP traffic is coming from, and filter out packets that have a different UDP source address inside them.
This would literally make the internet DDoS free.
https://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
Amplification makes a DDoS bigger, but isn't what makes it a DDoS.
I know, but large botnets like MIRAI and similar usually take advantages of how UDP flooding works, because TCP RST packets don't scale as well.
I was just mentioning that because ISPs could easily get rid of most UDP-based DDoS attacks if they would watch their networks' packet sources (what they're doing anyways).
Usually it's literally just a comparison of IANA assigned IP ranges (of source+victim being inside or outside), and if they're mismatching, it's very likely to be a UDP flooding attack.
Imagine how many times security and privacy have been reimplemented in different contexts.
And that patchwork approach will incentivize security breaches and manipulation through dark surveillance until ... no end in sight.
Although even non authenticated encryption is nice to prevent passive eavesdropping.
The protocols could be encrypted by default - all that's needed are protocols to let a device communicate to the router what its chosen public key is, and for that to communicate it back to the owner of the IP block, which has to operate an OCSP-like query service to vend certs.
The big question is - do you trust your isp for that. Of potential attackers who can eavesdrop on my connection, isp (or someone at isp or gov giving isp a warrant) seems pretty high on the list.
In end to end encryption, preventing mitm attacks is the hardest part and often is glossed over. How many people actually verify the "safety number" when using signal? Probably most do not.
So i would say common definitions of end to end allows for trusting someone in the middle to not perform active attacks (after all, you also have to trust them not to provide malicious binaries with keyloggers) but should prevent passive attacks by someone in middle.
The source for that library will be extremely well vetted. Maybe the most vetted code ever written.
There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them.
Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally).
In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything.
Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report.
There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today.
The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
> Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally).
So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient).
How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message.
Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer?
> There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today.
Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have.
> The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
They don't have to know where the mail is actually going, or what is in it. Just that they are getting a request from a person who owns that mail.
It gets more complicated than that, for the wonderful reason that there are so many more great things you can once you have standard primitives for encryption and cryptography. For instance, instead of a general email address, you can also give unique addresses to people so that only people you want can send you anything, and you can verify who its from.
You can still have a public address just by creating and publicizing an address for that purpose.
Once their is a standard library that developers can take for granted there are so many other things that can be easily done.
Today many of those things are difficult simply because there is no standard library, and everyone rolling their own implementations creates a nightmare. It is the vetting and fixing every single vulnerability from each implementation that is too difficult for most developers, even very good ones. That is one reason why everything is so insecure today.
A first draft of how the encryption works for email would probably one day's white boarding, since the primitives for this kind of thing have been around a long time. And people have done this kind of thing many times before in small contexts.
The actual implementation, to be very fast, extremely vetted (even formally verified) for correctness and after iterating many times of possible use cases and corner cases, would take some time.
There wouldn't need to be a single code base, but the point is to have very few implementations that are extremely well vet. So few implementations creates better security.
That way most applications and users can forget its even there.
I agree you could do schemes like this (although some of the details here would need finessing), i just don't really think it fits the description of at a low enough protocol level its transparent. Like this is custom application logic - it doesn't get much higher level than that. How could an application forget its there if it has to keep track of storing numbers and finding/sending/decoding the right ones. If this generalized to something that fit every application, i'd say fair enough, but it seems incredibly specialized to the example at hand.
If all we're imagining is a standardized set of primitives, we already have that. AES, SHA-256, HMAC are all very well studied and well supported (the public key world doesn't quite have as much of a clear "winner", but there are still very standardized well studied options).
All of these things are very secure when used correctly. People however invariably use them incorrectly. Composing primitives (incorrectly) is one of the big ways people get into trouble with crypto.
I guess what you're suggesting is an opinionated library that has a bunch of safe options to make it less likely to shoot yourself in the foot? I mean, i certainly agree we could do better when it comes to usability of crypto libraries. Ultimately though, no library is going to prevent a programmer from (for example) giving the secret key to the attacker. By extension, we're never going to have a library that takes the thinking out of using crypto. A big portion of computer security problems are simply the programmer accidentally telling the computer to do something silly, and the computer blindly following orders. I don't think its possible to get rid of that if the programmer is the one calling the shots. Which is why i find the idea of automatic encryption on the tcp or ip layer so enticing - your average programmer would have no influence over it - but the idea also seems to have severe technical limitations (or at least it needs someone smarter than me to figure it out)
Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning.
Recall that nothing in today's internet really rigorously stops an ISP obtaining a certificate for a website it hosts, or even one that it doesn't! A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level.
However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
> Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning.
in WebPKI:
- CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable)
- certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA.
If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out.
> and pinning
I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to?
Its even worse if you still want to support NAT.
> A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level.
Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware.
> However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network.
Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.
CA Audits are mostly about ensuring they're following the rules. However, the rules cannot stop an ISP or hosting provider just issuing themselves a cert and a fully audit compliant CA is not expected to stop this.
Cert transparency is mostly unused. For it to work people have to proactively search the logs to find certs they didn't issue, but in reality nobody does this outside of maybe big tech firms. Moreover, in the ISP/colo interception case, the CA wouldn't be revoked because they wouldn't have done anything wrong.
Re: pinning. You can't pin if your IP isn't stable. However you can if you're a server. Then you don't need the fragile link of DNS in the loop at all. For instance, mobile apps can just have a cached public key (of course you can do that today, but we're talking about a system that is more deeply integrated with the internet).
"there is no single attacker who is on path for all of lets encrypt's vantage points"
No? AWS isn't on path for all the websites they host?
Even in the case where the hardware isn't owned, any site that has one internet uplink (i.e. most of them) can be targeted in this way.
Edit: I think this would result in protocols over walled gardens. The problem is JS makes HTTP/HTML everything to everyone.
The alternative to JS is not "no scripting", it's websites that only function with proprietary plugins installed.
Yes and those were websites that for the most part nobody gave a crap about. The important sites weren't willing to dump so many of their viewers. Heck, even post-JS, the web didn't suck so badly until the option of shutting off JS was removed from browser UI's. Before that, enough users shut off JS that sites wanting wide audiences had to be able to function without it.
https://stackoverflow.com/questions/6355300/copy-to-clipboar...
I'm confused by this comment - HTML5 does do all that out of the box. Are you saying it should have done it from the start?
I don't get the bit about JS being required to render static content either...
Should MS Word and Adobe PDF also execute code? Should I only be able to run an application only by executing it in MS Word and Adobe PDF reader?
Oh boy do I have news for you! https://helpx.adobe.com/acrobat/using/applying-actions-scrip...
Not sure about Word as I barely know it, but I'm sure you can execute some sort of code. If not JS, probably VBA or other Microsoft language.
Flash got axed because the way it was implemented into clients was wasteful, insecure and a bad user experience in general. Same with Java; you can't make the same tools that Java applets once provided through the browser because of the browser's security model, so I'd say the two never competed.
Making a quick interactive animation that works across all kinds of resolutions and sizes was trivial in Flash, but in HTML5 this is a challenge. HTML5 and friends fixed the problems that made web developers grasp at Flash for, like file uploads, animations and predictable interaction with the mouse and keyboard. These features were often already possible in browsers, but Flash was the only tool that made them appear the same in every browser available. They didn't replace the flash scene for games, interactive simulations and other online experiences. The Flash game scene pretty much died when Flash started getting blocked by Chrome, with only a small subset of the community fragmenting and finding their way to frameworks like Unity Web and its then plentiful competitors with high learning curves because they were designed for the "real deal" game developers rather than self-taught animators that turned game dev.
I think JS is a necessity for the web to exist today, but we need an alternative for what once was Flash, Java, Shockwave and more. Too many features have been shoved into HTML and Javascript that have no business there, left to be abused by trackers and hackers alike.
I don't see how it would. I think it would have led to something equivalent to JavaScript, because that's exactly the route we took to get to here. The WWW started as just documents, and there were plenty of protocols for other internet things. Businesses and consumers (and almost everyone else) want more than documents, and avoiding requiring people to install and run a separate client for every purpose (and requiring developers to build said cross-platform clients) led to plug-ins and then capable JavaScript.
Eventually, someone would try to ship everything to everyone through the internet, and they'll figure out a way. It's all just byte streams anyway. Perhaps something like java applet or Flash, or some worse version of "Click this to install our plugin".
The situation today of course is that the method that usually comes to mind when a person decides that something he or she has written should be put on the internet publishes what is essentially an executable for a very complex execution environment, and (except for a single non-profit with steadily decreasing mind share) the only parties maintaining versions of this execution environment with non-negligible mind share are corporations with stock-market capitalizations in the trillions.
E.g. for ssh, there's mosh (uses UDP to work around the control part of TCP).
Come to think of it -- everything I use is either stateless (http), or can use ssh for transport (ssh, sftp, sshfs, rsync, ...).
I'm sure some other protocols still break, but I haven't felt that pain in years!
Does it really need to take 5 seconds to load a website whose contents total 500kB on a 100Mbit/s connection with a 6-core CPU?
For example: a public index service (akin to DNS) where all pages upload all hyperlinks they were using. The end result is a massive graph that you can do PageRank on. You'd have to add some protections to avoid it getting gamed...
Email was the first decentralized social network and with it came bulletin board services and groups. Could these concepts have been developed a bit further or been a bit more user friendly while remaining decentralized?
Incorporating a time dimension to domains, such that it's explicitly recognised, and greatly restricting transfers, would be one element.
Ownership of domains should sit with the registrant, not the registrar.
Characterspace should be explicitly restricted to 7-byte ASCII to avoid homoglyph attacks. It's not a shrine to cultural affirmation, it's a globally-utilised indexing system, and as such is inherently a pidgen.
Other obvious pain points:
- BGP / routing
- Identity, authentication, integrity, and trust. This includes anonymity and repudiation. Either pole of singular authentication or total anonymity seems quite problematic.
- Security. It shouldn't have been permitted to be baked on.
- Protocol extensibility. Standards are good, but they can be stifling, and a tool for control. Much of the worst of the current Internet reflects both these problems.
- Lack of true public advocacy. It's deeply ironic that the most extensive and universal communications platform ever devised is controlled by a small handful of interests, none answerable to the public.
- More address space. IPv6 is a problematic answer.
- Better support for small-player participation. Servers are still highly dependent on persistence and major infrastructure. A much more robust peered / mesh / distributed protocol set that could be utilised without deep expertise ... well, it might not make things better, but we'd have a different problem-set than we face presently.
- Explicit public funding model for content, and a ban or very heavy tax on most advertising.
- A much keener, skeptical, and pessimistic early analysis of the interactions of media and society.
That said, an identity defined by a set of relationships, rather than a single pecuniary relationship with a registrar, seems more robust.
(One Laptop Per Child I underststand. Not its relationship to my comments.)
Within the transport network itself, localised dendritic trust relations (and corresponding transport flows) will all but certainly emerge. There might be some ad-hoc leaf-node communications, but standard, equipment, maintenance, etc., all favour some level of centralisation.
Note that "some level" != "complete and total".
Make it easier and more equitable to obtain addresses and ASNs.
Build protocol to make edge/cloud computing more fungible. Similar to folding@home but more flexible and taking into account networj connectivity rather than just CPU cycles. Probably looks a lot like Cloudflare Workers/Sandstorm but no vendor lockin.
DNSSEC only. TLS only for HTTP/consumer facing web.
Actually on the topic of that probably something simpler than TLS to replace TLS. It has too many features. x509 can stay but the protocol needs reworking for simplicity.
DNS is a horrid mess that should have been designed with ease of reading in mind. And I know that DNS was designed way before it, but I think a data transit format similar to JSON would have made the system a bit more extendable, and given people a chance to make it a more dynamic system.
E-Mail was brilliant in it's time, but for the love of all things explosive and holy is it bad. Just the fact that in it's base design there is no E2E encryption going on is a problem.
My biggest beef with the current internet is HTTP. Everything is built on it, and it isn't the greatest system. There have been so many systems and protocols implemented that did so many things, FTP/gopher/irc/etc, and most of them have gone the way of the dodo. A few hold-outs in the dedicated tech world will still use irc, but we could have done so much with cloud-based systems with FTP. And if we had a new spec for irc, would we need Slack/Discord/MS Teams/etc? They could then all talk to each other. We shouldn't be trying to reinvent the wheel, we should be using these older services in our platforms.
And don't get me thinking about cloud. The worst term that a marketing team got a hold of. At it's core, it's just somebody else's computer. And again, so much of it is build on HTTP protocols. Not many people know or remember that xWindows and X for *nix systems had a distributed system built in. Log into a server, set one environment variable to your IP address as long as you were running one of these systems yourself, and you could runs programs on the server with the GUI on your computer.
The reason we have all those separate systems is not that there are no alternatives: irc could have evolved with a new spec, but there is also XMPP (Jabber)... The reason is that all those systems like Slack/Discord/MS Teams do not interoperate with each other is that they are developed by companies that need to make money, and they want to force and keep users on their systems.
I think email is the only communication protocol that is still very popular and works across providers. I don't think it will disappear anytime soon. At this point, email providers cannot lock their users into their own system: no one can imagine that you'd be only able to email other gmail accounts from a gmail account or other microsoft accounts from a microsoft account.
I wish we could make new protocols at all.
this is mostly an artifact of how most firewalls are configured to only allow "neccesary" stuff; this also applies to ipv6 and hence all dreams of it re-enabling end-to-end connectivity are kinda moot.