Skip to content

Considerations & Issues

Winterhuman edited this page Apr 14, 2022 · 4 revisions

The IPNS-Link team has made many decisions on how and why we do certain things in certain ways, this page hopefully explains most of the considerations we have taken.

Considerations

Why are Gateways the connection initiators?

There are two reasons:

  1. Exposers can encrypt the ciphertext so only trusted gateways can know about the Listener, meanwhile, public Gateways have a domain and would need a traditional anti-spam system to mitigate attacks.
  2. If Exposers initiated the connection then only the Gateways they've contacted could access them, other Gateways wouldn't know how to contact the Listener without initiating the connection.

Why IPFS instead of Libp2p?

IPNS-Link relies heavily on many features that IPFS offers. For instance, IPNS provides proof of ownership as only the person with the Origin's keypair can publish the Manifest under the OriginID, IPFS provides offloading of static content away from the Origin thus reducing bandwidth usage, etc.

Issues

How do we prevent Gateway snooping?

Currently, Gateways can easily read what's being sent between the Origin and Browser as both the Libp2p and HTTPS connections terminate at the Gateway. We originally were going to solve this using TLS Passthrough in order to establish a direct TLS encrypted connection between the Origin and Browser, however, this turns out to not be a trustless solution as malicious Gateways can fake the interaction (See https://github.com/ipns-link/specs/discussions/3)

For now, we have no solution to prevent Gateway snooping. Instead it is recommended to not use Public Gateways for private information.

How we prevent DNSLinks from non-owners?

Currently, anyone could create a DNSLink from their domain to a random OriginID on a public Gateway, however, this can cause an excessive number of on-demand TLS certificates to be generated on the Origin's side during an attack. To prevent this, we can introduce a new JSON config for the Manifest stating what domain the DNSLink should have; if someone tries using their domain in the DNSLink then the Gateway would reject the connection, here's the discussion for this solution: https://github.com/ipns-link/specs/discussions/5