Subject: [therightkey] Combining OCSP stapling with advance MITM preparation

From: Kai Engert <[email-masked]>
Date: Thu, 23 Feb 2012 20:55:19 +0100

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Feb 2012 14:10:24 -0600

Google's solution is to push CRLs directly to the client (well, the
client pulls CRL updates, but you get the point):

http://www.imperialviolet.org/2012/02/05/crlsets.html

I agree that a combination of OCSP Response stapling plus pinning of
the fact that the server does OCSP Response stapling would be nice.
That's not quite what you propose.  But in any case, it seems that
it's getting late for OCSP to come to the rescue, though I really hope
not.  IMO OCSP always wanted to be stapled.

Nico
--

---

From: Kai Engert <[email-masked]>
Date: Sat, 25 Feb 2012 18:22:26 +0100

> http://www.imperialviolet.org/2012/02/05/crlsets.html

If my understanding is correct that they are pushing only a subset, then 
there is the risk that important revocations are filtered. Any 
revocation event might be important.

If a trainee at a CA issues a test cert for www.important.site, then 
immediately revokes it, who decides whether that should be filtered or not?

Kai