Certbot support for ECDSA certificates

While I agree rotating the keys periodically makes a lot of sense, new keys every renewal for short duration certs also pose several other problems. For instance, TLSA/DANE records normally should contain a digest of the certificate public key. Yes, you can set a mode to use the public key of the intermediate certs, and then enter their digests to separate DNS records, but this is suboptimal for many reasons:

  1. You need multiple records to cover if something happens to the current signing intermediate cert(s). I currently have 6 records for Let's Encrypt. As we know each DNS lookup is an incremental delay in resource loading and an incremental amount of data transferred.
  2. You are basically saying trust any cert issued by Let's Encrypt for the given domain. While it narrows the field, it does not prevent malicious users from issuing a fraudulent cert for your domain (if they somehow validate their request to the ACME back-end). The point of TLSA/DANE is to provide a chain of trust (Assuming DoH or similar is used) from the client device, through DNSSEC, TLSA records, to the TLS endpoint (be it a mail server, website, PBX or similar). TLSA/DANE can even be used with a self signed certificate to have it trusted by some browsers. Using the DANE-TA or PKIX-TA record types are essentially fallbacks for situations like Let's Encrypt where you don't know the public key in advance (and obviously can't provide the validation of a self signed cert).
  3. While the certificate lifetime for endpoint certificates should be short (under 6 months I believe is what Apple has decided now), they keys don't have to be. If the concern is people won't rotate their keys periodically, then maybe there needs to be a separate key expiry date built into certs, but a key expiry should be a longer term (and I think this was the main problem that longer certificate lifetimes was trying to solve back in the late 90's). Obviously if a key is compromised, the certs all need to be revoked, the key needs to be blacklisted and a new set of keys generated.
1 Like

I think you can easily generate your private key(s) well in advance.
Now, if that information (or subsequent CSRs) can be used to pre-populate your DNS records, then you have a simple working transition.
If you have to wait for LE to sign the newly keyed CSR, then I can understand your desire to minimize the frequency of taking such a step.

So my question is:
Can you pre-determine what your next DNS entry will be before LE returns to you a newly signed public cert?

2 Likes

Certbot explicitly supports key reuse via --reuse-key, which is hopefully useful for DANE.

As Osiris mentioned, #8254 is hopefully really, really close to being merged.

4 Likes

You can't (shouldn't) reuse a key forever!
What is the best/simplest way to introduce a new key?
[in the TLSA/DANE/worstcase scenario]

3 Likes

Key rotation was much, much more important when ciphersuites without forward secrecy were widely used, because then old server private keys could be used directly to read old traffic. Now that forward secrecy is common and routine, the benefit to key rotation is less obvious (although I think it still exists). We greatly reduced that benefit for the non-forward secret ciphersuite users by not making Certbot delete the old private keys. :crying_cat_face:

I guess our threat modeling wasn't explicit enough.

Anyway, I'm still happy that Certbot's default is to rotate keys—but I'm not confident enough of the concrete benefits of that behavior to try to pressure people not to use --reuse-key!

4 Likes

I agree. Unless I'm missing something (and I very well could be), forward secrecy pretty much negates the need to regularly rotate private keys unless you suspect compromise. The pressure to do so reminds me of the now defunct IT advise that users should be forced to regularly rotate their password. But it's been largely proven that caused more harm than good and as long as your password is long and you don't have a reason to believe it has been compromised (like being exposed in a breach), there's no reason to change it.

3 Likes

Quantum computing? Future compromise enough? As far as I know, ECDSA isn't quantum safe.

1 Like

I'm confused. How would rotating your key prevent issues with quantum computing or future compromise?

3 Likes

Hmm.. That's a good point. It doesn't :blush: If EDHE is compromised, rotating keys doesn't matter. My apologies.

2 Likes

One thing we should probably check on is whether the TLS servers are using genuinely ephemeral and not fixed DH shares.

I was surprised that I didn't know how to do this with openssl or gnutls-cli and even more surprised that neither seemed to have an option to do it.

I think it's something along the lines of

sudo tshark -T fields -e ip.src -e ssl.handshake.server_point -e ssl.handshake.extensions_key_share_key_exchange -Y '(ssl.handshake.server_point || ssl.handshake.extensions_key_share_key_exchange)'

(probably missing a field or two that could be relevant)

The output of that looks superficially OK to me (servers not reusing the same DH public key for subsequent negotiations) but maybe it would be good to know more about this topic. :slight_smile:

4 Likes

One thing we should probably check on is whether the TLS servers are using genuinely ephemeral and not fixed DH shares.

That might be something that could be added to the webserver plugins. Properly configure Apache, etc. to use a set DH size, and generate a new random DH key.

I'm not that familiar with fixed DH, but what I can find on Google is that you'd need specific "fixed DH certificates" for that? Could "fixed DH" even work with Let's Encrypt certificates?

What I meant in this case is that the server and client both have to send their own public Diffie-Hellman parameters as part of the key exchange process. The server could use the same one every time, or a different one each time. Part of the forward-secrecy property of Diffie-Hellman key exchange is that neither side should retain the secret parameter.

In the classic modular exponentiation setting

I'm talking about about reuse of the values this part calls b and B. The trouble with this is that if Eve later gets a copy of b, she can use A and b to calculate s. Therefore Bob ought to change B frequently and discard old values of b so that nobody can calculate old values of s.

I think this actually is the behavior of most current implementations, but I'd like to double-check that.

2 Likes

I suppose that's the "perfect" in PFS.

2 Likes

Ok but when you do decide to rotate the key (if and whenever that might be)...

2 Likes

I believe most clients that support key rollover generate a new key on their own just like when you create a new account and it generates a key. Or did I misunderstand the question?

1 Like

No, the question was abbreviated and separated from the context; so I suppose then you answered an incomplete/out-of-context question.
Here is some of that context (from above):

His issue includes DNS into the mix.

2 Likes

My bad. Ignore me. Too many different types of keys in the same conversation.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.