[Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Travis Burtrum travis at burtrum.org
Mon Jan 30 17:52:01 UTC 2017

On 01/30/2017 12:43 AM, Daurnimator wrote:
>> 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'.

I guess those are both requirements and implementation instructions,
suggestions for different wording are welcome, but it seems clear to me.

> The phrase "is the SRV 'service'" seems confusing to me.

That's exactly the language the SRV rfc uses:


   Here is the format of the SRV RR, whose DNS type code is 33:

        _Service._Proto.Name TTL Class SRV Priority Weight Port Target"

It goes onto explain what a Service is, so I believe I used the correct
terminology there.

>> 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.

Yes we've discussed this sentence at length before, with people arguing
that is or is not completely correct.  I'm not sure how to concisely
word it (please, suggest!) but the points I was trying to make are:

1. 'Direct' TLS and STARTTLS after it's started are both identical, so
same level of security.
2. If ALPN is not used, STARTTLS leaks that the underlying protocol is
XMPP and 'Direct' TLS does not, it should look the same as HTTPS or
anything else.  If ALPN is used the fact that XMPP is going on under
this TLS stream is 'leaked' with 'Direct' TLS as well.
3. If RFC 7590 is not followed (summary: Send STARTTLS even if you don't
get an offer to combat STARTTLS stripping), then 'Direct' TLS is more
secure since it is not susceptible to STARTTLS stripping.

Maybe what should also be mentioned is:

4. Both 'Direct' TLS and STARTTLS are vulnerable to DNS tampering absent

> 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

I think I did cover this in the requirements:

1. Treat both 'xmpp-' and 'xmpps-' records as the same record with
regard to connection order as specified by RFC 2782, in that all
priorities and weights are mixed.

so SRV already specifies all your other questions.  As to whether the
DNS requests can be done in parallel, yes they can of course, but that's
up to the implementer.

Thanks for the feedback!

More information about the Standards mailing list