On 29 January 2017 at 04:26, XMPP Extensions Editor <edi...@xmpp.org> wrote: > This message constitutes notice of a Last Call for comments on XEP-0368 (SRV > records for XMPP over TLS). > > Abstract: This specification defines a procedure to look up > xmpps-client/xmpps-server SRV records (for TLS connections) in addition to > xmpp-client/xmpp-server and mix weights/priorities. > > URL: http://xmpp.org/extensions/xep-0368.html > > This Last Call begins today and shall end at the close of business on > 2017-02-11. > > Please consider the following questions during this Last Call and send your > feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Ehhh... I haven't personally ever had the requirement for it, and I think <starttls> is cleaner.
> 2. Does the specification solve the problem stated in the introduction and > requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, why not? I guess? it's quite simple to add support, so might as well... > 4. Do you have any security concerns related to this specification? > 5. Is the specification accurate and clearly written? No. The stuff in 'requirements' are not requirements but implementation instructions > When ALPN is used protocol MUST be 'xmpp-client' where 'xmpps-client' is the > SRV 'service'. > When ALPN is used protocol MUST be 'xmpp-server' where 'xmpps-server' is the > SRV 'service'. The phrase "is the SRV 'service'" seems confusing to me. > TLS provides AT LEAST the same level of security as STARTTLS, and more > privacy without ALPN as using STARTTLS leaks that the underlying protocol is > XMPP, while any TLS stream should be indistinguishable from any other TLS > stream. TLS provides more security than STARTTLS if RFC 7590 [4] This sentence is confusing and potentially misleading. > Your feedback is appreciated! I think it should be noted how devices are expected to connect. e.g. should they do a SRV request for xmpps-client, and if that doesn't exist: try xmpp-client; and if that doesn't exist: use an AAAA record. if that doesn't exist, use an A record? ==> can/should these dns requests be done in parallel? (perhaps see RFC 6555 Happy Eyeballs) It should cover desired behaviour if there is a xmpps-* record but no xmpp-* record _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________