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

81–90 of 164 posts

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

#81

Post by IgorPartola »

bombcar wrote: post #73
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…

Yes, anyone who controls your DNS can get a TLS certificate from anyone who offers them - because, uh, they control your DNS! Try to figure out a way to block me from getting a TLS certificate if I can modify your DNS.

That’s fair but I also have to trust every provider between my DNS server and LE’s servers to not intercept DNS responses. Since DNS isn’t encrypted anyone anywhere between them can modify the traffic and get a certificate if I understand correctly.

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

#82

Post by mcpherrinm »

9dev wrote: post #59
mcpherrinm wrote: post #13

Earlier quoted context omitted.

There is no username in ACME besides the account URI, so the UUID you’re suggesting isn’t needed. The account uri themselves just have a number (db primary key). If you’re worried about correlating between domains, then yes just make multiple accounts. There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.

It’s still a valid point IMHO - why not just use the public key directly? It seems like the account URI just adds problems instead of resolving any.

It has these primary advantages:

1. It matches what the CAA accounturi field has

2. Its consistent across an account, making it easier to set up new domains without needing to make any API calls

3. It doesn’t pin a users key, so they can rotate it without needing to update DNS records - which this method assumes is nontrivial, otherwise you’d use the classic DNS validation method

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

#83

Post by toast0 »

wtallis wrote: post #50
basilikum wrote: post #45

> The timestamp is expressed as UTC seconds since 1970-01-01 That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?

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.

Probably yeah, seconds don't really matter here. You would have to work hard for the 27 second difference to be material. But precision is nice.

unixtime is almost certainly what is meant by the standard, but it is not the count of UTC seconds since 1970; unix time is the number of seconds since 1970 as if all days had 86400 seconds. UTC, TAI, and GPS seconds are all the same length, and the same number have happened since 1970, but TAI appears 37 seconds ahead of UTC because TAI has days with 86400 seconds, while UTC has some days with 86401 seconds and was 10 seconds ahead of UTC in 1970. unixtime and UTC are in sync because unixtime allows some days to encompass 86401 UTC seconds while unixtime only counts 86400 seconds.

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

#84

Post by tptacek »

cyberax wrote: post #71
tptacek wrote: post #64

Earlier quoted context omitted.

When you shoot yourself in the foot with DNSSEC, your entire domain falls of the Internet, as if it had never existed in the first place. It's basically the worst possible case failure and it's happened to multiple large shops; Slack being the most notorious recent example.

Yes, and it'd be great if DNSSEC added an "advisory" signature level. So it can be deployed without doing a leap of faith. But let's not pretend that WebPKI is perfect. More than one large service failed at some point because of a forgotten TLS certificate renewal. And more than one service was pwned because a signing key leaked. Or a wildcard certificate turned out to be more wildcard than expected. I understand the…

I don't really understand most of this comment but you opened up this subthread with "Come on. It's not dangerous", and, as you're acknowledging here, it clearly is quite dangerous.

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

#85

Post by mcpherrinm »

IgorPartola wrote: post #81
bombcar wrote: post #73

Earlier quoted context omitted.

Yes, anyone who controls your DNS can get a TLS certificate from anyone who offers them - because, uh, they control your DNS! Try to figure out a way to block me from getting a TLS certificate if I can modify your DNS.

That’s fair but I also have to trust every provider between my DNS server and LE’s servers to not intercept DNS responses. Since DNS isn’t encrypted anyone anywhere between them can modify the traffic and get a certificate if I understand correctly.

Two current mitigations and one future:

DNSSEC prevents any modification of records, but isn’t widely deployed.

We query authoritative nameservers directly from at least four places, over a diverse set of network connections, from multiple parts of the world. This (called MPIC) makes interception more difficult.

We are also working on DNS over secure transports to authoritative nameservers, for cases where DNSSEC isn’t or won’t be deployed.

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

#86

Post by akerl_ »

cyberax wrote: post #71
tptacek wrote: post #64

Earlier quoted context omitted.

When you shoot yourself in the foot with DNSSEC, your entire domain falls of the Internet, as if it had never existed in the first place. It's basically the worst possible case failure and it's happened to multiple large shops; Slack being the most notorious recent example.

Yes, and it'd be great if DNSSEC added an "advisory" signature level. So it can be deployed without doing a leap of faith. But let's not pretend that WebPKI is perfect. More than one large service failed at some point because of a forgotten TLS certificate renewal. And more than one service was pwned because a signing key leaked. Or a wildcard certificate turned out to be more wildcard than expected. I understand the…

> But let's not pretend that WebPKI is perfect.

You're commenting on a post about LetsEncrypt working with other entities in the industry to make improvements to WebPKI. It's safe to say that nobody's claiming it's perfect.

But you can't go from ~"WebPKI isn't perfect" and ~"DNSSEC/DANE exist" and draw a magic path where using DNSSEC or DANE is actually a good thing for people to roll out. They'd need to be actually a good fit, and for DANE we have direct evidence that it isn't: a rollout was attempted and it was walked back due to multiple issues.

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

#87

Post by bflesch »

mmh0000 wrote: post #4

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

> But I don't understand why they chose to include the account as a plain-text string in the DNS record.

Simple: it's for tracking. Someone paid for that.

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

#88

Post by tialaramex »

wtallis wrote: post #50
basilikum wrote: post #45

> The timestamp is expressed as UTC seconds since 1970-01-01 That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?

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 bye leap seconds.

The body responsible has formal treaty promises to make UTC track the Earth's spin and replacing those treaties is a huge pain, so, the "hack" proposed is to imagine into existence a leap minute or even a leap hour that could correct for the spin, and then in practice those will never be used either because it's even less convenient than a leap second - but by the time they're asked to set a date for these hypothetical changes likely the signatory countries won't exist and their successors can just sign a revised treaty, countries only tend to last a few hundred years, look at the poor US which is preparing 250th anniversary celebrations while also approaching civil war.

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

#90

Post by kami23 »

Ajedi32 wrote: post #55

This is going to make it way easier to get publicly trusted certs for LAN servers that aren't internet facing. I'm looking forward to every admin UI out there being able to generate a string you can just paste into a DNS record to instantly get a Let's Encrypt cert.

Just experienced this with my heavily networked off openclaw setup. I gave up and will do manual renewals until I have more time to figure out a good way of doing it. I was trying to get a cert for some headscale magic dns setups, but I think that's way more complicated than I thought it would be.
Post reply on HN