danyork

tptacek - the root keys will remain RSA-keyed for some time. The root Key Signing Key (KSK) is 2048-bit RSA. The root Zone Signing Keys (ZSKs) that are CHANGED every 3 months (a ZSK key ceremony is in fact happening TODAY) are 1024-bit RSA.

There was strong interest in changing the algorithm when the KSK is rolled (when that occurs is still to be decided), but for the moment an algorithm change will not be part of that.

I don't deny that deployment of ED25519 will take some time. Once approved it has to be integrated into the signing software. It's also got to be integrated into the validation side. It's going to take time. So lets get started!

This is great news for those of us who want to see DNSSEC more widely deployed for three reasons:

1. CloudFlare already hosts the DNS for millions of domains. This is now making it VERY easy for those who use CloudFlare to sign their domains with DNSSEC.

2. Because of the competition within the DNS hosting / operator space, this move by CloudFlare will hopefully motivate the other large DNS operators to simplify their own user experience for DNSSEC.

3. For those of us who want to see stronger crypto within DNSSEC, this move by CloudFlare advances the use of an elliptic curve algorithm. Yes, ECDSA has its issues, but by getting it out there: a) it gets people looking at EC algorithms; and b) it gets software providers realizing they need to have their user interfaces adaptable to incorporate more DNSSEC algorithms. (I.e. to realize the list is NOT fixed and will grow over time.)

As I said in another comment ( https://news.ycombinator.com/item?id=10553383 ) there is a draft out there to add Ed25519 as a DNSSEC algorithm:

https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01

This draft needs to be approved through the IETF working groups - and then deployed on both the signing and validation sides of DNSSEC. This will take quite some time and so we need to start as soon as we can.

Obligatory responses to tptacek's article:

- http://blog.easydns.org/2015/08/06/for-dnssec/

- http://www.circleid.com/posts/20150318_is_dnssec_worth_the_e...

Collectively thousands of words have been written on this topic within HN - and there are stark divisions between those who oppose DNSSEC and those who believe DNSSEC is a helpful and useful method of adding a layer of security to the Internet.

We don't agree. We won't agree.

Meanwhile, those of us who want to see DNSSEC more widely deployed applaud this move by CloudFlare because it both makes deployment simpler for many people and also advances the usage of stronger crypto (ECDSA) within DNSSEC.

This is great news!

It's great to see this microsite (and the announcement yesterday) as this rollout by CloudFlare will do two major things to help move DNSSEC forward:

1. Simplify the process of setting up DNSSEC-signing for so many people; and

2. Advance the usage of stronger crypto through the used of ECDSA (DNSSEC algorithm 13).

The first point will help with getting many more domains signed. The second point will help those of us who want to see even stronger crypto used within DNSSEC.

On that last note, I'd also note that there is an Internet Draft submitted about adding Ed25519 as a new DNSSEC crypto algorithm. You can find it here:

https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01

Support for this draft within the IETF working groups - and indeed in implementations - will help make this a reality.

A key point is this one:

----

Faced with police and city concerns, library director Fleming agreed to turn off the Tor relay temporarily until the board could reconsider. “We need to find out what the community thinks,” he said. “The only groups that have been represented so far are the Police Department and City Hall.”

----

The library's board and staff haven't heard from anyone but law enforcement / government ... so without other viewpoints offering another view they are at least temporarily bowing to that pressure.

Now, living in NH and knowing how our local politics work, I'm not sure exactly what a massive online petition is really going to accomplish. If anything, it may just rouse animosity within the local community. (We take "Live Free or Die" pretty seriously here - and that includes being free of outside forces trying to push us to do something!)

What really needs to happen is for some citizens of Lebanon, NH to provide an alternative view to the library board.

Thanks for providing that link - the original piece was far more useful for me to read than the condensed version.

There are a good number of stories now out about this:

http://www.techmeme.com/150727/p8#a150727p8

It seems one of the original reports is here:

http://blog.zimperium.com/experts-found-a-unicorn-in-the-hea...

I'd also note that it seems this is research that will be presented next week at Black Hat and then again at DefCon.

I found this an interesting view... but I think there's another model that's a combination. The author assumes all devices will talk to the cloud-based service, although in the "Decentralized" model the devices may talk amongst each other and THEN out to the cloud.

However, there could also be model where all the IoT devices communicate with a local hub within a building and then communicate back to the cloud through that local hub. So the model is "decentralized" in that it does not have reliance on a central hub... but "centralized" within the local area. Perhaps this is a "Distributed Hub" model or something like that.

Right... at this point Facebook is where the people are that other people want to communicate with. Facebook has the massive "directory" of users.

Social networks are only useful to people if the other people with whom they want to communicate are ON those networks.

Right now, Facebook has that massive directory. This can change, of course. The Internet does not have permanent favorites. But today, Facebook is where you can easily find and interact with people.

And yes, please do flesh out that post sometime... I would be interested in reading it! :-)

