Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-Persist-01: A New Model for DNS-Based Challenge Validation

letsencrypt.org

Post reply on HN
Print view View original

141–150 of 164 posts

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#141

Post by plagiat0r »

pepdar wrote: post #129

I'm one of the draft authors. Several questions here touch real design tradeoffs — addressing the main threads: Why account URI instead of a public key in the record? (micw, 9dev, csense) Three reasons: 1. Key rotation without DNS changes. dns-persist-01 exists because DNS updates are expensive. Embedding a public key forces a DNS update on every key rotation — the exact problem this method solves. The account URI su…

Thank you, this draft is literally perfect and I wish we had this years ago. Most people don't know about acmev2 account rekeying either. It is great you decided to use account uri instead of public key thumbprint.

Recently I wrote a simple acmev2 tool specifically for manual upfront acmev2 account creation, rekeying and getting TXT records on stout for dns-persist-01:

https://github.com/pawlakus/acmecli

It also helps with stateless http01 printing thumbprint...

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#142

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #96

Is it false that DNS requests sent from LE to authoritatuve nameservers are unencrypted

Answer: "Yes, standard DNS queries are unencrypted. The threat model relies on MPIC - querying from multiple vantage points - not transport encryption. DNSSEC adds an integrity layer where available."

https://news.ycombinator.com/item?id=47073054

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#143

Post by plagiat0r »

chaz6 wrote: post #38

Is it possible to create an ACME account without requesting a certificate? AFAICT is is not so you cannot use this method unless you have first requested a certificate with some other method. I hope I am wrong!

Most acmev2 clients create account on certificate request.

That is precisely why I wrote this: https://github.com/pawlakus/acmecli

This small tool will allow you to just create, rekey and deactivate your acmev2 account(s).

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#144

Post by pepdar »

bombcar wrote: post #77
csense wrote: post #21

To get a Let's Encrypt wildcard cert, I ended up running my own DNS server with dnsmasq and delegating the _acme-challenge subdomain to it. Pasting a challenge string once and letting its continued presence prove continued ownership of a domain is a great step forward. But I agree with others that there is absolutely no reason to expose account numbers; it should be a random ID associated with the account in Let's En…

Your account ID is exposed in the certificate generated; what's the real difference?

The ACME account URI does not appear in issued certificates. X.509 certs contain the subject, issuer, SANs, validity period, SCTs, etc., but no ACME account identifier. You can verify this by inspecting any Let's Encrypt certificate. What CT logs do reveal is which CA issued certs for which domain(s), and multi-domain certs group SANs together, so some correlation is possible. But the account URI itself is not exposed — dns-persist-01 records in DNS would be a new exposure surface for that identifier. That's a real tradeoff, which is why the draft supports using separate accounts per domain if isolation matters to you.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#145

Post by Bender »

liambigelow wrote: post #42
TrueDuality wrote: post #2

I 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…

CAA records including an accounturi already expose the account identity in the same manner, so I feel like that ship has already sailed somewhat (and I would prefer that the CAA and persist record formats match).

I think the difference is that using the existing DNS method listing the account is entirely optional. I have left it out on domains that I don't want correlated for that very reason.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#146

Post by Borealid »

akerl_ wrote: post #130
Borealid wrote: post #117

Earlier quoted context omitted.

In order for an attacker to reduce a site's Availability via DNS they must alter the records received by resolvers. If they can do that, they can just refuse to send the records at all (or mangle them such that they are ignored). DNSSEC makes the situation no worse. It does, however, increase Integrity. For the record, the 'A' in CIA refers to resilience against some party's purposeful attempt to make something unava…

> For the record, the 'A' in CIA refers to resilience against some party's purposeful attempt to make something unavailable. That’s pretty clearly not correct.

Care to explain what you think is correct, if that is incorrect?

CIA is about security. It's not about some kind of operational best practices.

Supporting example: creating a system where someone failing to enter their password correctly one time locks them out for a day is problematic, because that system can be made unavailable by an attacker. This is not an Available system, and thus not as secure as one that has a more flexible lockout policy.

Supporting example: creating a system where an application is only available from one IP address is problematic, because an attacker can take out one ISP and knock that IP address off the Internet. Making the system more Available by allowing users to access it from other IPs improves the overall security posture.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#147

Post by pepdar »

solatic wrote: post #127
ajnin wrote: post #124

Earlier quoted context omitted.

DNSSEC is encouraged ("SHOULD" wording) in the RFC draft : https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...

