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/standards/2022-February/038759.html
* https://github.com/xsf/xeps/pull/1158
*
https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.html#(17)
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