MSC4045: Deprecating the use of IP addresses in server names#4045
MSC4045: Deprecating the use of IP addresses in server names#4045
Conversation
turt2live
added
requires-room-version
|
I guess this could be useful to allow Matrix servers to run under NAT64/DNS64 (since that breaks IP literals) Also, there might be a way to still use IP literals if they use something like sslip.io. I'm new to the Matrix spec change process, please be patient with me. |
| algorithm when trying to make contact with the target server. However, a challenge arises due to | ||
| the specification's [requirement to use TLS](https://spec.matrix.org/v1.7/server-server-api/#tls): | ||
| getting a valid or useful certificate from a known Certificate Authority is effectively impossible. |
There was a problem hiding this comment.
This won't be the case in the near future: https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/
There was a problem hiding this comment.
Honestly, I feel as though that may just further justify this MSC's existence 😅 if it's easier to get certificates for IP addresses like that, then it's easier to create throwaway servers too.
Most rooms which use a moderation bot of some kind additionally ban IP address hostnames via server ACLs, but that hardly accounts for rooms which haven't discovered the need for a moderation bot yet.
I'm inclined to cite the blog post as a reason to land this MSC, and push it forward to FCP. Thoughts are welcome on the general direction of this MSC.
There was a problem hiding this comment.
I don't think I've ever seen a matrix user connecting from an IP address (likely due to the reasons mentioned in the MSC), so I don't really see any real benefit to banning raw IP addresses from participating. I wouldn't be surprised if this was the case for most people in the matrix federation, so maybe you should try to explain more what the benefits are to doing this.
There was a problem hiding this comment.
I don't really see any real benefit to banning raw IP addresses from participating
One benefit would be eliminating parsing ambiguities: matrix-org/matrix-spec#2090
Alternatively, what's the point in permitting it if it never happens in practice?
There was a problem hiding this comment.
Alternatively, what's the point in permitting it if it never happens in practice?
Careful, just because it's not commonplace in most of the federation, doesn't rule out that there could be small groups that may find this very useful in other parts of the world once certs for IP addresses become readily available.
And of course, in rooms where IP addresses are banned (as is the case for all of matrix.org's rooms afaik), I'm not surprised that you don't see IP addresses connecting. 😆 (plus ofc that it's very difficult to get a valid cert for an IP address atm)
|
I oppose this proposal for single reason: private networks. Pinecone, Yggdrasil, ZeroTier and other solutions use own end-to-end encryption and IP addressation. And that doesn't include air-gapped networks with TLS termination on-edge, where getting valid TLS inside the network is problematic. |
| handled by the [server discovery](https://spec.matrix.org/v1.7/server-server-api/#server-discovery) | ||
| algorithm when trying to make contact with the target server. However, a challenge arises due to | ||
| the specification's [requirement to use TLS](https://spec.matrix.org/v1.7/server-server-api/#tls): | ||
| getting a valid or useful certificate from a known Certificate Authority is effectively impossible. |
There was a problem hiding this comment.
Let's Encrypt now issues certs for IP addresses.
|
|
||
| If a server *does* somehow get a certificate for an IP address, the operator of that server can *never* | ||
| lose that IP address if they plan to continue communicating with the rest of the federated network. | ||
| Worse, the operator can intentionally recycle the IP address as a [DoS vector](https://github.com/matrix-org/matrix-spec/issues/386). |
There was a problem hiding this comment.
Hundreds of FreeDNS providers exist, aren't going away any time soon, and have been used as DoS vectors in the wild. Additionally, this is the same case with domains; under this logic, regular domains should also be deprecated.
| Worse, the operator can intentionally recycle the IP address as a [DoS vector](https://github.com/matrix-org/matrix-spec/issues/386). | ||
|
|
||
| Further, [server ACLs](https://spec.matrix.org/v1.7/client-server-api/#server-access-control-lists-acls-for-rooms) | ||
| already have a capability to ban bare IP address server names in rooms, and the vast majority of |
There was a problem hiding this comment.
So why not keep it that way? This seems like an unnecessary limitation, and is also only considering the public federation.
6 participants
Rendered
No unstable implementations known.