plaintext-policy

[syzop]

I have no idea if you guys find this CAP useful or not. Right now we have this implemented as unrealircd.org/plaintext-policy.
If others find it useful then we could make it an IRCv3 draft and once accepted I will of course rename the CAP accordingly. If not, no problem at all. I understand it only has a limited purpose.

Here it goes:

The plaintext-policy capability allows a server to inform clients about the policy in place with regards to any users, ircops and servers that do not use an SSL/TLS connection.

Syntax:
unrealircd.org/plaintext-policy=user=<POLICY>,oper=<POLICY>,server=<POLICY>

Example:
unrealircd.org/plaintext-policy=user=allow,oper=warn,server=deny

There are 3 categories of clients: user, oper and server.
Each of them may have any one of the following policies:
allow: allow the connection in without warning
warn: allow the connection but warn about the lack of SSL/TLS
deny: deny the connection (or in case of 'oper', deny the /OPER attempt)

For UnrealIRCd-specific configuration, see:
https://www.unrealircd.org/docs/Set_block#set::plaintext-policy

The CAP is informational only and not REQ'able.

The purpose of all this is that clients can receive more information about the security policy of the server.

Right now it's meant purely informational, but we could ask client developers to parse it and for example prevent an /OPER attempt in case of policy oper=deny.

[jwheare]

Thanks for posting this here, this looks really interesting. Not sure if you saw my comments in the unreal-devel channel. In terms of a client-facing piece of information, only the oper= seems like something a client could act on, and it could probably be presented in ISUPPORT instead of CAP. For user=deny I'm assuming the connection immediately exits with an error message, and server= isn't relevant to clients.

sts is a CAP because it allows the client to upgrade the connection at the earliest possible stage, but clients running OPER on connect should probably be waiting until 005/motd has arrived.

Any other reason this should be a CAP?

[SadieCat]

I like the idea of advertising the plaintext policy to clients but i'm not sure about the usefulness of "warn" value (clients should do this for plaintext connections regardless) and for the "server" key (CAP is C2S/S2C only and clients don't need to know about this).

We could also add policy entries for the following things:

• Logging into the server with PASS
• Logging into/creating a user account.

[syzop]

@jwheare: sorry had not seen your message. Thanks both for the feedback, so quickly!
The "usefulness" of server would be that clients can see the security policy in place, if this is server=allow then that may give you some doubts about the network. The link-security thing does something similar (but not the same).
The reason for advertising this early is that the client knows the security (policy) of the server before connecting fully. Clients could present the information to the user and/or abort the connection. Or, as @SaberUK made me thinking: one might not want to do SASL (or PASS) in case of server=allow. Now whether this will actually happen I don't know, but.. that's why it is shown so early.

[Zarthus]

I like the idea of servers being transparent in their configuration (to some degree), even though hardcoding it to a different value would remain trivial.

[syzop]

Just going through some old issues today...

Do others still find this interesting enough for a specification to be made? Like @SadieCat, would you use this or something like it for InspIRCd? And client coders, what about them? After all, if client coders don't do anything with it then the usefulness is pretty limited.

Maybe by now, with more networks switching off port 6667, it is not so relevant any longer?