[Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)
jonas at wielicki.name
Wed Dec 20 12:05:16 UTC 2017
On Mittwoch, 20. Dezember 2017 12:07:28 CET Georg Lukas wrote:
> when reading the Instant-Stream-Resumption Proto-XEP, I encountered
> this piece, which shows a deeper problem in 0198/6120:
> | The <isr-enabled/> element can optionally also contain a 'location'
> | attribute which specifies the preferred IP address or hostname, and a
> | TCP port number of the host which should be used for instant stream
> | resumption.
> | Note that the hosts announced by the 'location' attribute qualified by
> | the [ISR] namespace MUST be connected to using TLS from the beginning
> I see how this attempts to create a fast-path to the Direct-TLS port, as
> opposed to the STARTTLS 'location' of 0198 (which again is based on
> RFC6120 §22.214.171.124. see-other-host).
> I don't particularly like the 'location' mechanism in 0198, and by
> extension the one proposed in ISR, as they add tremendous complexity to
> the client due to breaking through multiple abstraction layers and
> introducing very interesting security challenges.
> However, I accept that there might be cluster deployments where such a
> feature is required, and I see the need for specifying the connection
> type, be it STARTTLS, Direct-TLS, BOSH or others for reconnecting.
> Nevertheless, the ISR-proposed way of implicitly encoding the connection
> type by the choice of which XEP carries the 'location' payload is not
> quite optimal.
Agreed-ish. Although I find that situation better than your proposed (b).
> This problem needs to be fixed either in RFC6120 or in 0198, not worked
> around from ISR. My strawman proposals for this would be:
> a) the server inspects the client connection type and returns the port
> for the same connection type in 0198/location, i.e. if the client
> connected via Direct-TLS to 5223, the server will return server:5223.
> This will obviously break clients that support Direct-TLS but fall back
> to STARTTLS in 0198. As Direct-TLS is rather fresh, the impact of this
> might be bearable, despite both specs being 'Draft'.
You’d still have to know which port is which, wouldn’t you?
> b) the server only returns the hostname, omitting the port, and the
> client uses the original (cached) list of ports to connect via its
> preferred method, allowing Direct-TLS resumption.
This seems worse, and more layer-breaking than what clients already have to
I think it would make more sense to specify the SRV-record field. This is a
standardized identifier which lets the client know how to connect. We have
that for Direct-TLS and STARTTLS (I don’t know about WebSockets or BOSH).
This still needs change in both specs.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards