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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
