Questions about Direct TLS versus STARTTLS

[stratself]

Hi, I'm considering selfhosting ejabberd to join the XMPP network, and hope this is the right place to ask about the protocol before proceeding.

I've noticed in RFC6120 that, with STARTTLS, the initiator sends unencrypted details about the initiating entity from and to information in the initial stream, and only upgrade to STARTTLS afterwards. This is before the <required/> child element is being sent back from the so ejabberd's starttls_required wouldn't make any difference. I consider this to be quite a sensitive metadata leak.

I've also seen the following on section 4.7.1 of the RFC:

Furthermore, if the client considers the
XMPP identity to be private information then it is advised not to
include a 'from' attribute before the confidentiality and integrity
of the stream are protected via TLS or an equivalent security layer.
However, if the client knows the XMPP identity then it SHOULD include
the 'from' attribute after the confidentiality and integrity of the
stream are protected via TLS or an equivalent security layer.

Given the information above I would like to ask: is my hypothesis is correct, that there is leakage of userinfo by using STARTTLS? And would exclusively using Direct TLS prevent this, as the TLS negotiation happens before any identity is sent over the wire? Also, are there any further security benefits of using Direct TLS? I've seen XEP-0368 indicating ALPN privacy, and I suppose this is because the xmpp-client/server is to be sent inside TLS' (encrypted) Server Hello, rather than in plain (?).

I suppose the answers can be found with Wireshark, but it's better getting confirmation from someone in-the-know.

I've also checked #1423 and the blogpost on TLS. The main reason that Direct TLS isn't recommended there is lack of SNI support and multi-domain deployments. I believe this does not apply to my use case as I'm looking to deploy a single-domain instance.

Hope for any answers, and thanks in advance.

[licaon-kter]

that blogpost is so old, the hammer swung back already...now DirectTLS is the best one

[prefiks]

With starttls only server address is sent unencrypted, username or auth information are sent only after encryption is already established. And until TLS1.3 this was also the case for direct tls, only this version did gain ability to pass hostname encrypted.

At this point starttls is just curiosity that was needed at a time it was introduced, it was used to allow to serve multiple domains from single ip address, when this was added to XMPP the only way to be able to serve tls traffic was single domain per single ip address (server could have just single certificate, and that limited it to single domain). Later tls was extended with SNI which made client tell server what domain it wanted to connect, and allowed server to choose what certificate to present - at this point you could have just direct tls that worked as good as starttls - but it still weren't more secure, domain name was still send in plain text. Only TLS1.3 (and i believe also not initially), had enough features to allow encrypting domain accessed, and with that direct tls expose less info than starttls.

[stratself]

Thanks for your response. I've decided to use v1.3-only Direct TLS for C2S, as most clients should support it. I think the ejabberd_s2s_in listen module supports Direct TLS too so that's nice. However, is my understanding correct that outgoing S2S is only STARTTLS (with mandatory-to-negotiate), because of the s2s_use_starttls option?

With starttls only server address is sent unencrypted, username or auth information are sent only after encryption is already established.

I believe your explanation differs a lot from RFC6120, where a JID is specified. Out of curiosity, has there been standards-level changes since then that strictly forces auth inside STARTTLS encryption? I'm not sure if RFC7590 applies because it's a recommendation.

Only TLS1.3 (and i believe also not initially), had enough features to allow encrypting domain accessed, and with that direct tls expose less info than starttls.

I believe SNI is still sent in plaintext even in TLS1.3, and only very recently does Encrypted Client Hello comes into play to encrypt this value. Is this the domain encryption you're mentioning, or are you referring to something else?

Thank you

[prefiks]

With starttls only server address is sent unencrypted, username or auth information are sent only after encryption is already established.

I believe your explanation differs a lot from RFC6120, where a JID is specified. Out of curiosity, has there been standards-level changes since then that strictly forces auth inside STARTTLS encryption? I'm not sure if RFC7590 applies because it's a recommendation.

Usually client don't send from="[email protected]" as in examples in rfc and only have to="server.com" (which is actually what's required). And then in next step they start tls, after which traffic is encrypted.

I believe SNI is still sent in plaintext even in TLS1.3, and only very recently does Encrypted Client Hello comes into play to encrypt this value. Is this the domain encryption you're mentioning, or are you referring to something else?

Yes this is what i was talking about.