3 ms·

A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via C

A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

waheoo 6y ago
Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.
- gpm 6y ago
  It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/
  - tialaramex 6y ago
    However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange. That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...
- nyanpasu64 6y ago
  I heard perfect forward secrecy is intended to prevent decrypting past traffic.
paranoidrobot 6y ago
Less labour intensive for whom? Anyone using email validation now needs to click a link every month, or their cert goes away. I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains. Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.
- floatingatoll 6y ago
  Less labor intensive than requiring validation and deploying a new signed certificate every month.
yjftsjthsd-h 6y ago
One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)
gruez 6y ago
>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.
- majewsky 6y ago
  > you're probably also in a position to block the CRL response from going through Not if the certificate is OCSP-Must-Staple.

waheoo 6y ago

Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.

gpm 6y ago
It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/
- tialaramex 6y ago
  However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange. That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...
nyanpasu64 6y ago
I heard perfect forward secrecy is intended to prevent decrypting past traffic.

paranoidrobot 6y ago

Less labour intensive for whom? Anyone using email validation now needs to click a link every month, or their cert goes away. I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains. Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.

floatingatoll 6y ago
Less labor intensive than requiring validation and deploying a new signed certificate every month.

yjftsjthsd-h 6y ago

One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)

gruez 6y ago

>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.

majewsky 6y ago
> you're probably also in a position to block the CRL response from going through Not if the certificate is OCSP-Must-Staple.