Live data from Hacker News

For DNSSEC

blog.easydns.org

31–40 of 81 posts

Re: For DNSSEC

#31

Earlier quoted context omitted.

There is nothing stopping you from doing online signing with DNSSEC. FWIW, DNSSEC is on it's third major iteration, 2/3rds of the TLDs have deployed it, and major DNS service providers are getting into the act.

You can even avoid domain enumeration by doing online signing with DNSSEC. It's just that people still prefer the offline option.

And the offline signing option adds complexity to the protocol.

Re: For DNSSEC

#32
post #28
post #16

With the current CA system, you have to worry about far more than just the CAs. An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website. So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thou…

Is there a way to see if any CA has issued a cert for a site? If all CAs posted the certs they sign to some database, then there could be services that alert you and you'd know right away and raise an alarm. If such a system doesn't exist, why not?

I think a good chunk of the foot-dragging on CT has been a concern about customers not wanting certs for private names to be publicized (yet wanting publicly-valid certs for those names). It's unclear if there are concrete customers with this actual concern, but the argument goes that if Uber gets a cert issued for lyft-acquisition.uber.com in advance of an announcement, they don't want that leaked in CT logs.

The current Internet-Draft for RFC 6962bis allows them to register this in CT logs as "?.uber.com", which is enough for Uber's sysadmins to raise an alarm if something matching that pattern was issued without their knowledge.

https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#...

Re: For DNSSEC

#33

Earlier quoted context omitted.

> "There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This is from the zone enumeration section and plain DNS doesn't do anything to prevent zone enumeration by default either. > EdDSA We are working on standardizing EdDSA, but it takes a long time to get to deployment.

Good, come back when it's standardized. Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto

I thought part of successfully killing off '90s crypto was deploying useful, obviously-correct systems without waiting for standards committees to bikeshed them to death (cf. CFRG).

Re: For DNSSEC

#34
post #28

Earlier quoted context omitted.

Is there a way to see if any CA has issued a cert for a site? If all CAs posted the certs they sign to some database, then there could be services that alert you and you'd know right away and raise an alarm. If such a system doesn't exist, why not?

Certificate Transparency ( http://www.certificate-transparency.org ) is a Google initiative working on just that. It's already required for EV certs in Chrome.

Have any CAs publically committed to submit all their generated certs to that?

Does https://pki.google.com/ do that?

Re: For DNSSEC

#35

Earlier quoted context omitted.

> How do you sign a key/value data set with a certificate from Verisign? If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset. I just don't understand the point of your other questions: >Are there tools that can automatically follow this delegation? Just lis…

> Just list the domain. You'll see all delegations there. > Are you arguing that the specific certificates are better? Why? We seem to be having a communication issue. From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and clas…

Ah, I think the delegation problem with the X.509 / HTTPS PKI is a (fairly massive) implementation facepalm, not anything inherent to a PKI itself. So I think that's why people were confused by your statement "DNSSEC got PKI wrong" -- that doesn't seem wrong, it seems like a good thing for a PKI to support this. Do you think that a DNSSEC replacement should match the X.509 PKI in this regard?

Re: For DNSSEC

#36
post #6

Earlier quoted context omitted.

One of the problems is that it exposed DNS zone information, and one of the reason it did that was it was designed to require signing only once and after that the private key didn't have to be used again until the zone info changes.

Are you talking about zone enumeration? That's covered in the article.

Can you provide an NSEC white-lie response to an arbitrary query without an online key?

(I'm not sure if this is what was being asked, but I'm curious about the answer to that, either way.)

Re: For DNSSEC

#37
post #4

Earlier quoted context omitted.

DNSSEC has several problems some of which is in the design, as tptacek likes to mention.

This post directly addresses each point that Ptacek raised in his "Against DNSSEC" blogpost and FAQ.

Poorly and unconvincingly addresses. Same argument we've seen over and over -- now in a nice clean FAQ!

Doesn't change the design problems. Just tries to hide them behind half-truths and "but there's nothing better..."

Re: For DNSSEC

#38
post #36

Earlier quoted context omitted.

Are you talking about zone enumeration? That's covered in the article.

Can you provide an NSEC white-lie response to an arbitrary query without an online key? (I'm not sure if this is what was being asked, but I'm curious about the answer to that, either way.)

Don't think so.

Re: For DNSSEC

#39
post #34

Earlier quoted context omitted.

Certificate Transparency ( http://www.certificate-transparency.org ) is a Google initiative working on just that. It's already required for EV certs in Chrome.

Have any CAs publically committed to submit all their generated certs to that? Does https://pki.google.com/ do that?

Chrome currently requires that all extended-validation certs with an issuance date of 1/1/2015 or later be submitted to the CT logs. (Otherwise it will not show up in the UI as an EV cert.)

As with all browsers, only a subset of CAs are trusted to provide EV certs in the first place, regardless of whether they include the EV bits in the certificate. And this policy only applies to EV certs, not to all certs by an EV-capable CA.

Re: For DNSSEC

#40
post #35

Earlier quoted context omitted.

> Just list the domain. You'll see all delegations there. > Are you arguing that the specific certificates are better? Why? We seem to be having a communication issue. From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and clas…

Ah, I think the delegation problem with the X.509 / HTTPS PKI is a (fairly massive) implementation facepalm, not anything inherent to a PKI itself. So I think that's why people were confused by your statement "DNSSEC got PKI wrong" -- that doesn't seem wrong , it seems like a good thing for a PKI to support this. Do you think that a DNSSEC replacement should match the X.509 PKI in this regard?

Ah, that makes sense. Sorry for the confusion I created. I meant that DNSSEC PKI is wrong in the sense that it is hierarchical, and the root keys are centrally controlled by a biased party. A better PKI would probably look like Convergence [1], where trust is derived from a hybrid CA/"web of trust" system formed by a network of notaries.

The delegation implemented in DNSSEC is a good thing. I didn't think about how that feature would quite reasonably be lumped in with "PKI".

Oops.

[1]: http://convergence.io/

Post reply on HN