Use dkim public key for dns authentication challenge

[mmsc]

Hi;
Wouldn’t it be sensible to use the dkim dns record’s public key to encrypt the signed Let’s Encrypt Certificate (by the Let’s Encrypt Servers) then send this to the cerbot client.
The cerbot client could then decrypt the certificate with the dkim private key.

This would make automatisation possible and save us yet another manually administered dns entry.

Does this make sense?

Michael

[stevenzhu]

Hi,

Can you please elaborate your question?

For DNS validation, most DNS provider who has API can use API with scripts to automate the process.

Thank you.

[mmsc]

Hi;

As you said not all dns providers allow automatic updates. (Does 1and1.co.uk allow this?)

Nevertheless it is more an idea than a question. Email servers should nowadays all have a dkim dns record and it’s associated public key.

It could be used to authenticate my servers.

certbot client from my server sends request for signing to Let’s encrypt server.
Let’s encrypt server retrieves dkim public key for domain in certificate signing request.
Let’s encrypt server encrypts the signed certificate with the dkim public key and sends this back to my server’s cerbot client.
cerbot client decrypts this response into the signed certificate.

I hope that is clearer now.

Michael

[stevenzhu]

Thank you for your clarification.

I’m not sure if certbot can do this, let me ask an expert for this. @schoen

Thank you

[schoen]

In Let’s Encrypt terms, this is effectively proposing a new ACME challenge type (and a new DV validation method). This would have to be approved by the CA/Browser Forum and then by the IETF ACME working group. Instead of issuing and then encrypting a certificate under the DKIM key (which would allow an attacker who didn’t actually possess the DKIM key to cause spurious certificates to be issued and use up the victim’s rate limits!), we’d probably want a random challenge token issued by the CA to be signed by the DKIM key.

While this challenge type definitely appears useful in principle, I think we would want to see some evidence that mail servers have configurations that prevent them from easily using one of the existing validation methods.

[mmsc]

Obviously the power that be need to decide what is best for us, but as an email only server admin the choices for authentication are somewhat limited.
I understand TLS-SNI is out of the picture, using apache only for this purpose is not groovy at all, which leaves DNS.
It was mentioned that APIs exist for this purpose, but not all ISPs support it, and quite frankly I do not think that automatically updating DNS records for the sake of publishing a challenge token is a good idea.
Your idea to use a challenge token sounds good enough to me.
The signing server sends token to certbot client, certbot signs it with private key, the server checks response with public DKIM key.
This way the identity is checked before signing the CSR, which makes more sense.

As an afterthought: one could use the same principle with web servers as well. Instead of the challenge you have at the moment the host would publish a public key at a certain location before it initiates signing (and remove it when not needed). That sounds simpler to me.

[jsha]

Thanks for your thoughts! If you’re not running Apache on port 443, you can use Certbot’s standalone mode to satisfy TLS-SNI challenges, which may suit your use case quite well.

Reusing DKIM keys to validate domain challenges is a bit problematic for a couple of reasons:

• Common DKIM practice is to use short (512-bit) keys and rotate them often, since the assertions made by DKIM keys do not need to be secure over the long term. There have been some interesting cases recently of email leaks being authenticated by validating DKIM signatures, but there are some counter-points that those signatures don’t necessarily fully authenticate the leak.
• Reusing keys for different purposes across protocols can often introduce surprising vulnerabilities, so it’s not a best practice. For instance, Let’s Encrypt does not allow you to use the same public key for your certificates that you use for your ACME account.
• The CA/Browser Forum DNS validation requirements include a “freshness” requirement, meaning that the token provisioned to validate a challenge must be fresh within the last 30 days. A method that didn’t include this freshness requirement would be unlikely to pass.