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

111–120 of 164 posts

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

#111

Post by jmholla »

mschuster91 wrote: post #44
jmholla wrote: post #43

There's a missing part here, and that's validating your ACME account ownership. I think most users depend on automation that creates their accounts, so they never have to deal with it. But now, you need to propagate some credential to validate your account ownership to the ACME provider. I would have liked to see some conversation about that in this announcement. I'm not familiar with Let's Encrypt's authentication m…

> There's a missing part here, and that's validating your ACME account ownership. Why? ACME accounts have credentials so that the ACME client can authenticate against the certificate issuer, and ACME providers require the placement of a DNS record or a .well-known HTTP endpoint to verify that the account is authorized to act upon the demands of whoever owns the domain. If either your ACME credentials leak out or, eve…

> Why? ACME accounts have credentials so that the ACME client can authenticate against the certificate issuer, and ACME providers require the placement of a DNS record or a .well-known HTTP endpoint to verify that the account is authorized to act upon the demands of whoever owns the domain.

This is the previous models. In this case, DNS-Persist-01, the record is permanent and never changes. So to prove that your request is valid, they need to authenticate in some other manner. Otherwise, once you create that persistent record, anybody could request a cert for your domain.

Edit: Spivak explains the flow differences better in their comment: https://news.ycombinator.com/item?id=47065821

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

#112

Post by tptacek »

cyberax wrote: post #110
tptacek wrote: post #101

Earlier quoted context omitted.

This is a very strange definition of "dangerous".

I'm mostly thinking about dangerous from the security point of view. I agree that it might not be the best from the operational point of view. DNSSEC in its current state makes DNS updates even more risky than they are, I agree with that.

You remember what CIA stands for, right?

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

#113

Post by Hamuko »

tripdout wrote: post #105

For local services, I don't see the benefit of using DNS challenges and a Let's Encrypt certificate over running my own CA and generating my own certificates. It's not that much work to trust my root certificate on each device, and then I don't need an internet connection to verify local service certificates.

I can either add a Cloudflare API key and Certbot on my NAS, or I could generate a root certificate and add it to my desktop computers, laptop, tablet, phones, Apple TV, etc.

Doesn't seem that tough of a choice. I guess in the future I could even forego the Cloudflare API key and just have the persistent DNS record there once.

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

#114

Post by zufallsheld »

amluto wrote: post #65
9dev wrote: post #57

Earlier quoted context omitted.

For the love of god, switch to a DNS provider with an API. Whatever legacy behemoth you’re working with doesn’t justify a gap this wide.

Name one that doesn’t have an AWS-style per-query cost. (There might well be a nice one, but I haven’t found it yet.)

Hetzner does not charge any money for their dns service and they have an api.

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

#115

Post by pests »

xyzzy_plugh wrote: post #98
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.

Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.

Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json

While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list).

This means a 99% uptime on a 90 day rolling average, a 1 minute update frequency for new entries (24 hours on an older RFC). No split views, strict append-only, sharding by year, etc.

I think OP's original idea would work.

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

#116

Post by raquuk »

micw wrote: post #8

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

Using the account identifier in the record and and LE mapping the identifier to a public key internally enables key rotario without touching the record again.

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

#117

Post by Borealid »

tptacek wrote: post #112
cyberax wrote: post #110

Earlier quoted context omitted.

I'm mostly thinking about dangerous from the security point of view. I agree that it might not be the best from the operational point of view. DNSSEC in its current state makes DNS updates even more risky than they are, I agree with that.

You remember what CIA stands for, right?

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 unavailable. It does not stand for Areliability or Asimplicity.

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

#118

Post by pests »

gurjeet wrote: post #78
IgorPartola wrote: post #72

Am I just stupidly missing something or does this in theory allow anyone who controls a DNS server for my domain or anyone who controls traffic between LE and the DNS server for my domain to get a TLS certificate they can use to impersonate my domain? I suppose the same is true for DNS-01 but this would make it even easier because the attacker can just put up their LE account instead of mine into the DNS response and…

If you don't trust your DNS provider to _not_ do malicious acts against you, you shouldn't be in that relationship. If someone can perform MITM attack between LetsEncrypt and a DNS server, we've got bigger problem than just certificate issuance.

This is why the big names pay MarkMonitor $250-$1000 per domain with a minimum $10,00/yr spend.

They have a good reputation, lock down the domain technically at all levels, and have the connections and people/social skills to take care of any domain issues involving person-to-person contact.

Which is not easy, I recall spending months like a decade ago on email/phone attempting (successfully) to get my personal domain out of expiry hell (made more complicated by wrong records).

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

#119

Post by solatic »

I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks to seize control of a root of trust.

Of course, this has little applicability to anyone who is small enough not to have nation-state level actors in their threat model. But when I look behind the curtain of even Fortune 100 companies that really ought to have nation-state level actors in their threat model, too often you find people who are just not operating at that level or are swamped with unrelated work. So I'm starting to become of the opinion that guidance should change here and at the very least be documented recommendations - if it's not encouraged down the organizational size scale, too often it's not applied further up where it's needed.

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

#120

Post by imtringued »

tialaramex wrote: post #88
wtallis wrote: post #50

Earlier quoted context omitted.

Do leap seconds even matter here? Doing anything involving DNS or certificates in a way that requires clock synchronization down to the second would seem to be asking for trouble.

Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye by…

I tried to think about and leap seconds on their own don't seem to be a real problem. The problem is that leap seconds, minutes, hours, days, years, etc are a human interface concept and therefore only make sense to humans, but we've decided to force machines to deal with these human interface concepts as the primary way of dealing with time, when only the presentation layer should even know what a leap second is.
Post reply on HN