DNS-Persist-01: A New Model for DNS-Based Challenge Validation
1–10 of 164 posts
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#2I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that.
While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attack can commence. This also provides the ability to associate random found credentials back to the sites you can now issue certificates for if they're using the same account. This is free scope expansion for any breach that occurs.
I guarantee sites like Shodan will start indexing these IDs on all domains they look at to provide those reverse lookup services.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#3I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that. While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attac…
Exactly. They should provide the user with a list of UUIDs(or any other randomish ID tied to the actual account) that can be used in the accounturi URL for these operations.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#4I really like and hate this at the same time.
Years ago, I had a really fubar shell script for generating the DNS-01 records on my own (non-cloud) run authoritative nameserver. It "worked," but its reliability was highly questionable.
I like this DNS-PERSIST fixes that.
But I don't understand why they chose to include the account as a plain-text string in the DNS record. Seems they could have just as easily used a randomly generated key that wouldn't mean anything to anyone outside Let's Encrypt, and without exposing my account to every privacy-invasive bot and hacker.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#5I really like and hate this at the same time. Years ago, I had a really fubar shell script for generating the DNS-01 records on my own (non-cloud) run authoritative nameserver. It "worked," but its reliability was highly questionable. I like this DNS-PERSIST fixes that. But I don't understand why they chose to include the account as a plain-text string in the DNS record. Seems they could have just as easily used a ra…
Those who choose to use DNS-PERSIST-01 should fully commit to automation and create one LetsEncrypt account per FQDN (or at least per loadbalancer), using a UUID as username.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#6Ah, the next step towards True DANE!
We then can just staple the Persist DNS key to the certificate itself.
And then we just need to cut out the middleman and add a new IETF standard for browsers to directly validate the certificates, as long as they confirm the DNS response using DNSSEC.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#7I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that. While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attac…
The account is the same as you create in any acme client. I don't see potential for a reverse lookup.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#8I wonder why they switched from a super-secure-super-complex (in terms of operations) way of doing DNS auth to a super-simple-no-cryptography-involved method that just relies on the account id.
Why not using some public/private key auth where the dns contains a public key and the requesting server uses the private key to sign the cert request? This would decouple the authorization from the actual account. It would not reveal the account's identity. It could be used with multiple account (useful for a wildcard on the DNS plus several independent systems requesting certs for subdomains).
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#9Ah, the next step towards True DANE! We then can just staple the Persist DNS key to the certificate itself. And then we just need to cut out the middleman and add a new IETF standard for browsers to directly validate the certificates, as long as they confirm the DNS response using DNSSEC.
This decreases the salience of DANE/DNSSEC by taking DNS queries off the per-issuance critical path. Attackers targeting multitenant platforms get only a small number of bites at the apple in this model.
Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation
#10I wonder why they switched from a super-secure-super-complex (in terms of operations) way of doing DNS auth to a super-simple-no-cryptography-involved method that just relies on the account id. Why not using some public/private key auth where the dns contains a public key and the requesting server uses the private key to sign the cert request? This would decouple the authorization from the actual account. It would no…
The most common vector for DNS-based attacks on issuance is compromised registrar accounts, and no matter how complicated you make the cryptography, if you're layering it onto the DNS, those attacks will preempt the cryptography.