13 Feb
2024
13 Feb
'24
11:55 a.m.
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.
13 Feb
13 Feb
11:18 p.m.
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/pipermai…
* https://github.com/xsf/xeps/pull/1158
*
https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.…
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
11:30 p.m.
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.
14 Feb
14 Feb
8:13 a.m.
On 2/13/24 11:30 PM, Stephen Paul Weber wrote:
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/
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.
2:19 a.m.
On Wed, 14 Feb 2024 at 06:18, Travis Burtrum <travis(a)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/pipermai…
* https://github.com/xsf/xeps/pull/1158
*
https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.…
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.
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).
"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?
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8:14 a.m.
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
11:11 a.m.
On Wed, 14 Feb 2024 at 15:14, Peter Saint-Andre <stpeter(a)stpeter.im> wrote:
On 2/13/24 11:18 PM, Travis Burtrum wrote:
We can, though it's still useful in odd cases.
That doesn't preclude supporting it here, though.
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?
85
days inactive
86
days old
7 comments
4 participants
participants (4)
-
Dave Cridland -
Peter Saint-Andre -
Stephen Paul Weber -
Travis Burtrum