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.
For DNSSEC
31–40 of 81 posts
Re: For DNSSEC
#32With 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?
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
#33Earlier 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
Re: For DNSSEC
#34Earlier 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.
Does https://pki.google.com/ do that?
Re: For DNSSEC
#35Earlier 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…
Re: For DNSSEC
#36Earlier 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.
(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
#37Earlier 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.
Doesn't change the design problems. Just tries to hide them behind half-truths and "but there's nothing better..."
Re: For DNSSEC
#38Earlier 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.)
Re: For DNSSEC
#39Earlier 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?
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
#40Earlier 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?
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.