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

Reformatted and added Requirements and alternatives considered to HACX

Browse Source
This commit is contained in:
Travis Burtrum 2018-05-16 00:14:53 -04:00
parent 0d904db40b
commit 88db7daa58
1 changed files with 15 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
inbox/hacx.xml
View File

@ -38,14 +38,26 @@
<p>Various methods exist to connect to XMPP servers over direct TLS, &xep0368; defines SRV records, &rfc7395; defines websocket, &xep0206; defines BOSH. HACX defines a method to retrieve all of those along with optional extra information such as SNI/ALPN requirements and pinned public keys from a &rfc5785; well-known URI over HTTPS.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>Needs to look like HTTPS.</li>
<li>Needs to support all current and future XMPP connection methods through extensibility</li>
<li>Should be as simple as possible, all XMPP clients already have an XML parser, most have an HTTP client</li>
</ul>
<p>Several alternatives were considered to avoid writing yet-another-spec but they were all deficient in various ways:</p>
<ul>
<li>DOH (DNS-over-HTTPS) or DNS-over-TLS could be used to look up &xep0368; SRV records, but can't mix priority/weight with &xep0156; alternative methods, and can't support extra features such as domain fronting (arbitrary SNI/ALPN)</li>
<li>&xep0156; has a similar HTTP .well-known URL document, but since the XSF doesn't control the namespace we can't extend it with the extra required attributes to support weight/priority/alpn/sni and pinned keys, along with future methods. The business rules also state that it must only be used as a fallback which is in direct opposition of what HACX requires.</li>
<li>&posh; pins certificates instead of keys, and also explicitly allows other forms of authentication (like a cert issued by a trusted CA), which is incompatible with a network attacker that might control a CA</li>
</ul>
</section1>
<section1 topic='Protocol' anchor='proto'>
<p>HACX servers MUST use HTTPS. This means that
the HACX client MUST verify the certificate of the HTTPS service at
the source domain in order to securely "bootstrap" into the use of
HACX; specifically, the rules of &rfc2818; apply to this
"bootstrapping" step to provide a secure basis for all subsequent
HACX operations. HACX clients and servers MUST support and use
methods to increase the security of this HTTPS request using all available
means such as HPKP (&rfc7469;), HSTS (&rfc6797;), DANE (&rfc6698;), etc.
HACX operations. HACX clients and servers MUST support HPKP (&rfc7469;), HSTS (&rfc6797;), and DANE (&rfc6698;),
and SHOULD support any future standard that serves to increase the security of this HTTPS request.
</p>
<p>A HACX document is retrieved over secure HTTP in the
following way:</p>