On Wed, 14 Feb 2024 at 06:18, Travis Burtrum 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/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-le...@xmpp.org
>
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
