4 ms·

I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do no

by chaz6 10y ago

I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do not know (I have never met one of the root signers before), so you have no way to know if they or their equipment have been compromised by a state actor.

rocqua 10y ago
Sure, the root keys of DNS are non-state operated, but they are used to sign the DNS-sec keys for the TLDs. These, in turn, are used to sign the keys for the nameserver responsible for serving the normal domain. For any country TLD domain (.us .uk .nl), those keys are held by a state actor. That TLD then gets to sign any lower level DNS servers. Say whomever controlled .com wanted to change the key for hackernews.com. They'd simply change the .NS record for hackernews.com to point to a different DNS box with different keys, that proxies DNS requests for the real server but re-signs them. It can then simply serve a new DANE record. (DANE records are the DNS-sec version of CAs). This is essentially the same procedure as a CA issuing a wrong certificate. The source of this problem is that you don't just need to trust the root DNS servers, but you also need to trust the TLD-servers that are signed by the root DNS servers. (And down recursively if there are more NS records in between)
xorcist 10y ago
You already trust the DNS root, as long as domain names are what certificates are based on. If you can transfer a domain name illegitimately you will have no problem getting a completely legitimate certificate signed. But the fact that domain names are hierarchical means you have to trust one or two entities at most. That's why domain name theft is historically less common than illegitimate TLS certificates. You'll find all sorts of arguments that the CAs do more things than that and no end of security professionals who work for them. Some of these arguments are probably correct but that doesn't change the overall picture how a secure global TLS PKI should operate in the presence of domain names. It does the current system quite resistant to change however.

by chaz6 10y ago

rocqua 10y ago

Sure, the root keys of DNS are non-state operated, but they are used to sign the DNS-sec keys for the TLDs. These, in turn, are used to sign the keys for the nameserver responsible for serving the normal domain. For any country TLD domain (.us .uk .nl), those keys are held by a state actor. That TLD then gets to sign any lower level DNS servers. Say whomever controlled .com wanted to change the key for hackernews.com. They'd simply change the .NS record for hackernews.com to point to a different DNS box with different keys, that proxies DNS requests for the real server but re-signs them. It can then simply serve a new DANE record. (DANE records are the DNS-sec version of CAs). This is essentially the same procedure as a CA issuing a wrong certificate. The source of this problem is that you don't just need to trust the root DNS servers, but you also need to trust the TLD-servers that are signed by the root DNS servers. (And down recursively if there are more NS records in between)

xorcist 10y ago

You already trust the DNS root, as long as domain names are what certificates are based on. If you can transfer a domain name illegitimately you will have no problem getting a completely legitimate certificate signed. But the fact that domain names are hierarchical means you have to trust one or two entities at most. That's why domain name theft is historically less common than illegitimate TLS certificates. You'll find all sorts of arguments that the CAs do more things than that and no end of security professionals who work for them. Some of these arguments are probably correct but that doesn't change the overall picture how a secure global TLS PKI should operate in the presence of domain names. It does the current system quite resistant to change however.