[Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)

Jonas Wielicki jonas at wielicki.name
Wed Dec 20 12:05:16 UTC 2017


On Mittwoch, 20. Dezember 2017 12:07:28 CET Georg Lukas wrote:
> Hi,
> 
> 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 §4.9.3.19. 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 
do.


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.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171220/05b9bd5e/attachment.sig>


More information about the Standards mailing list