5 ms·

This CA system is designed for maximum reduction in security - not defense in depth. The company with the least security defines the security of the entire CA s

• some_furry 6y ago
  I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec https://sockpuppet.org/blog/2015/01/15/against-dnssec
  • cjbprime 6y ago
    Agree with you, it's entirely incorrect that a CT log operator "defines the security of the entire CA system". They can't issue certs and their output is already regarded with suspicion by default.
  • rasengan 6y ago
    > I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. I think this would be true except my statement wasn't just about SCT but the CA system in general. Furthermore, browsers like Firefox [1] do not even have CT checks. > Also, DANE relies on DNSSEC [1], which is bad. Handshake completes this system [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 [1a] https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency https://developer.mozilla.org/en-US/docs/Web/Security/Certif... [2] https://github.com/handshake-org/hdns https://github.com/handshake-org/hdns
    • Spivak 6y ago
      Despite being supported, relying on browsers checking CT logs was never something that what going to be deployed at scale because, just like revocation lists, it adds a performance hurdle to every request. Auditors and monitors are the real protection you get from CT logs. You get the same problem with any form of DNS validation because you'll never get every little caching server to validate records.
    • tptacek 6y ago
      Just so everyone's clear about this, Handshake is a system backed by a cryptocurrency, "HNS", that is actively traded despite being useful only to speculators. Its backers believe that they'll take over control of the Internet and be rewarded financially for it through their currency. If that works, I call ARPcoin next.
  • pinhead26 6y ago
    Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier already DNSSEC is Incomplete -> Agreed, we need browser adoption
    • CiPHPerCoder 6y ago
      > Not if the root of trust is secured by a proof-of-work blockchain https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology https://paragonie.com/blog/2017/07/chronicle-will-make-you-q... > Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 https://tools.ietf.org/html/rfc6605 First: That's a big "if". Lots of RSA legacy support. Furthermore, ECDSA is so bad that Ed25519 and Ed448 are even coming to FIPS 186-5 later this year. Citing ECDSA adoption in DNSSEC doesn't make as strong of a case as you might think.
      • dane-pgp 6y ago
        For context, some statistics: "Currently [2018], in more than 90% of cases if a user passes DNS queries to a resolver that performs DNSSEC validation of an RSA digital signature the same resolver will also perform DNSSEC validation of ECDSA P-256 digital signatures." https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-an-update/ https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-... "Since the second quarter of 2019 [to the first quarter of 2020], the population of [strict DNSSEC] validating users has risen from 12% to 22%, close to doubling. At the same time, the proportion of [non-strict DNSSEC validating] users has risen from 5% to 10%." https://blog.apnic.net/2020/03/02/dnssec-validation-revisited/ https://blog.apnic.net/2020/03/02/dnssec-validation-revisite...
    • dane-pgp 6y ago
• Avamander 6y ago
  How would you monitor that your DNS provider hasn't changed your DANE records and intercepted traffic?