Also we have to consider that "regular" Internet users (who are probably not HN readers!) just want to communicate with their friends, share pictures and jokes, find news, etc. They want a simple user experience that's just easy to use.

THAT user experience (UX) has been the main issue I've seen with attempts at a distributed social network (such as Diaspora).

Try http://en.internet.nl/ as a way to find whether your sites or ISPs use IPv6

I agree that signatures are of no value unless validation is done... but please do note that current measurements are showing about 13% of all DNS queries globally are in fact being validated:

http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g...

If you scroll down that page you'll see higher statistics, such as 70% of all queries being DNSSEC-validated in Sweden, because almost all the ISPs there are now validating.

In the USA, about 23% of all DNS queries are being DNSSEC-validated:

http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1

So the argument that "no one is checking" is no longer true.

> It's not controlled by NSA? The largest nodes in the tree are literally controlled by them.

Perhaps I should thank you, Thomas, for continuing to beat this drum... because it shows extremely clearly how we need to educate more people and be MUCH more clear about exactly how the keys at the root of DNSSEC are maintained. If people fully understand the process, and how it was designed to NOT allow attackers in this way, we could spend our time on much more productive discussions. (Granted, documents such as https://www.iana.org/dnssec/icann-dps.txt do NOT make for friendly reading.)

Thank you for pointing out the work that needs to be done.

> The CA mechanism used for TLS has the same issue. It's not just theoretical either...

Exactly. Which is why so many of us are looking for ways to add an additional layer of trust to the CA system used for TLS.

One such mechanism is to use DANE and DNSSEC as an additional mechanism for trust.

Let's be clear, though, the root of DNSSEC is NOT handled like the root of any CA system. The process of obtaining the root private key is not something where you just break into some system and grab a file somewhere.

The root zone's private key is actually distribute across a set of smart cards possessed by Trusted Community Representatives (TCRs - people like you and me within the Internet technical community) - some number of whom get together periodically in "key ceremonies" to perform actions that require the root KSK, such as the generation of new Zone Signing Keys (ZSKs) every 3 months in what are called "key ceremonies" - https://www.iana.org/dnssec/ceremonies

The entire process of protecting the root zone's key material are documented at length in what is called a DNSSEC Practice Statement: https://www.iana.org/dnssec/icann-dps.txt

Again, the DNSSEC root zone management is EXTREMELY different from that of the CA system. It was designed to be much more secure and to not allow the kind of penetration we're seeing with the CA system.

But here's the thing - the root zone's private key for DNSSEC is not in one place. It is spread across a number of smart cards carried by a variety of individuals spread around the world - specifically so that it could not be compromised by governments or others.

You can see for yourself exactly what kind of process takes place to use the root key to generate new Zone Signing Keys (ZSKs) every 3 months at the IANA key ceremonies: https://www.iana.org/dnssec/ceremonies

It would be an extremely difficult process for an intelligence agency to subvert, even one with essentially limitless resources.

colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query.

Yes, "cache poisoning".

Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there.

If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there.

If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater.

This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.

> jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure.

Please explain how. The whole point of DNSSEC is to provide a cryptographic validation that the material put into DNS by the operator of a zone is the same information you get out of DNS when you perform DNSSEC validation.

I'm quite tired of seeing the assertion that "DNSSEC can be re-directed" without people actually walking through HOW that redirection can occur. (Thank you in advance for doing so.)

tptacek:

> I don't understand the point you're trying to make.

I am trying to understand how the attack you say is possible truly is possible.

> In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.

Verisign operates the .COM TLD registry and has documented in excruciating detail how they handle the security of DNSSEC key material: https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf

Is your assertion that the NSA would order Verisign to bypass those controls and make a change to a DS record (and associated NS records) to redirect people to another site?

If so, how would they do that for just me? It would have to be a much larger redirection of people.

If your Internet-enabled device doesn't have a DNSSEC-validating resolver (with solid trust anchors for the root zone), then this entire conversation is irrelevant.

If your Internet-enable device does have a DNSSEC-validating resolver either on the device or within an acceptable zone or risk[1] then the chain of trust back up to the root zone of DNS will mean that I will notice a substitution and get a SERVFAIL. It may mean that the attacker could DoS me and prevent me from going to a site, but I don't see where I would wind up on the bogus site.

[1] For example, I have a DNSSEC-validating resolver on the edge of my home network. Yes, an attacker could still compromise my home network and send me forged responses. I consider that less likely and am willing to take that risk.

Thomas,

I perform DNSSEC validation on the edge of my home office network. All my devices use my DNSSEC-validating DNS resolver on my network server-gateway.

That resolver is going to check the DNSSEC chain of trust using DS records all the way up to the root of DNS.

If I get back a signed record for www.example.com (meaning an RRSIG), my DNS resolver is going to validate the signatures back up to the root of DNS.

If the signatures don't validate, it's going to give me a SERVFAIL and prevent me from going to whatever site I'm trying to get to.

If the NSA/GCHQ/whomever wanted to redirect me to another site under their control, they could try to send me the record with a valid RRSIG from their own DNSKEY. My resolver is now going to go to .COM (for example.com) and pull the DS record for "example.com". If the DNSKEY and DS don't match, I'm going to get a SERVFAIL and won't get to the site.

Now, the attacker could try to send me their own DS record for the .COM domain... but that's going to be signed by the .COM's DNSKEY ... which again I suppose the attacker could try to send me a substitute.

But now my resolver is going to pull a DS record from the root of DNS for the .COM TLD. That DS record will be signed with the DNSKEY of the root. My resolver is going to validate that signed DS record and compare it with the DNSKEY for .COM. If they don't match, I'm going to get a SERVFAIL.

Now I guess in theory the attacker could try to send me a DS record for the .COM TLD that is signed by their own key... but here's the thing - my local resolver is already pre-loaded with the public key of the root zone as the trust anchor. So it's not going to trust anyone else's records that purport to be the root zone if the signatures don't match the local trust anchor.

So how does the NSA/GCHQ/etc. carry out this attack to redirect me to another site?

The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case:

http://tools.ietf.org/html/rfc4255

When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.)

