libp2p
feat: add WebTransport protocol
Description
related to #2993
Notes & open questions
Change checklist
- [ ] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] A changelog entry has been made in the appropriate crates
@dgarus Please ping me once you'd like me to take another look here!
@dgarus Please ping me once you'd like me to take another look here!
Hi! Ok. If you suggest a lib which we could use for deterministic cert generation, it would be great.
@dgarus Please ping me once you'd like me to take another look here!
Hi! Ok. If you suggest a lib which we could use for deterministic cert generation, it would be great.
I don't think there is one at the moment :(
In libp2p-webrtc, we solved the problem by letting the user pass a certificate in. That way, they can generate one and keep it around (like save it to disk). It would obviously nicer to generate one deterministically but if the choice is between requiring the user to pass one in and not being able to ship webtransport at all, I'd rather pick the former :)
@dgarus Please ping me once you'd like me to take another look here!
Hi! Ok. If you suggest a lib which we could use for deterministic cert generation, it would be great.
I don't think there is one at the moment :(
In
libp2p-webrtc, we solved the problem by letting the user pass a certificate in. That way, they can generate one and keep it around (like save it to disk). It would obviously nicer to generate one deterministically but if the choice is between requiring the user to pass one in and not being able to ship webtransport at all, I'd rather pick the former :)
Really, I don't like the idea of generating a cert deterministically because I think it's bad for security. What is the problem with fresh certs?
Really, I don't like the idea of generating a cert deterministically because I think it's bad for security. What is the problem with fresh certs?
Can you elaborate the security problem that you are seeing? The essence of the certificate is the private key that it is signed with. The node's private key should be sufficient to produce such a key via a HKDF.
The problem with "fresh" certificates is that they are useless unless you communicate the certificate hash to the remote who wants to connect. If we generate a new certificate every time on startup, all addresses that we have previously given out via identify or what other nodes have stored in their kademlia routing table are now useless.
Can you elaborate the security problem that you are seeing?
I thought about it one more time, and it looks ok. If someone gets the host's private key and saved TLS traffic, he can't decrypt it in any case.
Can you elaborate the security problem that you are seeing?
I thought about it one more time, and it looks ok. If someone gets the host's private key and saved TLS traffic, he can't decrypt it in any case.
If a peer's private key is exposed then we have bigger problems I think :) Pretty much every protocol builds on the assumption that the private key remains - well - private! So tying the certificate to the key just makes operation of the node easier (only one element to persist between restarts instead of two). Long-term, we should definitely achieve that!
@thomaseizinger Hi, Thomas!
this means we cannot share a listener on the same port for WT and regular QUIC connections.
What are your thoughts on sharing an endpoint rather than a listener? I just tried to find an endpoint with the same socket address and use it again.
Please take a look how I did a noise security handshake. I'm not sure that it's correct.
@thomaseizinger Hi, Thomas!
this means we cannot share a listener on the same port for WT and regular QUIC connections.
What are your thoughts on sharing an endpoint rather than a listener? I just tried to find an endpoint with the same socket address and use it again.
Please take a look how I did a
noisesecurity handshake. I'm not sure that it's correct.
@thomaseizinger Hi! Do you have time to take a look?
@thomaseizinger Hi, Thomas!
this means we cannot share a listener on the same port for WT and regular QUIC connections.
What are your thoughts on sharing an endpoint rather than a listener? I just tried to find an endpoint with the same socket address and use it again. Please take a look how I did a
noisesecurity handshake. I'm not sure that it's correct.@thomaseizinger Hi! Do you have time to take a look?
Sorry for the delay, I was on vacation! Will take a look now.
@thomaseizinger Hi, Thomas! Glad to see you. I'm going back to the PR on next week.
Btw @dgarus, if you want to push the deterministic certificate story forward: The next step would be to open an issue with ring to inquire about deterministic APIs. See https://github.com/rustls/rcgen/issues/173#issuecomment-1757092321.