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

First-ever DNSSEC root key rollover

redhat.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: First-ever DNSSEC root key rollover

#61

Post by tedunangst »

the_clarence wrote: post #49
tptacek wrote: post #36

Earlier quoted context omitted.

I like LetsEncrypt and wasn't trying to suggest it was a problem. I think the comparison between LetsEncrypt and DNSSEC is instructive; a LetsEncrypt confidentiality failure would be disastrous, and a DNSSEC confidentiality failure... actually wouldn't matter at all , unless someone out there is doing something really creative and dumb with the protocol.

This might actually be a bad point for letsencrypt. All the eggs are starting to be in the same basket.

If your failures don't count, you're not doing anything important.

Re: First-ever DNSSEC root key rollover

#62

Post by tialaramex »

tptacek wrote: post #55
tialaramex wrote: post #46

Earlier quoted context omitted.

For example Thomas likes Let's Encrypt but he's stuck with his narrative about how nothing uses DNSSEC. So when you point out that Let's Encrypt uses DNSSEC so this position makes no sense, Thomas will just pretend not to understand and refer you back to stuff he wrote many years ago about how nothing uses DNSSEC.

LetsEncrypt does not rely on DNSSEC and does multi-perspective DNS lookups. Something significantly south of 0.5% of LetsEncrypt certificates ever involve DNSSEC. If DNSSEC vanished tomorrow, literally nothing about LetsEncrypt would change. There would be no operational impact whatsoever. Not that there's anything wrong with the pieces I wrote "years ago" about DNSSEC (nothing material has changed about it since I w…

Those "multi-perspective" validations have been stalled for over a year. The last news is from August 2017. Unlike many issuers Let's Encrypt notoriously does fresh validations for most issuances and they start with a DNSSEC validated authoritative DNS query chain. So, that's 100% of validations, and perhaps 95% of all issuances. Not 0.5% as you've claimed.

When you wrote your jolly screed against DNSSEC the biggest CAs relied heavily on "Any other method" blanket exemptions which no longer exist today. They also used to insist that their extremely high issuance rates made DNSSEC and other security features just infeasible.

After CT this last part got awkward. Where, a neutral party like me might ask, are the doubtless hundreds of millions of certificates you've been issuing that would make this so hard? And of course they don't exist, it was a bluff and now their bluff has been called.

Re: First-ever DNSSEC root key rollover

#63

Post by tptacek »

tialaramex wrote: post #62
tptacek wrote: post #55

Earlier quoted context omitted.

LetsEncrypt does not rely on DNSSEC and does multi-perspective DNS lookups. Something significantly south of 0.5% of LetsEncrypt certificates ever involve DNSSEC. If DNSSEC vanished tomorrow, literally nothing about LetsEncrypt would change. There would be no operational impact whatsoever. Not that there's anything wrong with the pieces I wrote "years ago" about DNSSEC (nothing material has changed about it since I w…

Those "multi-perspective" validations have been stalled for over a year. The last news is from August 2017. Unlike many issuers Let's Encrypt notoriously does fresh validations for most issuances and they start with a DNSSEC validated authoritative DNS query chain. So, that's 100% of validations, and perhaps 95% of all issuances. Not 0.5% as you've claimed. When you wrote your jolly screed against DNSSEC the biggest…

An infinitesimal fraction of the domains LetsEncrypt issues certificates for are signed. I kind of don't understand how you're even trying to make this argument. Everyone here who has ever set up LetsEncrypt knows there's no DNSSEC involved. LetsEncrypt does not depend on DNSSEC; if DNSSEC vanished tomorrow, there would be no operational impact.

Here, try this: search for "LetsEncrypt tutorial", go through the first two search pages, and find one that says "to start with, sign your domain with DNSSEC". Not one in my search results mentions DNSSEC. That's because: nobody cares.

Re: First-ever DNSSEC root key rollover

#64

Post by tialaramex »

tptacek wrote: post #63
tialaramex wrote: post #62

Earlier quoted context omitted.

