[Standards] Advance XEP-0368 to Proposed

Travis Burtrum travis at burtrum.org
Tue Jan 24 12:54:32 UTC 2017


Thanks for the comments, I'll address these in-line:

On 01/19/2017 05:11 PM, Dave Cridland wrote:
> 1) SNI really needs to be a MUST rather than a SHOULD. It's the moral
> equivalent to having a "to" in the stream open for the pre-TLS
> STARTTLS case, which is also mandated as of RFC 6120.

That makes sense, I agree.

> 2) IANA registration is required for xmpps-client and xmpps-server SRV
> protocols.

Also registration of the ALPN protocol IDs is required also:

4 IANA registrations for 1 XEP, is that a new record? :)

> 3) Should we request IANA register 5223 and 5270 as default ports?

That's another issue I guess, this XEP at least doesn't have any concept
of default ports.

> 4) "TLS provides more security than STARTTLS", for example, in
> Security Considerations doesn't make sense - I think we need a term
> for immediate-mode TLS. What about "Immediate-mode TLS"?

That's as good as anything else I suppose, I might mention in a note
that this is 'like HTTPS' but otherwise I'm fine with that.

> 5) I think it'd be beneficial to point to RFC 2595 Section 7, and note
> that the rationales listed there have either become outdated, or else
> do not apply where SRV records are in use. For example, the URL issue
> is a non-issue with XMPP, where the URL scheme will not change
> irrespective of the record followed. (Also, it's always fun to cite
> any RFC mentioning ACAP, right?)

Yea I read through that and they indeed don't apply in this case at all.
 Where in the XEP should this be pointed out? and in how much detail?

> 6) Security Considerations should note that in the absence of DNSSEC,
> there is still a downgrade attack possible. (You can spoof the
> non-existence or incorrect Immediate-mode TLS records fairly
> trivially).

DNS spoofing/manipulation equally applies to regular STARTTLS SRV lookup
and this SRV lookup in the absence of DNSSEC, I suppose it wouldn't hurt
to mention it though.

> Incidentally, while I've coded up the S2S variant in Metre, I've not
> really tested it at all - if anyone else is up for implementing it
> than we can give it a bit of a whirl on interop.

Awesome! That's the first S2S implementation of this that I've heard of. :)


More information about the Standards mailing list