search

publicsuffix / list

The Public Suffix List
https://publicsuffix.org/
Mozilla Public License 2.0
2k stars 1.2k forks source link

add libp2p.direct #2084

Closed aschmahmann closed 1 month ago

aschmahmann commented 1 month ago

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

Submitter affirms the following:

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

Description of Organization

Interplanetary Shipyard is an engineering collective of the core maintainers of the most commonly used IPFS and libp2p implementations and public goods infrastructure.

The libp2p project enables universal connectivity between nodes across different network positions by supporting a wide range of transport protocols.

I am one of the directors of Interplanetary Shipyard and I am submitting this on behalf of Interplanetary Shipyard which will be operating the infrastructure in support of the libp2p project.

Organization Website:

https://libp2p.io/

Reason for PSL Inclusion

We are seeking inclusion in the PSL for per-user origin isolation and security.

We are giving distinct subdomains to libp2p users, basing them on their peer identifier (roughly a cryptographic hash of a public key) that will look like <peerID>.libp2p.direct. As a result, foo.libp2p.direct and bar.libp2p.direct are owned by different users, similar to how various web host subdomains work.

The main use of these domains will be exposing Secure WebSockets and HTTPS listeners, for improving connectivity options for libp2p nodes running in Secure Contexts on the web.

We have no purpose for PSL inclusion other than per-user isolation of HTTPS and Secure WebSockets permissions and connection limits in browsers.

In particular, we've already been discussing rate limit increases with Let’s Encrypt and while we were planning on waiting to apply here until after being granted an increase they were sufficiently convinced that we would get approval here that pre-granting us a rate-limit we would get anyway would be a waste of time on their end. This submission is not aiming to circumvent those limits.

We understand that libp2p.direct will have to keep registration terms longer than 2 years to remain in the PSL. As of this submission, libp2p.direct expires in 2027, and checking + renewing their registrations is something we do regularly for the domains of the various public infrastructure projects and websites we maintain.

Number of users this request is being made to serve:

The libp2p.direct service is one we are providing to the libp2p community (https://libp2p.io/) as a whole, however our first integration is into go-libp2p and the most popular IPFS implementation (https://github.com/ipfs/kubo). There are hundreds of thousands of libp2p nodes in the wild and while many wouldn’t benefit much from a certificate, a whole lot would. IPFS’ Amino DHT alone has tens of thousands of publicly reachable server nodes (stats) which could benefit from having individual per-peer domain names and certificates. However, even giving those tens of thousands of nodes per-peer domain names and certificates would enable millions of users to interact with those peers from browser environments.

There are no past issues or PRs relating to these PSL entries.

We do operate the dweb.link IPFS Gateways on behalf of the community which was added to the PSL in https://github.com/publicsuffix/list/pull/766.

DNS Verification via dig

$ dig +short TXT _psl.libp2p.direct @8.8.8.8
"https://github.com/publicsuffix/list/pull/2084"

$ dig +short TXT  _psl.libp2p.direct @1.1.1.1
"https://github.com/publicsuffix/list/pull/2084"

Results of Syntax Checker (make test)

============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
simon-friedberger commented 1 month ago

The main use of these domains will be exposing Secure WebSockets and HTTPS listeners, for improving connectivity options for libp2p nodes running in Secure Contexts on the web.

I'm lacking the background here. If this is mostly used by libp2p, what exactly is the browser isolating for you?

aschmahmann commented 1 month ago

Thanks @simon-friedberger for the quick response.

Let me know if you need anything else on my end

groundcat commented 1 month ago

Checks:

Expiration (Note: Must remain >2 years at all times):

The domain name libp2p.direct has a registry expiry date of 2027-02-23T06:20:26Z, according to WHOIS records, indicating it is currently in good standing. Please ensure it is renewed in the coming years to maintain a validity period of more than 2 years at all times.

DNS _psl Entries (Note: Must remain in place):

The DNS entries appear correct based on checks with multiple public DNS servers. Please ensure they remain in place at all times in the future.

Sorting:

The sorting appears to be correct.

Basic Security Check:

VirusTotal observations obtained show all clear.

Email:

A nonpersonal email address is used.

simon-friedberger commented 1 month ago

Browser vendors, such as Chromium have internal limits on the number of concurrent resources such as connections or objects per origin and usually separate limits for all origins sharing the same eTLD+1

Is this for libp2p running in the browser then?

simon-friedberger commented 1 month ago
aschmahmann commented 1 month ago

Is this for libp2p running in the browser then?

Yes, this is to support libp2p in the browser. Technically <peerID>.libp2p.direct addresses will be assigned to non-browser nodes, and browser libp2p nodes will connect to them over Web APIs such as the WebSockets API. libp2p nodes running in the browser context do not have access to raw TCP and UDP ports, and can only use transports provided by Web APIs.

simon-friedberger commented 1 month ago

This sounds a bit odd, I would expect something like this to authenticate with things other than TLS and cookies since you're already using a fairly opaque ID and therefore, there must be some other channel that communicates who to talk to, right?

Edit: Feel free to point me at some docs. :)

aschmahmann commented 1 month ago

Fundamentally the problem is that in order to do any kind of networking activity in a web browser you need to use one of the Web APIs supported transports. These include:

So realistically, in order to deliver connectivity to users in web browsers today having TLS certs signed by a CA is an important part of the story. While we realistically need these domains and certificates to improve the usability of peer-to-peer tooling in browsers today, we are continuing working with groups like Igalia and browser vendors to improve the story for peer-to-peer networking and self certifiable addressability on the web.

You can see more at connectivity.libp2p.io and learn more about the specifics with Secure WebSockets.

I would expect something like this to authenticate with things other than TLS

To go a little more into the details here, the CA certificates (and TLS processing of them by the browser) are not relied on by users for authentication since the PeerIDs enable self-certifiable authentication without relying on the operators of the libp2p.direct DNS for connection authenticity. Instead what will happen today with a Secure WebSocket libp2p connection is that there will be a second security handshake (using TLS or Noise) that leverages the PeerID and is accessible to the javascript in the browser.

there must be some other channel that communicates who to talk to, right?

This is frequently true and many users discover the addresses associated with a given peerID with routing systems such as the Amino DHT (based on Kademlia - libp2p kad spec), Peer Exchange based on a pubsub topic, or putting the routing system behind an API like https://specs.ipfs.tech/routing/http-routing-v1/. However, to interact with a system like the Amino DHT from a web browser we run into the same bootstrapping problem. How can you talk to the DHT nodes without a compatible transport?

This is what brings us back to needing per-peer domain names and certificates.

Thanks, and let me know if any other information is needed.

Side note: I see on GitHub you work at Mozilla, independent of this PR if there’s interest in making this self-certifiable addressing more natively usable in browsers definitely hit me up. My email is visible in my profile.