Those "multi-perspective" validations have been stalled for over a year. The last news is from August 2017. Unlike many issuers Let's Encrypt notoriously does fresh validations for most issuances and they start with a DNSSEC validated authoritative DNS query chain. So, that's 100% of validations, and perhaps 95% of all issuances. Not 0.5% as you've claimed. When you wrote your jolly screed against DNSSEC the biggest…

An infinitesimal fraction of the domains LetsEncrypt issues certificates for are signed. I kind of don't understand how you're even trying to make this argument. Everyone here who has ever set up LetsEncrypt knows there's no DNSSEC involved. LetsEncrypt does not depend on DNSSEC; if DNSSEC vanished tomorrow, there would be no operational impact. Here, try this: search for "LetsEncrypt tutorial", go through the first…

DNSSEC not protecting those who choose not to be protected is entirely to be expected.

Should I assume you figured "nobody cares" about the Web PKI back just a few years when tutorials wouldn't have mentioned TLS? Were people who said that right? Or wrong?

Re: First-ever DNSSEC root key rollover

#65

Post by tptacek »

tialaramex wrote: post #64
tptacek wrote: post #63

Earlier quoted context omitted.

An infinitesimal fraction of the domains LetsEncrypt issues certificates for are signed. I kind of don't understand how you're even trying to make this argument. Everyone here who has ever set up LetsEncrypt knows there's no DNSSEC involved. LetsEncrypt does not depend on DNSSEC; if DNSSEC vanished tomorrow, there would be no operational impact. Here, try this: search for "LetsEncrypt tutorial", go through the first…

DNSSEC not protecting those who choose not to be protected is entirely to be expected. Should I assume you figured "nobody cares" about the Web PKI back just a few years when tutorials wouldn't have mentioned TLS? Were people who said that right? Or wrong?

I'm sorry, I can't understand what you're trying to argue at this point. My argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it does not.

Re: First-ever DNSSEC root key rollover

#66

Post by joshuamorton »

RL_Quine wrote: post #16
tialaramex wrote: post #11

Earlier quoted context omitted.

The new key is simply newer. For especially valuable keys we must assume that an adversary is trying to break them, even if this will be difficult and expensive. But by changing keys, we undo all the work invested so far into breaking a key, since the key they were breaking won't even be used any more. This was the rationale behind password change frequency rules too. If I can try 100 passwords per day, and I'm sure…

> This was the rationale behind password change frequency rules too. If I can try 100 passwords per day, and I'm sure you've picked 1 of 1000000 passwords I have a good chance to find which one in a few years. But if you're forced to change it every 6 months then I'll never have more than a small chance to get it. This is not how probability works. Password rotation is intended to prevent long term compromises from e…

>This is not how probability works. Password rotation is intended to prevent long term compromises from existing due to a leaked password. I'd debate if this actually has any effect, but that's another matter entirely.

Yes it is. Let's up the number to 1000 passwords per day. That means that I can check all passwords in the space in 1000 days, or 3 years. In other words, after 1000 days, there is a 100% chance I can access your account.

If on the other hand, you change your password to a new, random password each day, I have a 1/1000 chance of guessing it each day. Then after 1000 days, I have a 1 - (1 - 1/1000)^1000 chance[1] of knowing your password. That is, each day, I guess your password with P = .1%, so there's a 99.9% chance I don't. Then after 2 days, there's a 99.9% chance for day one, and of the remaining 99.9, there's a 99.9% chance I don't, continue on for 1000 days, and there's a 63.2% chance you ever accessed my account, not 100%.

In short, it converts the password cracking attempts form being correlated to uncorrelated over a long time scale.

[1]: As an aside, note that in this example that is ~1 - 1/e.

Re: First-ever DNSSEC root key rollover

#67

Post by tialaramex »

tptacek wrote: post #65
tialaramex wrote: post #64

Earlier quoted context omitted.

DNSSEC not protecting those who choose not to be protected is entirely to be expected. Should I assume you figured "nobody cares" about the Web PKI back just a few years when tutorials wouldn't have mentioned TLS? Were people who said that right? Or wrong?

I'm sorry, I can't understand what you're trying to argue at this point. My argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it does not.

Me describing how these conversations go: > Thomas will just pretend not to understand

