TL;DR: Please support a challenge based on a self-signed certificate, generated by certbot and stored in DNS,
Hi folks,
AFAIU the DNS-01 challenge relies upon my own zone file stored at a well-known DNS provider. To identify my certbot as a blessed one it has to prove it knows the login or access token to my DNS provider to generate TXT entries in the zone file. The challenge can be modified using some additional static NS and CNAME entries, pointing to my private bind. DNS is used as a chain of trust.
Would it be possible to reduce the complexity of this setup by using a strong public key, e.g. a self-signed certificate, generated by certbot and stored as a static entry in DNS? certbot is the only one knowing the private key, i.e. it can still prove its identity based on information in the zone file. But it could prove its identity immediately, without waiting for some remote zone files being updated.
3.2.2.4.7 DNS Change
Confirming the Applicant’s control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for
either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is
prefixed with a Domain Label that begins with an underscore character.
If a Random Value is used, the CA SHALL provide a Random Value unique to the
Certificate request and SHALL not use the Random Value after
i. 30 days or
ii. if the Applicant submitted the Certificate request, the timeframe permitted for
reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of
these Guidelines or Section 11.14.3 of the EV Guidelines).
no. CA can't reuse it's value. it may be a public key, but it cannot be reused.
You misunderstood. The public-private key pair is just a matter of identification. It doesn't have to change for each identification. It can be reused, as you can reuse your passport.
The certbot establishes an https connection to letsencrypt, polls some unpredictable text provided by the peer, signs it using his private key, and sends it back to the peer. letsencrypt can verify the signature using the public key from DNS. If the signature is correct, it must have been signed by the expected certbot for this domain, because nobody else has the corresponding private key. Thats basic cryptography.
Point is that the private key is not transferred to some other place, so it doesn't get used up or something like this. The only thing that must be changed for each run is the text to be signed by certbot.
there is whitelist of validation method CA can choose from, (the link I given to you in upper post) and you can't invent a new challenge and expect LE to adapt. (it requires 2/3 of CA and 1/2+1 certificate consumer to amend the rule)
I'm afraid this just isn't true: it's forbidden by the Baseline Requirements posted by @orangepizza above. While I understand that in your proposal reuse of the key is the whole idea, this whole element just is forbidden.
That said, it is of course possible to suggest your proposal for a new challenge type, perhaps in a form of a ballot. However, I'm not sure how this is handled: can anyone suggest such a thing? Or does it need to be a member of the CA/B forum? Probably the latter and I don't know if LE is willing to do such a thing.
Also, not to be all negative here (I don't like to be the bearer of bad news): I do think your proposal is elegant! The use of a private/public key pair to make a static but also somewhat dynamic DNS entry (static public key, but dynamic due to the fact of random tokens being signed by the private key) is I think pretty smart. I'm just not sure if the "people at power" agree
It would however increase the complexity of validation a lot. For example, how would a CA know the certificate in DNS is not revoked? How do you check revocation status for self-signed certificates? And if you don't check the cert for revocation status, how would the CA know the private key hasn't been compromised? Et cetera.
It doesn't have to be an x509 certificate, but a reasonably strong key pair generated by certbot would do. If it gets compromised, then the user should tell certbot to create a new key pair and to wait, until the public part has been added to the DNS, replacing the old one. If letsencrypt doesn't like a weak key pair anymore, then it could simply refuse to proceed, until the key pair has been replaced.
I understand that I have no insight in the complex internals of running the letsencrypt organization, and especially how to keep confidence of the industry in the certificates provided. But time is right for the suggested extension.
Question: Does letsencrypt revalidate the DNS entries of the DNS-01 challenge, after the web certificate has been issued, but before it has expired?
A valid auth is good for 30 days, IIRC. If it's been longer than that, you'll need to complete a new challenge. Thus, you should expect that you'll need to create (and then destroy, after validation is complete) a new TXT record for every renewal.
But how would a CA know if a certain published key in the DNS is still trusted? Your idea suggests the CA should put ALL its faith in the client: the client determines if a certain keypair is still trustworthy and the CA just has to believe the client will replace a leaked private key.
That is something which would probably never float with the CA/Browser forum.
That's a rather bold statement in my opinion and warrants much more explanation than just the statement: semper necessitas probandi incumbit ei qui agit.
If I understand your question correctly...
The answer is NO.
Any DNS entry created to validate a certificate request is "consumed" at issuance; And never revisited.
It can remain in DNS or be deleted (preferred) - no one will ever ask for it again.
I see some similarity there in your proposal, if there is ever any compromise, it is up to the end user to request revocation. The fact that this method would use a private/public key pair for validation should not change anything regarding certificate revocation. Once "ownership" is proven, the "proof" itself becomes irrelevant and should no longer be needed nor used for any other purpose.
When the end user no longer wants certs issued for that key pair, they simply just need to remove it from their DNS zone.
On rereading this, your feature request seems similar to the idea of adding the LE account number(s) into DNS.
That idea being that as long as the LE account being used remains in the requested DNS zone, that LE account can make requests against that zone without any further required "proof".
[an LE account can only be used by a system that holds the private key to that LE account]
There is also talk of the added control of restricting the LE accounts that can issue certs to only those listed in the DNS zone.
[but like with all good things - we must wait... until it makes sense to everyone before accepted by anyone]
There are different kinds of 'trust' in these things. For this challenge, the DNS operator needs to answer a dynamic (= non-predictable) challenge defined by the CA.
In this challenge, the CA wants proof of control not proof of authenticity. This is a subtle but important difference. It is important to remember that control can be delegated (for example using CNAME). The control proof is performed by having the non-predictable value returned to the CA. An entirely static validation would remove this type of proof. I'm not saying that other challenges can't be done securely, just highlighting the current concept of the DNS-01 challenge.
The security of this proof depends on the presence/absence of DNSSEC and on the CA's resilience against network attacks. There is no "trust" in the NS or CNAME records in itself, as the CA is not validating the authenticity of these (well, except when they're DNSSEC-secured). It is simply validation of DNS control by the subscriber.
That said, the HTTP-01 challenge actually features a static/stateless mode, because you can simply respond with the challenge string from the request URL + account thumbprint. If this is deemed to be acceptable for control validation, some DNS challenge revolving around statically (or almost statically) putting the account thumbprint somewhere should provide similar levels of security.
There are certainly more challenges CAs could do than the three we currently have. Actually implementing them is a whole different story though - you need to get them checked thoroughly for any overlooked security issues (remember the SNI challenge?) and get them approved by your relevant issuance policies (e.g baseline requirements) and obviously write the code and documentation. All of this is significant effort and a potential new challenge should first demonstrate to be worth all of this.
What can this new validation method do that other methods don't/can't?
What does it improve?
What is an example use case that may greatly benefit from this new validation method?
To that last question I think I can add a possible benefited use case:
delegating DNS validation without allowing any DNS modifications.
Department Z of Company Y can be delegated DNS zone: Z.Y.tld by making one single permanent DNS zone entry - adding the LE account, or the public key, controlled by Department Z into their DNS zone.
Restating a few things that other responses may not have conveyed clearly:
LetsEncrypt will essentially only provide challenges that are standardized in an RFC and approved by the CA/B forum. A new challenge type requires a long, public process.
the ACME rfc requires a timely authentication of control. The method you suggested is essentially the same as constantly re-using the same DNS authorization challenge on every domain and renewal - which is prohibited by the RFCs. Wrapping a reused value with a cryptographic signature does not create a more secure mechanism - it creates a less secure mechanism because the value is reused.
While your suggestion could potentially add a cryptographic link that can provide an additional authentication measure to a given account/holder, it does so at the expense of other security and control concerns. For this concept to actually be secure (and conform to the RFC), the DNS record payload would be a cryptographic signature by the private key of a random value assigned by the server. This mechanism would be considerably more complex to implement by ACME servers and only add negligible improvements.
Forgot to add: The premise of LetsEncrypt and ACME services is to have automated systems that continually authenticate control and renew certificates in short intervals. The spirit of the RFC is to assume a domain is not under control of the requesting party, and revalidate control for issuance.
The proposed mechanisms invert that concept and assume a domain is under control of the requesting party - which would require that party to take action only to refute a claim of control. This creates an elaborate and automated system that essentially functions the same as offering long duration certificates - a concept that not only LetsEncrypt opposes, but virtually every browser vendor and large scale web technology company oppose as well.
I think I understand what you mean: The guy running the DNS zone is not the web server guy asking for a certificate via certbot. To obtain a certificate they have to work together.
From a users perspective, if LE asks for "showing control over DNS" it asks the wrong guy. This introduces a lot of additional friction, making it difficult to deploy LE, but only a valid receiver of a certificate can overcome this obstacle.
My point is, using the suggested crypto-based challenge, DNS and web browser guy have to work together, too. From the DNS guy's point of view this is a one-time action (add the public key to DNS), then he can forget about it. This is very similar to using acme-dns together with static DNS & CNAME entries. There is no big difference between a compromised key pair and a compromised host running acme-dns.
What I've gathered here, and over the past years of lurking the forum. It's pretty much a moot point, LE is prohibited from adding a new challenge type similar to what you specify. If they do so they will be immediately distrusted by all browsers / root programs and kicked to curb.
You will need to bring your proposal to the CA/B forum, where browsers and certificate authorities will discuss the measure, weigh the pros and cons, and then vote. If the vote passes then it may be implemented.
