I've just sent the following message to Mozilla's dev-tech-crypto
mailing list, and I thought you might be interested, too.
While working on an updated paper of the MECAI proposal (which I hope to
post in the next couple of days), the following orthogonal idea came to
me. I don't know whether it is a new idea, or whether it has been
discussed/mentioned before.
Let's say the owner of a domain learns that a rogue certificate for
their domain has been issued, and is being controlled by an attacker.
(For example because of a user's report, who used any of the systems
that may help to detect a rogue certificate.)
The rogue certificate will be revoked, but because of today's reality of
incomplete revocation checking, the victim might be unable to perform
revocation checking and still be attackable.
The following idea only helps against those attackers who can only
temporarily control act as a MITM, who only temporary control the
network connection between a client and a server, such as users with
mobile devices, and may only help with sites that are visited frequently
by the user.
As soon as the certificate has been revoked, the domain owner is able to
obtain an OCSP response for the rogue certificate. The domain owner
could configure their server to include this OCSP response in all TLS
handshakes, even though this OCSP response is unrelated to the server
certificate actually being used.
If clients had a persistent OCSP cache, in particular bundled with a
persistent OCSP cache for all revocation events, then users/clients
could potentially learn about important revoked certificates in advance,
for the servers they frequently visit.
I believe this is an argument for getting OCSP stapling (and in
particular "multi OCSP stapling" as proposed by Yngve Pettersen)
implemented and widely deployed more quickly.
Actually, here is an expansion of this idea, not sure if it is practial.
We could invent a new communication protocol between servers and CA's
OCSP servers.
Servers could be allowed to contact (daily) each of the publicly known
CAs. The server could ask "do you know about any revoked certificates
for my server's hostname?". Assuming the CA has a database of their
incorrectly issued certificates, it could lookup the affected
certificates, produce a revocation OCSP response for each of them, and
send them back to the server. This way, information about compromised
certificates could be distributed automatically, only between the
parties that are really interested in such certificates.
Of couse, this "advance OCSP stapling" doesn't help if the user connects
to the system for the first time, or visits the system infrequently and
therefore doesn't have a chance to learn about the rogue certificate
early. That's where MECAI might be able to help.
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
