Server active participation

[csosto-pk]

The biggest issue brought up about the ICA suppression draft was the potential failures with client that has not gotten the latest CCADB ICA list (https://www.ccadb.org/resources ). In that case the client would need to retry without requesting ICA suppression. I do not consider this a big issue to be honest, but the WG did not like the extra slowdown and state management.

After David B. and Bas’ Merkle Tree Proposal draft-davidben-tls-merkle-tree-certs, I started thinking. Their draft introduces a “snapshot in time” concept. If the client does not have the correct snapshot in time the connection will not use this mechanism. That prevents corner case failures when the client does not have the proper up-to-date to tree.

So, what if we used a similar concept? The Compact TLS draft (https://datatracker.ietf.org/doc/draft-ietf-tls-ctls ) uses it too. We can assume there is a dictionary of ICA certs that both the client and the server are aware of. The one we have available now is the CCADB ICA database, but there could be more in the future. When the client wants to use suppression it uses the TLS ICA suppression flag and the RFC7924 “cached_info” extension to convey the “snapshot” of the ICA dictionary to the server. That way the server can rest check if its chain was in there or not and send it back. if it should send back the chain or not.

That way there would be no failures due to stale cache, but we have two new assumptions:

• the server regularly pulls down the ICA DB so it knows if its cert chain is included there. This is similar logic for the subscriber in draft-davidben-tls-merkle-tree-certs.
• we update RFC7924 and use “cached_info” extension (only when it is used with the TLS ICA suppression flag) to include a different hash instead of the server cert hash defined in RFC7924.

The idea is for the ICA suppression draft is to be more general. draft-davidben-tls-merkle-tree-certs can be more optimal in terms of size, but I think it could be deployed easier for WebPKI instead of other uses. But the ICA suppression could be more general for B2B PKIs or other non-web usecases where a ICA dictionary is easily possible and does not get updated daily.

[csosto-pk]

Setting up the ICA DB could be a config line in nginx to configure a starting ICA list for those that can says it is a static list they control. And there could be an optional config line to pull down the “updated CCADB ICA list” daily. Nginx offers configurations that call into the TLS library today, so I don’t consider it too bad.

[csosto-pk]

The Merkle draft cert_type and TA extension could be used to negotiate the “dictionary” too. I was thinking to abuse the RFC7924 extension and the TLS flag because I always saw it as hard to convince the TLS WG to develop a new extension, but this could work too.

[csosto-pk]

As Bas pointed out

In a sense, it would be natural for the TLS library to provide the functionality, but for the server to explicitly enable it. That, however, requires changes to every single piece of server software.

Having the TLS server do it by default would also probably not fly: that would be surprising behavior.

I think the ACME client is the best target here.

[csosto-pk]

Another good counter-point by Bas was that OSCP which requires for servers to actively probe a responder ocassionally didn't get much adoption in servers

OCSP staples require similar effort to deploy and in the end don't see any real world usage apart from Cloudflare AFAIK. Perhaps ICA suppression has a clearer performance benefit compared to OCSP staples, so it will get adopted even requiring changes to servers, but it does still worry me.