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