[Standards] Advance XEP-0368 to Proposed
dave at cridland.net
Thu Jan 19 22:11:31 UTC 2017
On 19 January 2017 at 20:19, Travis Burtrum <travis at burtrum.org> wrote:
> Hi all,
> I am proposing advancing XEP-0368 from Experimental to Proposed, and the
> XSF MUC said to do this by sending an email to the standards list.
> It's been a bit over a year, no one has suggested any changes to me.
> There is at least one client implementation (Conversations), multiple
> servers supporting it with C2S (using sslh it seems, mostly), and one
> server supporting it for S2S (Metre).
> What's the next step? Any thoughts?
Council will vote on it. I'm inclined personally toward Last Calling.
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.
2) IANA registration is required for xmpps-client and xmpps-server SRV
3) Should we request IANA register 5223 and 5270 as 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"?
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?)
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
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.
More information about the Standards