The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key.

Do note this is not a new idea. This RFC was published back in 2006.

tptacek:

> Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?

Please remind me again how the NSA/GCHQ can subvert my domain at example.com without anyone else in the chain noticing that?

> Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

DNSSEC has nothing to do with privacy.

DNSSEC is entirely about the integrity of DNS requests.

DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about.

That's it.

DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.

jocluteseh - your site seems to be down now (perhaps buried under HN traffic). Perhaps post it as a gist on Github or something like that? https://gist.github.com/

> 9. I'm not smart enough to understand what this argument means.

Thomas, I _think_ you are replying to this:

> 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings.

There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys.

People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.

I'll note that a main point of this document is to explain to people such as policy makers how we in the Internet technical community collaborate to address security issues. This is an effort by Olaf Kolkman to help policy makers understand "the Internet way" and why the collaborative approach taken by different communities on the Internet is better than centralized, government-mandated approaches to Internet security.

So what do we do to fix the broken CA system? Particularly in a case where a bogus certificate is issued by an intermediate CA that rolls up to a root CA that is included in all the major browsers.

It seems to me that we have several building blocks available and it may be a combination we need:

1. CERTIFICATE PINNING (HPKP) - example: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 - if a browser had previously pinned the certs of affected sites then it would have known that it was going to bogus sites and could have displayed a warning or prevented the user from going to those sites.

The challenge with pinning is that somehow you have to learn what to pin before you visit a site, either by having the pinset or certs pre-loaded into the app/browser or simply by doing Trust On First Use (TOFU). Additionally, if the first use is to the site controlled by an attacker, the cert that gets pinned in the browser could in fact be the attacker's cert, which could make recovery difficult.

Which brings us to...

2. DANE/DNSSEC - http://www.internetsociety.org/deploy360/resources/dane/ - with DANE (RFC 6698) you put a fingerprint (or an entire cert) into a TLSA record in DNS and then sign that with DNSSEC. A browser or app that supported DANE could deal with the TOFU issue by doing a DANE check to verify the cert that it is receiving from the web server. This would then effectively bootstrap the cert pinning process by providing a way to test the validity of the cert.

Because the DANE TLSA records are entered by the owner/operator of the domain and then through DS records are tied into a validated chain-of-trust up to the root of DNS, it would be difficult for an attacker to subvert this with his/her malicious TLSA records.

But we have a third layer to help...

3. CERTIFICATE TRANSPARENCY (CT) - http://www.certificate-transparency.org/ - CT provides a way to log all the issued certs and have browsers/apps check those logs through an auditor. When the browser gets the TLS cert, it also gets a signed cert timestamp (SCT) and can use that through an auditor component to check if the cert is valid. The challenge is that right now only some CAs log issuance of certs and only some browsers/apps check via an auditor. (I also don’t understand myself exactly how real-time CT is, but that may just be that I need to understand the SCT mechanism better.)

To me these three different components can work together to provide a higher degree of trust: cert pinning to help with the speed of connecting to frequently-visited sites; DANE to help with the first use/key learning issue[1]; and CT to provide another means of checking the cert validity.

Comments?

[1] And yes, DANE could be used to store entire TLS certs separately, but right now I’m looking at how these pieces could be used together to give the maximum efficiency and security.

Any CA can generate a cert for any domain. This is one of the problems with the current CA system.