with_root_certificates config API encourages CT validation in clients that may not receive regular updates

[jsha]

I briefly checked in from sabbatical on the latest state of the rustls 0.20 beta API. It's looking great. I wanted to give feedback on one specific thing: the inclusion of CT logs as one of the arguments for with_root_certificates.

The current API requires users to decide about CT logs, and I think the shape of the API encourages them to find some list of CT logs and include it. However, it takes great care to deploy a CT-enforcing app, in particular with regards to updates.

Right now the major CT enforcing clients are browsers, and they have autoupdates, plus logic that disables CT enforcement if the browser is not updated for a certain amount of time (18 weeks?). I think this is an important ecosystem safety measure, and I know the browser vendors would agree.

CT logs are retired much more frequently than root certificates. Browsers impose uptime and consistency requirements on the logs they trust. Many logs have already been disqualified for missing these requirements. Once the log is disqualified, the operator will usually shut it down, making it impossible to get new SCTs from that log. If you read the ct-policy list archives you'll find an example of a problem caused by deployed software (watchOS IIRC) that trusted a fixed set of logs, and wound up having to ask a log operator not to shut down an (expensive) log because of it.

Also, logs are now sharded annually. If a rustls user compiles a list of CT logs into their application today, there will only be shards available for the next few years, putting a hard limit on how long the application can continue to validate certificates. Certainly applications should be updated more often than that, but in practice many are not, and this is a sharp edge on the API that is likely to catch people by surprise, and also lead to pressure on CAs and log operators to do unusual things in order to help end users out of a bad situation.

My recommendation is that the main with_root_certificates API should not take an argument for CT logs, and should not perform CT validation, at least not without more significant warning of the risks. There should be an advanced API to enable CT validation, with a note that it is only suitable for applications where regular updates are guaranteed, and a built-in "stop enforcing N weeks after compile" option that is strongly encouraged.