Feedback requested: SVCB for XMPP
Hi all, Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP. Assuming attachments work on this list! Feedback welcome, I intend to submit this one shortly to the IETF. Dave.
Hi Dave! I've only briefly reviewed this so far, so please forgive if I've missed things, but I have some early comments: Major blocker I'm not sure can be addressed: 1. This essentially re-introduces the major security flaw that was addressed in XEP-0156 by removing the TXT record, just with a warning. Context: * https://web.archive.org/web/20220828222121/https://mail.jabber.org/pipermail... * https://github.com/xsf/xeps/pull/1158 * https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.h...) But all those points still remain, most importantly: * nearly no HTTPS clients/libraries/browsers actually support "connect me to domain X but send SNI Y and validate the cert against domain Y", I would argue it's too dangerous to even allow trying this Things easily addressed: 1.
"xmpps-server" and "xmpps-client" have a default port registered in this document. I don't actually see these registered. Also I'm generally opposed to this, because, whether we like it or not (and I know most of us do not, including me) it's 2024 and protocols are no longer multiplexed via port, but instead all go over 443 (TLS or QUIC) and are multiplexed via ALPN. Soothe yourself to sleep at night with the fact that this, combined with ECH, is actually a huge win for both connectivity and privacy, as intermediaries can no longer guess or police which protocol(s) you can use.
2. It mentions QUIC, and links to the XEP, but I don't see a way to indicate a QUIC connection? 3. Needs ECH, with HTTPS this is on the HTTPS record, where can it go here? I consider this absolutely required. 4. Semi-minor nit: StartTLS certainly doesn't preclude ALPN being sent, but I actually wouldn't define it at all here. legacy clients that don't support DirectTLS won't support this spec, and will look up StartTLS the old way, and 0 servers have support for StartTLS but not DirectTLS. Unless I'm missing some reason to keep support? 5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way. Thanks, Travis
This essentially re-introduces the major security flaw that was addressed in XEP-0156 by removing the TXT record, just with a warning.
Isn't this security flaw inherent to all possible discovery mechanisms for browser-based connection with domain delegation? Unless you can somehow trust the discovery information itself (via DNSSEC or if you decide to trust the CA in HTTPS, which we've seen recently demonstrated is an extra bad idea) the inability to validate post-fact remains present. I'm not saying "so let's just do it anyway" per se, but I'm actually failing to see a solution from inside a web browser that will work and mitigate the known risks. To use SVCB from inside a browser your only real option is DoH anyway which means HTTP which means trusting the CA system and I really don't know if we can do better. But maybe I'm just not thinking of something.
2. It mentions QUIC, and links to the XEP, but I don't see a way to indicate a QUIC connection?
Maybe because QUIC is still experimental, so probably not ready to be enshrined in an RFC, especially with WT coming.
3. Needs ECH, with HTTPS this is on the HTTPS record, where can it go here? I consider this absolutely required.
This seems unrelated since as you say even HTTPS doesn't put it in the SVCB record? In the future I expect we can use the HTTPS record for this since we're talking about things designed to work from in the browser and that's where the browsers will look for HTTP(bosh)/WSS/WT ECH anyway. We can't really spec a new place, we have to use the one the browsers already want, and that's the HTTPS record as you say.
5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way.
I would support deprecating bosh for sure.
On 2/13/24 11:30 PM, Stephen Paul Weber wrote:
2. It mentions QUIC, and links to the XEP, but I don't see a way to indicate a QUIC connection?
Maybe because QUIC is still experimental, so probably not ready to be enshrined in an RFC, especially with WT coming.
QUIC was published as RFC 9000 almost 3 years ago. [1] HTTP/3 (which goes over QUIC) is perhaps 30% of traffic at major websites. I'm not sure I would call it truly experimental at this point. Peter [1] https://www.rfc-editor.org/rfc/rfc9000.html [2] https://radar.cloudflare.com/
On Wed, 14 Feb 2024 at 06:18, Travis Burtrum <travis@burtrum.org> wrote:
Hi Dave!
I've only briefly reviewed this so far, so please forgive if I've missed things, but I have some early comments:
Major blocker I'm not sure can be addressed:
1. This essentially re-introduces the major security flaw that was addressed in XEP-0156 by removing the TXT record, just with a warning. Context: *
https://web.archive.org/web/20220828222121/https://mail.jabber.org/pipermail... * https://github.com/xsf/xeps/pull/1158 *
https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.h...)
But all those points still remain, most importantly: * nearly no HTTPS clients/libraries/browsers actually support "connect me to domain X but send SNI Y and validate the cert against domain Y", I would argue it's too dangerous to even allow trying this
I agree it's tricky, but HTTPS RRs (and SVCB for HTTPS) do introduce this requirement anyway, so the difficult part might be convincing the library that this is the same situation.
Things easily addressed:
1.
"xmpps-server" and "xmpps-client" have a default port registered in this document. I don't actually see these registered. Also I'm generally opposed to this, because, whether we like it or not (and I know most of us do not, including me) it's 2024 and protocols are no longer multiplexed via port, but instead all go over 443 (TLS or QUIC) and are multiplexed via ALPN. Soothe yourself to sleep at night with the fact that this, combined with ECH, is actually a huge win for both connectivity and privacy, as intermediaries can no longer guess or police which protocol(s) you can use.
I agree, but I think functionally it's simpler to use a default port here. (I've not done the various IANA bits needed in this draft yet, hence it doesn't exist).
2. It mentions QUIC, and links to the XEP, but I don't see a way to indicate a QUIC connection?
Good point; it'd need another ALPN identifier.
3. Needs ECH, with HTTPS this is on the HTTPS record, where can it go here? I consider this absolutely required.
The HTTPS RR is actually just a SVCB RR without the attrleaf (ie, the _xmpp that we have in this one), and this information implied by the type (66 instead of 65). So anything that can be in an HTTPS can be in a SVCB, and this includes ECH - but I do need to explicitly say it counts, and I'll do that.
4. Semi-minor nit: StartTLS certainly doesn't preclude ALPN being sent, but I actually wouldn't define it at all here. legacy clients that don't support DirectTLS won't support this spec, and will look up StartTLS the old way, and 0 servers have support for StartTLS but not DirectTLS. Unless I'm missing some reason to keep support?
I'd like to support StartTLS (and BOSH) if it seems relatively trivial to do so. I'm certainly aware of servers that don't support both (or do, but have it turned off). This is usually for all the wrong reasons, but still.
5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way.
BOSH is definitely trivial to support - just an additional path. It does work in some (sadly not rare) cases where nothing else will. BOSH is horrible, and I wish we just used WebSockets everywhere, but still. My focus is currently on things like Google App Engine, where you have a docker image that can only do HTTP/1.1, accessed indirectly via a load balancer that terminates TLS. The load balancer will do HTTP/2 and HTTP/3 - but because it's forwarding on as HTTP/1.1, you don't get the option of WebTransport, and instead only get WebSockets or BOSH. In some cases (the really cheap options), you don't even get WebSockets.
Thanks, Travis _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On 2/13/24 11:18 PM, Travis Burtrum wrote:
5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way.
Could we perhaps deprecate BOSH at this point? Peter
On Wed, 14 Feb 2024 at 15:14, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 2/13/24 11:18 PM, Travis Burtrum wrote:
5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way.
Could we perhaps deprecate BOSH at this point?
We can, though it's still useful in odd cases. That doesn't preclude supporting it here, though.
participants (4)
-
Dave Cridland -
Peter Saint-Andre -
Stephen Paul Weber -
Travis Burtrum