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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
