4 ms·

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.

Someone1234 10y ago
> How does the 3 month cert limit stem from a much more complicated problem? Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months. Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.
- okket 10y ago
  > While a 2048 bit key is normally considered to take tens of years to break [...] FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA. http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ http://www.internetsociety.org/deploy360/blog/2016/03/lets-e... http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/ http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)
- dingaling 10y ago
  > A three months max duration limits the potential liabilities to three months. But what attack is that blunting? 1. A bad actor with access to the system will just regenerate another LE cert and carry on. 2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base. I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning. 90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.
eximius 10y ago
If you are able to get it working once, you're generally going to be able to automate it where the 3 month limit is irrelevant. Requiring longer time horizons stem from non-standard setups.

Someone1234 10y ago

> How does the 3 month cert limit stem from a much more complicated problem? Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months. Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.

okket 10y ago
> While a 2048 bit key is normally considered to take tens of years to break [...] FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA. http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ http://www.internetsociety.org/deploy360/blog/2016/03/lets-e... http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/ http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)
dingaling 10y ago
> A three months max duration limits the potential liabilities to three months. But what attack is that blunting? 1. A bad actor with access to the system will just regenerate another LE cert and carry on. 2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base. I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning. 90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.

eximius 10y ago

If you are able to get it working once, you're generally going to be able to automate it where the 3 month limit is irrelevant. Requiring longer time horizons stem from non-standard setups.