The RFC wording is a little weird. If the zone has DNSSEC configured, then the wording should be stronger and use MUST wording, and not imply that CAs will be compliant if they choose to avoid verifying signatures despite the presence of signstures. Likewise, these TXT records for dns-persist-01 ideally "SHOULD NOT" be deployed when DNSSEC is not configured.

An open PR on the draft (#35) adds exactly this language: if a CA performs DNSSEC validation and it fails (expired signatures, broken chain of trust), the CA MUST treat it as a challenge failure and MUST NOT use the record. The rationale is that dns-persist-01 records are long-lived, so a DNSSEC failure has more severe consequences than it would for a transient challenge.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#148

Post by pepdar »

mscdex wrote: post #48

After having to deal with VM hosts that do GeoIP blocking, which unintentionally blocks Let's Encrypt and others from properly verifying domains via http-01/tls-alpn-01, I settled on a DIY solution that uses CNAME redirects and a custom, minimal DNS server for handling the redirected dns-01 challenges. It's essentially a greatly simplified version of the acme-dns project tailored to my project's needs (and written in…

Key rotation doesn't change the account URI — ACME key rollover (RFC 8555 §7.3.5) replaces the key pair but keeps the same account URL, which is one of the reasons the draft uses account URI rather than a public key. Your DNS record stays unchanged through key rotations.

The only case that requires a DNS update is creating an entirely new account, and that's deliberate — the record binds a specific account to the domain so a stolen record can't be used by someone else.

For your setup with CNAME delegation to a custom DNS server, this should actually be simpler than dns-01. You would point _validation-persist instead of _acme-challenge, and the target record is static. No per-issuance dynamic updates at all.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#149

Post by akerl_ »

Borealid wrote: post #146
akerl_ wrote: post #130

Earlier quoted context omitted.

> For the record, the 'A' in CIA refers to resilience against some party's purposeful attempt to make something unavailable. That’s pretty clearly not correct.

Care to explain what you think is correct, if that is incorrect? CIA is about security. It's not about some kind of operational best practices. Supporting example: creating a system where someone failing to enter their password correctly one time locks them out for a day is problematic, because that system can be made unavailable by an attacker. This is not an Available system, and thus not as secure as one that has…

I'm not sure why you're trying to build up what CIA means by inventing scenarios.

https://en.wikipedia.org/wiki/Information_security#CIA_triad

> For any information system to serve its purpose, the information must be available when it is needed.[78] This means the computing systems used to store and process the information, the security controls used to protect it, and the communication channels used to access it must be functioning correctly.[79] High availability systems aim to remain available at all times, preventing service disruptions due to power outages, hardware failures, and system upgrades.[80] Ensuring availability also involves preventing denial-of-service attacks, such as a flood of incoming messages to the target system, essentially forcing it to shut down.[81]

https://www.fortinet.com/resources/cyberglossary/cia-triad

> If, for example, there is a power outage and there is no disaster recovery system in place to help users regain access to critical systems, availability will be compromised. Also, a natural disaster like a flood or even a severe snowstorm may prevent users from getting to the office, which can interrupt the availability of their workstations and other devices that provide business-critical information or applications. Availability can also be compromised through deliberate acts of sabotage, such as the use of denial-of-service (DoS) attacks or ransomware.

https://online.utulsa.edu/blog/what-is-the-cia-triad/

> Software bugs or misconfigurations. Incorrect software configurations or glitches can cause system outages.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#150

Post by tialaramex »

plagiat0r wrote: post #139
tialaramex wrote: post #80

Earlier quoted context omitted.

Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.

X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key. The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.

Although the poisoned pre-certificates† are logged as a necessary part of offering the least hassle product which is the business Let's Encrypt are in, they, like most CAs, also log the finished certificate shortly after.

Here's the pre-certificate for this web site's current certificate:

https://crt.sh/?id=23696530376

and here, just a few later in the log, is the finished certificate:

https://crt.sh/?id=23696528656

This is good practice, but it's also just easier, because if anything goes wrong, and sometimes things do go wrong, when the trust store says hey, please provide all certificates you issued with these properties, if you've logged them they are right there published in the logs for everybody to see - no bother, no risk - if you haven't then you need your own storage and better hope there aren't any mistakes. I'm sure LE do have their own copies if they needed them, but it sure is nice to know that's not what you're betting on.

† Poisoned pre-certificates are a "temporary" hack so that the certificate logging system can be demonstrated. If we ever really wanted this of course we'd develop a proper solution instead, right? Right? Every experienced software engineer knows that "temporary" usually means permanent in practice and so nobody was surprised by how this turned out.

Post reply on HN