search

csosto-pk / tls-suppress-intermediates

Suppress intermediate certificates in TLS
Other
0 stars 0 forks source link

Cache information in tickets to prevent incorrect ICA list failures #4

Open csosto-pk opened 2 years ago

csosto-pk commented 2 years ago

From @martinthomson

If we are talking about return visits to the server, the client doesn't even need to be involved. The server can pack whatever state it wants into the ticket and even if the ticket is not used, it can use that information. From a privacy perspective, this falls under existing mechanisms, so no new exposure. And no new protocol mechanism is needed.

csosto-pk commented 2 years ago

From @camshaft

So on a return visit, the client would still need to set the tls_flags bit but the server could determine given the presented ticket if it wants to send the full chain.

Do you think this is worth calling out in the draft? As in, recommending if servers support the tls_flags bit, they should also issue tickets to prevent the "false start" problem. Or do we take it further and say it's the server SHOULD only suppress CA chains as long as it has a mechanism to detect if the client's cached cert is correct or not, which could include ticket information?

Without a reliable detection mechanism, the failure scenario doesn't perform very well. For TCP/TLS 1.3 it would be 4 RTTs for the handshake (plus a TLS alert) and 2 RTTs for QUIC (plus a CONNECTION_CLOSE). The server also has to perform the ServerCertificateVerify step twice, once for the failed attempt, once for the successful one. But like you said, some experimentation may show it isn't a big deal in practice.

csosto-pk commented 2 years ago

From @martinthomson

As I've said before (I think) a lot hinges on the semantics of the tls_flags bit. I don't think that we can say that it means "I have all the intermediates I am willing to accept". That's a little too absolute for the web PKI as it stands. Right now, we (as a client) have knowledge of all the intermediates without technical constraints (like name constraints), which goes a long way, but an unqualified claim like that would amount to a lie for us.

I don't have stats on how often we'd fail as a result; I'd have to check with others. It might take a very long time to find out if we don't have metrics already.

We /can/ retry, but as you say it's a big performance hit that we'd only want to pay if we hit exceptional circumstances. My sense is that unconstrained intermediates isn't exceptional.

I am inclined to push for a semantic of "I have all the unconstrained intermediates that I'm willing to accept". Or maybe "I have all the intermediates from that I'm willing to accept, unless it's the WebPKI and then I only have unconstrained intermediates"' if someone wants to assert that enumerating all the constrained intermediates is a reasonable ask in other settings. A context-dependent interpretation is also possible, though that seems like a recipe for accidental interoperability failure. If we specify an automatic retry, that sort of thing becomes a latent performance bug, which I'd prefer to avoid.

csosto-pk commented 2 years ago

From @bwesterb

If I'm not mistaken, by default, Chrome and Safari currently require SCTs on a leaf even if the intermediate is name-constrained.

I'm gathering all non-expired non-MMD intermediates logged in CT now. I haven't downloaded them all yet[1], but so far there are 1537.