14 Feb
2024
14 Feb
'24
10: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