Issues with STS that need to be fixed

[kaniini]

These fixes should be made to STS:

• [ ] The effect of encountering an sts cap should not cause a TLS upgrade, this should be decoupled from the spec and handled differently.
• [ ] The STS "pinning" should explicitly only be accepted if:
  • [ ] the client has accepted the TLS connection (i.e. accepted the certificate)
  • [ ] the certificate is verifiable to a root stored in the client's CA bundle (creating a small bundle for IRC-specific use may also be interesting, not covered here) OR has explicitly accepted the certificate (hopefully after examining it)
• [ ] The client MUST have the ability to override STS, for example if it were erroneously set either on purpose by an attacker (with verifiable certificate, such as one signed for example, by CNNIC ROOT CA) or by accident by the admin
• [ ] The client MUST have the ability to ignore STS if explicitly configured to do so (to prevent false upgrades)

It is probably desirable to include RPL_REDIR as an upgrade mechanism, which can be provided as a hint that TLS is available. Such a specification should probably mention that RPL_REDIR which violate STS policy if pinned SHOULD be ignored. Once a TLS connection is made, then the STS pinning can be presented and placed into effect if the TLS connection is valid.

[jwheare]

Thanks.

The effect of encountering an sts cap should not cause a TLS upgrade, this should be decoupled from the spec and handled differently.

At the moment the spec uses just one CAP for both the upgrade redirect (the port key) and the pinning (the duration key). These are two separate mechanisms that trigger separate client behaviour. They are combined in one syntax, but they do not need to be, but I don't feel like it's a major point of contention as the distinction is clearly defined in the spec.

What are the pros and cons of combining them vs using a separate numeric e.g. RPL_REDIR? It's worth noting that the redirect should take place as soon as possible in the connection phase.

The STS "pinning" should explicitly only be accepted if: the client has accepted the TLS connection (i.e. accepted the certificate) the certificate is verifiable to a root stored in the client's CA bundle (creating a small bundle for IRC-specific use may also be interesting, not covered here) OR has explicitly accepted the certificate (hopefully after examining it)

This is covered in the spec

• "Clients MUST use sufficient certificate verification to ensure the connection is secure without any errors."
• "If the client receives the duration key on a non-secure connection, it is invalid and MUST be ignored."

The client MUST have the ability to override STS, for example if it were erroneously set either on purpose by an attacker (with verifiable certificate, such as one signed for example, by CNNIC ROOT CA) or by accident by the admin

Browsers have this ability. It could be included in a non-normative section as advice for clients, along with heavy warning that it not be a simple "click through the warnings" UI, as it is in HSTS section 12.5 (The whole of section 12 is non-normative)

The client MUST have the ability to ignore STS if explicitly configured to do so (to prevent false upgrades)

If a server is persistently advertising a false upgrade and a user has realised enough to change a setting in their client to ignore STS, a MUCH safer course of action would be to stop connecting to that server entirely. I don't know if allowing a user to disable the feature entirely makes sense.

It is probably desirable to include RPL_REDIR as an upgrade mechanism, which can be provided as a hint that TLS is available. Such a specification should probably mention that RPL_REDIR which violate STS policy if pinned SHOULD be ignored. Once a TLS connection is made, then the STS pinning can be presented and placed into effect if the TLS connection is valid.

There isn't really a practical difference between using RPL_REDIR and the port key of the sts CAP as specced. As such, either are acceptable, so I don't see a need for a change just for the sake of it, unless there is a sufficient difference that I'm overlooking. Both will require work on behalf of a client to support correctly with new special requirements, and it's not a numeric that isn't broadly implemented anyway, so the reuse argument is somewhat negated.

[jwheare]

I realise there is some confusion around the dual purpose sts CAP. It is used both as an upgrade redirect from insecure to secure (the port key), and separately, on secure connections only, as an announcement of the sts policy (the duration key). This is arguably an inelegant solution, designed to avoid CAP proliferation.

However, there is no other way to perform the redirect at the moment, and after thinking some more, RPL_REDIR is inappropriate, because:

a) It apparently has no mechanism for specifying secure transport, only hostname and port. b) It's not in any spec, and we don't know how clients currently interpret it, so it can't be relied upon to be backwards compatible, if e.g. we specified that the hostname include ircs:// or a secure flag be added to the info parameter.

So instead, a more elegant proposal might involve:

1) A redirect CAP, decoupled from sts, that serves as a properly defined version of RPL_REDIR, and allows specifying, host, port AND security. This would be useful independently of sts, e.g. in the current situation I'm seeing with IRCHighway. This could be defined as a separate spec, that sts would depend upon. 2) Given duration is ignored unless it's received on an already secure socket, we could even move it to ISUPPORT, as it no longer needs to appear early on in the handshake. This would limit the number of CAPs that do not need to be REQed.

The argument remains that a redirect CAP is an odd and inappropriate use of CAP, as it isn't REQed, however, it is guaranteed to be backwards compatible with existing CAP negotiation code. If we instead introduced a dedicated command, e.g. REDIRECT, would we need to bump to CAP LS 303 to avoid client errors? I'm not sure how big of an issue this is.

[ghost]

I have authored an alternative proposal which maintains user choice.