Deprecate STARTTLS

[lol768]

Has already been some discussion on this in #ircv3. I'm in favour of deprecating it for the reasons I outlined there, but happy to see more discussion on the matter.

---

It's been quite rightly pointed out I should elaborate on reasoning here, so:

• The upgrade message can be silently dropped by an active MitM. Some clients, which are purely opportunistic about the upgrade, will continue connecting in plaintext -- whereas a "proper" TLS-only connection would fail if an insufficient level of security could be established. @dequis has pointed out that this is addressed in the spec, but it still is subject to TOFU (vs e.g. STS preloading, or an explicit option to connect using TLS on port 6697)
• Whilst STARTTLS can provide some protection against a passive Eve, I feel that it's existence is harmful as it offers a false sense of security to users who may not fully appreciate the difference between STARTTLS and TLS (especially given the misleadingly named CAP key).
• We should be pushing STS instead (and preload mechanisms to prevent plaintext connections at the start). We should also push for TLS-only connections in the longer term.

[DanielOaks]

+1 on deprecating STARTTLS in favour of properly pushing STS instead. If we do go through with this, we should add some explanatory text into the spec itself as well, and some other cleanups.

[lol768]

This is a bit of a crappy explanation, and should be expanded with more reasoning.

[Herringway]

This article has a decent explanation of the issue as well as some real-world examples of attacks on STARTTLS in SMTP. I've also heard this attack referred to as STRIPTLS in the past.

[dequis]

While I agree with deprecating STARTTLS in favor of STS (we've been informally recommending against implementing it for a long while already), it should be noted that the current text of the spec covers downgrade attacks:

If the user agrees, all future connections to the server must use TLS via STARTTLS. If TLS cannot be negotiated, it is a hard error and the client must abort the connection. This is to make sure that the connection cannot be downgraded to plaintext by a man-in-the-middle once it has been established that TLS support is available.

It's more of an afterthought, in contrast to how STS was designed around persisting the policy, but it's there.

[Herringway]

Be sure to remove the STARTTLS rows from the support tables as well.
EDIT: never mind it seems to be done already

[grawity]

The upgrade message can be silently dropped by an active MitM. Some clients, which are purely opportunistic about the upgrade, will continue connecting in plaintext -- whereas a "proper" TLS-only connection would fail if an insufficient level of security could be established.

The problem is the opportunistic behavior itself, not the upgrade process. It's the same with TLS on separate port – you can equally have an opportunistic client that tries port 6697 and is forced to fall back to insecure by active MitM. (The only difference is that separate ports make it much simpler to implement a strict client, since it's the default behavior already.)

Regardless of that, I agree that STARTTLS on IRC doesn't offer anything useful compared to direct TLS and should be deprecated. It might be useful to reference RFC 8314 as part of the explanation.

[FauxFaux]

What would a server, which only wanted to speak TLS, offer on the plain port? I was expecting it to offer CAP negotiation, then drop the connection (hopefully the client displays the message) if the client doesn't request the STARTTLS cap. Maybe send one of the many deprecated REDIRECT opcodes?

(Similar to how many sites redirect http://example.com/foo/ -> https://example.com/foo/ , and if you don't redirect you're doomed.)

[Zarthus]

What would a server, which only wanted to speak TLS, offer on the plain port? I was expecting it to offer CAP negotiation, then drop the connection (hopefully the client displays the message) if the client doesn't request the STARTTLS cap. Maybe send one of the many deprecated REDIRECT opcodes?

(Similar to how many sites redirect http://example.com/foo/ -> https://example.com/foo/ , and if you don't redirect you're doomed.)

You can use sts with the port=6697 to redirect clients (and presumably close the connection. if they don't support it, they're SOOL just like if you dont implement starttls).

but a server should never advertise a plaintext port if you don't support it, imho.

[lol768]

Probably the best approach is what @Zarthus suggested along with a NOTICE explaining why the connection is being terminated (for clients that lack sts support).

[lol768]

I've expanded the explanation in the Markdown file a little to try and give some context around the deprecation. Thoughts welcomed

[Zarthus]

ping @DanielOaks, is there anything else needed here to progress this issue?

[lol768]

There's broad consensus here I think with regard to the change itself, and I've not received any further wording related suggestions.

Can we get this merged please @jwheare?