-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Thijs, Travis, others,
On 06.11.2015 17:27, Thijs Alkemade wrote: > >> On 6 nov. 2015, at 14:15, Travis Burtrum <[email protected]> >> wrote: >> >> On 11/06/2015 05:28 AM, Georg Lukas wrote: >>> So lets assume I want to connect as [email protected] >>> <mailto:[email protected]> and the SRV record is >>> >>> _xmpp-client._tls.example.com <http://tls.example.com/>. IN SRV >>> 5 1 443 xmpp.example.com <http://xmpp.example.com/>. >>> >>> My client then makes a TCP connection to xmpp.example.com >>> <http://xmpp.example.com/>:443, requests xmpp.example.com >>> <http://xmpp.example.com/> via SNI, and the server is expected >>> to return the certificate for example.com <http://example.com/> >>> instead, which the client verifies? >>> >>> If this is the desired behavior, it must be stated VERY CLEARLY >>> in the XEP, as it is very unintuitive. >> >> Yes that's exactly how I intended it to work. The server >> operator would know which domain to serve which certificate for >> because they set it up that way. The plus side being this gives >> the server an easy way to route traffic (as opposed to just >> example.com <http://example.com/> being sent) and I can't see any >> negatives. >> >> It would make sense to explain it better and more thoroughly. > > One negative is that it would make things a lot more complicated > for shared hosting providers. If you create records like: > > _xmpp-client._tls.example.com. IN SRV 5 1 5223 xmpp.hoster.lit > > then it would be difficult for the hoster to serve the right > certificate if the SNI indicates only "xmpp.hoster.lit". They could > identify by port, or by wildcard DNS entries like > example.com.xmpp.hoster.lit, but that complicates the configuration > for example.com. > > (Sure, most existing XMPP hosting provides don't serve valid > certificates, but that's not a good reason to make it *harder*.) As an operator, I concur. It makes things harder: If I wanted to support XMPP over TLS, I would have to either (1) restructure all the SRVs and create host names somehow encoding the Jabber Domain being addressed -or- (2) restructure my certificates to cover all jabber domain names served by my XMPP service. (1) increases the maintenance cost of the zone file, especially if you don’t have any way to manage it automatedly (which is reasonable for small, relatively static zones), as well as the maintenance cost of TLSA records. (2) is even worse, it requires to re-issue certificates whenever I add or remove a Virtual Host, including the required transition times for TLSA records and so forth. While I can see the motivation for that idea, I think it does more bad than good. It kind of defeats the elegance provided by SRV and SNI (implemented in XMPP as `to` on the stream header) together. regards, Jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWP02dAAoJEMBiAyWXYliKPZkP/2Udad3n8nzafPW2Bc0ANilT OriqRq4wKOH0Aq1Z1n0RorE0fl4WMfSTRN264/Xpbv47MTnojmjIsgM8wkGhucnp ImsbdsMzGfwzZlpiYW93PCFl+hUF/VVGRiMD4rilEPHbSu4BF9LguqWCc0MK5mGf bWojeOwrkfJPlheFW/W5xtnR0UxQAXwin866UBsU+LM3J1ge3Euj0TzdPBFDS30o oFSyaFN7w1JA3GhRpwWRHCSe3/t+9zhpqY5K+XyokSSgs86YDVuxVlUnk1VfSozO 045KNI9+zySrI9UYqIGeWhmR4iK5fcTOA64YoyPom3a13xCyiEIjdOE7Q51JI5Do 1eqCgunkn67YMvN167WNwQH+YhB+JAC+Cs8OWSSWt67X50agQfl+h6Lp+2X0Aai/ GVTXyYoD3vx3DKhDqyj2EzX0FdpvzI4FPZffv1to8pPt2K1OMVBXaFXg1Zr7K3Cy DHQPYI6ZX4EdR/HEbTivdXNo4bhzwdh/nR0a7ge4jnhN7uCc3cMsLiKPnmp15bnZ sngW5AWqRlyhEEx/vUd1NJ7C5zcbV0uhoanbzt0aMfEpa29+zXAV3PyUfJ5maBXS DDiAWUkB0GmvTYbp4UHXvY4ypGBeDXobmP0PEjQ+jJcDqWFDn0v0RBa+TzkN1v5E bbe+C2HA9LYSEaP905ZP =hauf -----END PGP SIGNATURE-----