Thomas just now: > I'm sorry, I can't understand what you're trying to argue

Let's Encrypt does today depend on DNSSEC because it uses a DNSSEC verifying validator. If you have chosen not to sign names of course your names aren't protected by this, names which are signed are protected.

In a similar way, Firefox does today depend on the Web PKI because it uses NSS, a TLS implementation with a certificate validator baked into it. If you have chosen not to use HTTPS of course your sites aren't protected by this, sites which use HTTPS are protected.

Re: First-ever DNSSEC root key rollover

#68

Post by tialaramex »

RL_Quine wrote: post #20
peterwwillis wrote: post #19

Earlier quoted context omitted.

> if this actually has any effect It has the effect of limiting the amount of time that a credential leak can lead to exploit. The focus is on long-term undiscovered compromise using valid credentials. If an attack is not discovered, and the credentials are never changed, the attacker might have access for years. If you're worried about something like corporate espionage, this mitigation is simple and minimal effort.…

I argue that most compromises are effectively instantaneous. There’s usually little value in being a persistent threat when it takes only a moment to, for example, dump a database or an IMAP folder. Forcing rapid rotations just encourages people to choose weak passwords or store them on post it notes on their screen.

I don't buy the first part of what you wrote. For the second part, I agree but we need to cut it out with the band-aids. Passwords are not good enough, whatever the policies.

One of the few things I miss from my old job was the very intimate view of how much personal data is being stolen (or obtained through phishing) by crooks. If you imagine HIBP as a normal two storey house, and then imagine the data I was looking at and that's an Eiffel tower, or more.

And although some fraction of the feed every day was new (in the sense that we'd not seen it in the last 90 days, we deliberately destroyed it after 90 days so who knows before that) there was also lots of recycling. There are crooks still selling a SQL dump they got in early August by October, maybe they aren't getting top dollar for it, but it's shifting.

And the data people are buying for those "We know your password and if you don't pay us a Bitcoin we'll release webcam images of you masturbating" scams is much older. One of my bait accounts still gets those every few weeks, I used it for bait in a system that we know was broken into (though it isn't public in HIBP or whatever) by 2013. So while those bitcoin scam people aren't using it for account break-ins, it's still out there and represents a threat.

Re: First-ever DNSSEC root key rollover

#69

Post by tptacek »

tialaramex wrote: post #67
tptacek wrote: post #65

Earlier quoted context omitted.

I'm sorry, I can't understand what you're trying to argue at this point. My argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it does not.

Me describing how these conversations go: > Thomas will just pretend not to understand Thomas just now: > I'm sorry, I can't understand what you're trying to argue Let's Encrypt does today depend on DNSSEC because it uses a DNSSEC verifying validator. If you have chosen not to sign names of course your names aren't protected by this, names which are signed are protected. In a similar way, Firefox does today depend on…

You're simply using a different definition of "depend" than I am.

When you say "it does depend", you mean that in the rare cases where a domain owner has chosen (weirdly) to sign with DNSSEC, LetsEncrypt will enforce DNSSEC validation on that domain.

When I say "it does not depend", I mean that the basic functioning of LetsEncrypt does not in any way rely on DNSSEC. As I've said in the last several comments, LetsEncrypt will continue to function just fine when DNSSEC goes away, and a security failure in DNSSEC (for instance: if the root keys were posted to Pastebin) would literally not impact LetsEncrypt --- today's LetsEncrypt! --- at all.

I'm fine with you using the word "depend" to mean "uses, in any situation, ever", but you're clear now on what we're trying to say, and the semantic part of the debate should be over.

Re: First-ever DNSSEC root key rollover

#70

Post by nybble41 »

the_clarence wrote: post #52
colde wrote: post #47

Earlier quoted context omitted.

Of course you gain security, but not in the HTTPS PKI sense. Not that long ago, somebody BGP hijacked Route 53 in order to serve up different IP's for specific domains. Had that domain been using DNSSEC, that attack would have failed for everyone using a validating resolver. That might not be a common attack, but it certainly grants security. This could also help with "rogue" free wifi setups, that try to do somethin…

Were the domains using TLS?

Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.
Post reply on HN