moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

host-meta-2: Add overall reason and paramater explanation to rationale

Browse Source
This commit is contained in:
Travis Burtrum 2023-12-16 11:16:16 -05:00
parent 136875eb33
commit f02a263db0
Signed by: moparisthebest
GPG Key ID: 88C93BFE27BC8229
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
inbox/host-meta-2.xml
View File

@ -206,6 +206,7 @@ Access-Control-Allow-Origin: *
</section1> </section1>
<section1 topic='Rationale' anchor='rationale'> <section1 topic='Rationale' anchor='rationale'>
<p>At the time of this writing, connecting to an XMPP server requires at least 5 seperate fetches of data, and doesn't support half the things this XEP does. I don't find adding more fetches a sustainable path forward, hence definining one extensible method for all things going forward.</p>
<p>Here I will go through alternative solutions that were explored and explain their deficiencies and why they were not chosen.</p> <p>Here I will go through alternative solutions that were explored and explain their deficiencies and why they were not chosen.</p>
<section2 topic='Why not DNS?' anchor='rationale-dns'> <section2 topic='Why not DNS?' anchor='rationale-dns'>
<ul> <ul>
@ -231,6 +232,13 @@ Access-Control-Allow-Origin: *
<li>As stated in the section above, I find a JSON parser much less of a potential security vulnerability to have available than an XML parser capable of parsing host-meta.xml</li> <li>As stated in the section above, I find a JSON parser much less of a potential security vulnerability to have available than an XML parser capable of parsing host-meta.xml</li>
</ul> </ul>
</section2> </section2>
<section2 topic='Why do we even need these additional parameters?' anchor='rationale-params'>
<ul>
<li>SNI fixes a fundamental problem we have with current methods of secure delegation (XEP-0156 and DNSSEC signed SRV records), in that these enable certificate validation to allow a certificate if it contains either one of two names, the service name *or* the target name. But you can only send one name with SNI, and nothing indicates which to send! If you send the wrong one the connection will fail, this necessitates sending one and, if it fails, sending the other, which is of course less than ideal.</li>
<li>ECH allows encrypting SNI+ALPN on the wire and so is invaluable for privacy.</li>
<li>Pinned public keys are a better replacement for POSH (they don't need changed on certificate renewal which commonly happens every 60 days now), and an alternative to DANE which can't be used where DNSSEC is not available.</li>
</ul>
</section2>
<section2 topic='Misc' anchor='rationale-misc'> <section2 topic='Misc' anchor='rationale-misc'>
<ul> <ul>
<li>host-meta.json has an 'expires' key defined already, why 'ttl' instead? I was almost convinced to use this until I realized this means that the file needs served by a program that can update 'expires' dynamically on fetch, or at least on a schedule, and that is far more complicated and therefore less preferable than a simple ttl that never needs updated allowing clients to keep track of their own expiry.</li> <li>host-meta.json has an 'expires' key defined already, why 'ttl' instead? I was almost convinced to use this until I realized this means that the file needs served by a program that can update 'expires' dynamically on fetch, or at least on a schedule, and that is far more complicated and therefore less preferable than a simple ttl that never needs updated allowing clients to keep track of their own expiry.</li>