18 ms·

Standing reminder that friends don't let friends use DNSSEC, because it is crazy and provides no real security. With that in mind, it's fun to dive in and see w

Standing reminder that friends don't let friends use DNSSEC, because it is crazy and provides no real security. With that in mind, it's fun to dive in and see where the problems are ... Fundamentally this DANE idea swaps out the problems of a PKI CA hierarchy, the kind your browser is using when you actually log into gmail to read and send your e-mail, with the problems of DNSSEC. The biggest problems with PKI are that there are too many CAs, who can each go rogue, and that X509 is a horrifically awful format that takes a gigantic TCB to parse. Mitigations include browsers firing CAs and severely impacting their business (so effectively, there is regulation), certificate transparency and more and more testing. Either way you pretty much have to deal with these problems today though, an awful lot of e-mail is sent/received over HTTPS. The biggest problems with DNSSEC are that DNSSEC doesn't actually protect DNS queries at their most vulnerable points, that you have to trust your TLD provider, and the root operators completely, with no effective means to fire them, and finally that they almost certainly are using embarrassingly stupid crypto that even most ICOs could avoid. This very deck has several 1024-bit RSA keys, right there on a slide with a February 2018 timestamp, as if it's not an incredibly obviously stupid thing to do since the LogJam paper was published, or you know, when everyone stopped using them for TLS years ago. Actually wait, there's even a 512-bit key on another slide, using alg-5. That's RSA + SHA1!! What's the point of using all of those SHA256 MACs at the TLS Layer if everything depends on utterly breakable RSA plus SHA1 anyway? It's hard to take this seriously. PS. Yes, this is also my best impression of tptacek

swiley 9y ago
It's still an improvement over the way things where before (nothing at all, and complete blind faith in every part of the DNS and internet routing) and arguably better than CA which isn't that useful for email. Furthermore, the browsers replace the TLD in who you trust with CAs and in many cases it's practically difficult (or impossible) to "fire" your browser. I will agree that no one seems to use good crypto with DNSSEC though. The only people I know using it are using 512 bit RSA which is pretty horrifying.
- gruez 9y ago
  >it's practically difficult (or impossible) to "fire" your browser. You can reconfigure your trust store, and you can distrust a CA in a few clicks.
  - tptacek 9y ago
    Not only that, but Firefox and Chrome have "fired" some of the largest, "most important" CAs on the Internet. We know there's no TBTF problem with the Web PKI. But there is literally no way to fire a DNS TLD operator. In this scheme, they are prêt-à-porter TBTF.
    - Nullabillity 9y ago
      > We know there's no TBTF problem with the Web PKI. Hardly. Comodo is still around, and Symantec took years to be gradually distrusted. Hell, even the WoSign/StartSSL debacle started in Jan 2015, and they weren't removed before Jan 2017.
      - jcranmer 9y ago
        The WoSign issues became public around early September 2016 (maybe last week of August): https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&action=history https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&ac...
        gruez 9y ago
        not to mention that wosign came out in early 2015. https://news.ycombinator.com/item?id=8982013 https://news.ycombinator.com/item?id=8982013
      - tptacek 9y ago
        This is a rebuttal to some argument, but not mine.
- rphlx 9y ago
CiPHPerCoder 9y ago
What's the energy/time cost of breaking 512-bit RSA keys in 2018? I wonder if we could sign a message that says "DON'T USE DNSSEC" with their private key.
- gruez 9y ago
  probably not very expensive, considering it was broken in 2003. https://en.wikipedia.org/wiki/RSA_Factoring_Challenge#The_prizes_and_records https://en.wikipedia.org/wiki/RSA_Factoring_Challenge#The_pr...
- mikeyouse 9y ago
  In 2015, using Amazon EC2 and the bucket with: > This instance type has two Intel Xeon E5-2666 v3 processor chips, with 36 vCPUs in a NUMA configuration with 60 GB of RAM A team built a configuration that could factor a 512-bit RSA in four hours for $75. That was August 2015, so it would clearly cost much less and proceed much more quickly today. As a plus, they call out DNSSEC explicitly in their paper: https://eprint.iacr.org/2015/1000.pdf https://eprint.iacr.org/2015/1000.pdf
alwillis 9y ago
Good crypto for DNSSEC is available and is starting to gain traction: https://ed25519.nl https://ed25519.nl
- tptacek 9y ago
  Because of the architecture of DNSSEC, it's not in fact available until every DNSSEC resolver on the Internet supports it; until then, you have to keep bad crypto available, and expose users to downgrade attacks.
  - xorcist 9y ago
    That is equally true of the global TLS PKI. Protocols are notoriously hard to upgrade, and endpoint policy upgrades perhaps more so than most.
    - tptacek 9y ago
      No, that's not true, and the way you know it's not true is that there's such a thing as a Qualys SSLLabs grade, where it makes sense to talk about individual systems being secured against specific cryptographic attacks. DNSSEC is all-or-nothing. You can publish Ed25519 records (in theory), but for anyone to talk to you, you'll have to publish equivalent RSA records --- more importantly, every parent zone also needs to publish secure records, or else your Ed25519 records are just theater. TLDs still have RSA-1024 keys! DNSSEC advocates really want DNSSEC's security to asymptotically approach that of TLS, but in fact DNSSEC is far worse.
      - xorcist 9y ago
        How is that not equivalent to TLS? The fact that you can talk about invididual domains and their key length should be evidence enough that Qualys, or anyone else, could do the same. You can get a ed25519 certificate for your web server today too, but hardly anyone would be able to communicate securely with you. Until deployment reaches critical mass you are in need of a fallback. Sunsetting protocols are even harder, so there's complete equivalency there. The use of TLS is just orders of magnitude more deployed than DNSSEC. There's also no need to suggest I am an advocate of something when stating basic facts about it. Real world systems are dependent on DNSSEC today, and nothing you or I believe will change that. I will not discuss specifics, but I am sure you recognize its use within well known public protocols such as SMTP and SSH.
zeveb 9y ago
> The biggest problems with PKI are that there are too many CAs, who can each go rogue, and that X509 is a horrifically awful format that takes a gigantic TCB to parse. Mitigations include browsers firing CAs and severely impacting their business (so effectively, there is regulation), certificate transparency and more and more testing. Those are problems with XPKI, not with PKI in general. SPKI (RFCs 2692 & 2693) fixed them both — it really should have been picked up. It could be used to ensure that you really are talking to someone authorised to use a particular IP address and host name; it also uses a much lighter format than X.509's ASN.1 (and it's human-readable to boot!). I encourage anyone building a modern protocol to take a look at SPKI. Some parts of it need to be modernised, but that's easily-enough done. I'm not so worried about DNSSEC needing to trust TLD & root servers, because with domain-verified certs that's all you get anyway. I contend that domain verification (and IP verification, which to my knowledge no-one does) is good enough for most of what most of us need or want, and the customised SPKI certs could be used for the edge cases.
0x0 9y ago
You already have to trust the TLD operators today, since a rogue one could reply to a CA's domain validation requests as they please?
- jacobparker 9y ago
  Certficate transparency helps to mitigate that by creating a public audit log of certificate issuance.
  - xorcist 9y ago
    That depends entirely on best practice among CAs, something we've seen multiple CAs bend the rules on. Any one is enough to make the attack undetected. An attack against the global public DNSSEC would be much harder to mount undetected, as it is logged and cached by nature of its design.
    - tptacek 9y ago
      People say this constantly, as if attacks against DNSSEC would require intelligence services to alter the DNS across the entire Internet. But of course, that's not how states attack Internet connections and never has been: they subvert ISPs (which are often stated-owned, and almost invariably state-controlled) and pinpoint individual connections to manipulate. There's a hundred million dollar business of tools to facilitate this. It's not one of my best arguments against DNSSEC, but it is a valid one: the fact that the people designing and advocating for it don't appear to understand the Internet threat model.
      - xorcist 9y ago
        No one has made that statement. I pointed out that DNS by nature is cached and distributed. Not that it's impossible to manipulate, but that it in every circumstance is not worse than a TLS intercept, and in some cases less bad. DNSSEC did make one important design decision: Signing is offline. That alone makes the threat model different than with TLS, and makes for some interesting use cases.
phicoh 9y ago
I fully agree that 1024 bit RSA needs to go. Beyond that, if I take the insanely bad track record of CAs as a group, and compare to the (as far as I know) complete lack of serious attacks on DNSSEC (including even those with 1024 bit keys), then I would put my money on DNSSEC+DANE. For DANE you need to do client side validation. But that has been known for quite a while now. And there is code (for example getdns) to do that. For e-mail there is the additional complexity that DANE seems to be the only way to transition to SMTP over TLS without downgrade attacks.
- tptacek 9y ago
  Why would there have been any attacks on DNSSEC? Literally no real-world system relies on it right now. It's "deployed" on a small subset of large networks, but not in ways where those networks are materially exposed if DNSSEC fails. As for SMTP: the IETF is pursuing STS, which breaks that downgrade attack the same way HSTS does for the web (except far more powerfully, since the most important MTA relationships are far more stable than the web's), with an explicit design goal of not relying on DANE --- which nobody uses.
  - phicoh 9y ago
    Plenty of published attacks are not all that practical. There are plenty of security researchers that would like to have some nice attacks on their CVs. If you like the security of HSTS, then I guess STS is for you. Personally I'd like something better then just blindly trusting the network the first time you try to connect to something.
    - tptacek 9y ago
      Security researchers generally do not in fact spend a lot of time attacking systems that nobody uses. But in the sense that you're referring to, BIND, the de facto standard Internet DNS server, has one of the worst records in all of software security.
      - xorcist 9y ago
jcrites 9y ago
> Either way you pretty much have to deal with these problems today though, an awful lot of e-mail is sent/received over HTTPS Nitpick: I believe you meant to say TLS rather than HTTPS. The majority of sending indeed takes place over TLS, at least between top-tier senders and ISPs. Google's Safer Email Transparency Report shows how many inbound and outbound connections to/from Gmail are protected by TLS, and the numbers have been climbing steadily in recent years: https://transparencyreport.google.com/safer-email/overview https://transparencyreport.google.com/safer-email/overview
- colmmacc 9y ago
  Nope! I mean https, most people send and receive email on a browser.
xorcist 9y ago
> DNSSEC doesn't actually protect DNS queries at their most vulnerable points That would make it useless if true. Are you talking about trusting an external resolver? I haven't seen any real world deployments like that. > you have to trust your TLD provider, and the root operators completely You already have to trust them. They are the authoritative source of who owns a domain. In a perfect world, they could assert that ownership cryptographically. The bit about weak crypto deployments however are completely correct. That needs to be fixed. Improving the situation takes time, and there are aligned economic and national interests in maintaining the global CA model with its numerous trust points.
- dogecoinbase 9y ago
  > DNSSEC doesn't actually protect DNS queries at their most vulnerable points That would make it useless if true. Correct. Clients do not validate DNSSEC and clients cannot be made to do so until DNSSEC deployment is universal (at which point you still have several other problems).
  - phicoh 9y ago
    You are saying that the ssh client that I have that locally validates SSHFP records using getdns doesn't actually work because DNSSEC is not universally deployed? Strange if something I've been using for a couple of years cannot exist.
    - dogecoinbase 9y ago
      You are correct that using previously obtained information over a secure channel will allow you to continue connecting to an unchanged endpoint. Again, not helpful when connecting to new or changed endpoints over an untrusted path unless you assume that all endpoint implement the mechanism (and, of course, that you trust the CA).
      - xorcist 9y ago
        SSH does not operate with trust-on-first-use when using DNSSEC. It will not store key information locally in that case, specifically to be able to operate with changed endpoints over untrusted networks.
rphlx 9y ago
> Mitigations include browsers firing CAs and severely impacting their business (so effectively, there is regulation) Nit: Not when the browser developer and CA are part of one entity. Excepting some major change to corporate structure, there are presumably no or very nearly no circumstances under which Chrome will permanently remove the Google CAs. Their behavior is therefore essentially unregulated WRT Chrome users.
- tptacek 9y ago
  If you don't trust your browser vendor, none of these protections matter.
  - rphlx 9y ago
    I agree with that. But that point is orthogonal to the (in)validity of the "CAs are effectively regulated by browser vendors" argument I was commenting on.
ietf-dane 9y ago
Other big problems with WebPKI: * DV certificate issuance is based on a leap of faith (TOFU) by the CA. It is vulnerable to BGP hijack, DNS cache poisoning, ... as amply illustrated by the "domain control" "proofs" in ACME. * The CA ecosystem is dying with Let's Encrypt's free certs removing the raison d'etre for most of the other CAs. Actual verification of identity does not scale, and DV "domain control" "verification" does not pay. Crypto: * The use of SHA1 in DNSSEC is not subject to collision attacks, only 2nd pre-image resistance is required, and there's no hint of SHA1 (or even MD5!) 2nd pre-images any time soon. While moving to SHA256 makes sense, there's no real problem with SHA1 in DNSSEC, it is adequately secure. * The domains using 512-bit keys are a tiny minority hosted by a couple of DNS hosting providers (one of them "free", so you get what you pay for). * Most zones have 2048-bit KSKs, and 1024-bit ZSKs. This can be addressed as more domains deploy ECDSA or 1280-bit and 1536-bit RSA keys (which have an estimated work-factor of 89 and 96 bits respectively, and there is ). The root zone keys are 2048 bits for both KSK and ZSK, and 1 in 3 TLDs has 1280-bit ZSKs, more will do that or switch to EC. * Logjam researchers estimated the cost for a single widely used DH key (embedded as a constant in software): "The researchers calculated the cost of creating logjam precomputation for one 1024-bit prime at hundreds of millions of USD". This is somewhat specific to DH rather than RSA, and leverages the fact that many users used the same fixed DH groups. ZSKs are not fixed and vary across providers. * Many estimates of RSA factoring cost ignore memory costs, for a more realistic analysis, see https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e68394bcf9f52bf.pdf https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e... Finally: the talk is about improving on unauthenticated opportunistic TLS in SMTP. The right comparison is with downgrades to cleartext, not with the latest fashionable crypto in browsers. The browsers moving from 1024-bit RSA directly to 2048-bit RSA is a bit of power-of-two numerology and was overkill (better optics more than better engineering). They did it because signing and verification are still adequately fast, so they can get away with turning it up to 11. That does not mean that more modest key sizes are not effective. Since DNSSEC is used only to authentication, not key agreement, there's no risk from future key compromise once a key is retired, so keys don't need to remain secure for decades, just a few months (for a ZSK) is enough. Generally, real-world attacks bypass the crypto and attack far weaker defenses. Why break the crypto when you can subpoena the private key material, install malware on the end-systems, break TOFU certificate issuance... Smug attacks on DNSSEC ignore many deficiencies of the alternatives, and are I suggest a case of letting the perfect be the enemy of the good.

swiley 9y ago

It's still an improvement over the way things where before (nothing at all, and complete blind faith in every part of the DNS and internet routing) and arguably better than CA which isn't that useful for email. Furthermore, the browsers replace the TLD in who you trust with CAs and in many cases it's practically difficult (or impossible) to "fire" your browser. I will agree that no one seems to use good crypto with DNSSEC though. The only people I know using it are using 512 bit RSA which is pretty horrifying.

gruez 9y ago
>it's practically difficult (or impossible) to "fire" your browser. You can reconfigure your trust store, and you can distrust a CA in a few clicks.
- tptacek 9y ago
  Not only that, but Firefox and Chrome have "fired" some of the largest, "most important" CAs on the Internet. We know there's no TBTF problem with the Web PKI. But there is literally no way to fire a DNS TLD operator. In this scheme, they are prêt-à-porter TBTF.
  - Nullabillity 9y ago
    > We know there's no TBTF problem with the Web PKI. Hardly. Comodo is still around, and Symantec took years to be gradually distrusted. Hell, even the WoSign/StartSSL debacle started in Jan 2015, and they weren't removed before Jan 2017.
    - jcranmer 9y ago
      The WoSign issues became public around early September 2016 (maybe last week of August): https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&action=history https://wiki.mozilla.org/index.php?title=CA:WoSign_Issues&ac...
      - gruez 9y ago
        not to mention that wosign came out in early 2015. https://news.ycombinator.com/item?id=8982013 https://news.ycombinator.com/item?id=8982013
    - tptacek 9y ago
      This is a rebuttal to some argument, but not mine.
rphlx 9y ago

CiPHPerCoder 9y ago

What's the energy/time cost of breaking 512-bit RSA keys in 2018? I wonder if we could sign a message that says "DON'T USE DNSSEC" with their private key.

gruez 9y ago
probably not very expensive, considering it was broken in 2003. https://en.wikipedia.org/wiki/RSA_Factoring_Challenge#The_prizes_and_records https://en.wikipedia.org/wiki/RSA_Factoring_Challenge#The_pr...
mikeyouse 9y ago
In 2015, using Amazon EC2 and the bucket with: > This instance type has two Intel Xeon E5-2666 v3 processor chips, with 36 vCPUs in a NUMA configuration with 60 GB of RAM A team built a configuration that could factor a 512-bit RSA in four hours for $75. That was August 2015, so it would clearly cost much less and proceed much more quickly today. As a plus, they call out DNSSEC explicitly in their paper: https://eprint.iacr.org/2015/1000.pdf https://eprint.iacr.org/2015/1000.pdf

alwillis 9y ago

Good crypto for DNSSEC is available and is starting to gain traction: https://ed25519.nl https://ed25519.nl

tptacek 9y ago
Because of the architecture of DNSSEC, it's not in fact available until every DNSSEC resolver on the Internet supports it; until then, you have to keep bad crypto available, and expose users to downgrade attacks.
- xorcist 9y ago
  That is equally true of the global TLS PKI. Protocols are notoriously hard to upgrade, and endpoint policy upgrades perhaps more so than most.
  - tptacek 9y ago
    No, that's not true, and the way you know it's not true is that there's such a thing as a Qualys SSLLabs grade, where it makes sense to talk about individual systems being secured against specific cryptographic attacks. DNSSEC is all-or-nothing. You can publish Ed25519 records (in theory), but for anyone to talk to you, you'll have to publish equivalent RSA records --- more importantly, every parent zone also needs to publish secure records, or else your Ed25519 records are just theater. TLDs still have RSA-1024 keys! DNSSEC advocates really want DNSSEC's security to asymptotically approach that of TLS, but in fact DNSSEC is far worse.
    - xorcist 9y ago
      How is that not equivalent to TLS? The fact that you can talk about invididual domains and their key length should be evidence enough that Qualys, or anyone else, could do the same. You can get a ed25519 certificate for your web server today too, but hardly anyone would be able to communicate securely with you. Until deployment reaches critical mass you are in need of a fallback. Sunsetting protocols are even harder, so there's complete equivalency there. The use of TLS is just orders of magnitude more deployed than DNSSEC. There's also no need to suggest I am an advocate of something when stating basic facts about it. Real world systems are dependent on DNSSEC today, and nothing you or I believe will change that. I will not discuss specifics, but I am sure you recognize its use within well known public protocols such as SMTP and SSH.

zeveb 9y ago

> The biggest problems with PKI are that there are too many CAs, who can each go rogue, and that X509 is a horrifically awful format that takes a gigantic TCB to parse. Mitigations include browsers firing CAs and severely impacting their business (so effectively, there is regulation), certificate transparency and more and more testing. Those are problems with XPKI, not with PKI in general. SPKI (RFCs 2692 & 2693) fixed them both — it really should have been picked up. It could be used to ensure that you really are talking to someone authorised to use a particular IP address and host name; it also uses a much lighter format than X.509's ASN.1 (and it's human-readable to boot!). I encourage anyone building a modern protocol to take a look at SPKI. Some parts of it need to be modernised, but that's easily-enough done. I'm not so worried about DNSSEC needing to trust TLD & root servers, because with domain-verified certs that's all you get anyway. I contend that domain verification (and IP verification, which to my knowledge no-one does) is good enough for most of what most of us need or want, and the customised SPKI certs could be used for the edge cases.

0x0 9y ago

You already have to trust the TLD operators today, since a rogue one could reply to a CA's domain validation requests as they please?

jacobparker 9y ago
Certficate transparency helps to mitigate that by creating a public audit log of certificate issuance.
- xorcist 9y ago
  That depends entirely on best practice among CAs, something we've seen multiple CAs bend the rules on. Any one is enough to make the attack undetected. An attack against the global public DNSSEC would be much harder to mount undetected, as it is logged and cached by nature of its design.
  - tptacek 9y ago
    People say this constantly, as if attacks against DNSSEC would require intelligence services to alter the DNS across the entire Internet. But of course, that's not how states attack Internet connections and never has been: they subvert ISPs (which are often stated-owned, and almost invariably state-controlled) and pinpoint individual connections to manipulate. There's a hundred million dollar business of tools to facilitate this. It's not one of my best arguments against DNSSEC, but it is a valid one: the fact that the people designing and advocating for it don't appear to understand the Internet threat model.
    - xorcist 9y ago
      No one has made that statement. I pointed out that DNS by nature is cached and distributed. Not that it's impossible to manipulate, but that it in every circumstance is not worse than a TLS intercept, and in some cases less bad. DNSSEC did make one important design decision: Signing is offline. That alone makes the threat model different than with TLS, and makes for some interesting use cases.

phicoh 9y ago

I fully agree that 1024 bit RSA needs to go. Beyond that, if I take the insanely bad track record of CAs as a group, and compare to the (as far as I know) complete lack of serious attacks on DNSSEC (including even those with 1024 bit keys), then I would put my money on DNSSEC+DANE. For DANE you need to do client side validation. But that has been known for quite a while now. And there is code (for example getdns) to do that. For e-mail there is the additional complexity that DANE seems to be the only way to transition to SMTP over TLS without downgrade attacks.

tptacek 9y ago
Why would there have been any attacks on DNSSEC? Literally no real-world system relies on it right now. It's "deployed" on a small subset of large networks, but not in ways where those networks are materially exposed if DNSSEC fails. As for SMTP: the IETF is pursuing STS, which breaks that downgrade attack the same way HSTS does for the web (except far more powerfully, since the most important MTA relationships are far more stable than the web's), with an explicit design goal of not relying on DANE --- which nobody uses.
- phicoh 9y ago
  Plenty of published attacks are not all that practical. There are plenty of security researchers that would like to have some nice attacks on their CVs. If you like the security of HSTS, then I guess STS is for you. Personally I'd like something better then just blindly trusting the network the first time you try to connect to something.
  - tptacek 9y ago
    Security researchers generally do not in fact spend a lot of time attacking systems that nobody uses. But in the sense that you're referring to, BIND, the de facto standard Internet DNS server, has one of the worst records in all of software security.
    - xorcist 9y ago

jcrites 9y ago

> Either way you pretty much have to deal with these problems today though, an awful lot of e-mail is sent/received over HTTPS Nitpick: I believe you meant to say TLS rather than HTTPS. The majority of sending indeed takes place over TLS, at least between top-tier senders and ISPs. Google's Safer Email Transparency Report shows how many inbound and outbound connections to/from Gmail are protected by TLS, and the numbers have been climbing steadily in recent years: https://transparencyreport.google.com/safer-email/overview https://transparencyreport.google.com/safer-email/overview

colmmacc 9y ago
Nope! I mean https, most people send and receive email on a browser.

xorcist 9y ago

> DNSSEC doesn't actually protect DNS queries at their most vulnerable points That would make it useless if true. Are you talking about trusting an external resolver? I haven't seen any real world deployments like that. > you have to trust your TLD provider, and the root operators completely You already have to trust them. They are the authoritative source of who owns a domain. In a perfect world, they could assert that ownership cryptographically. The bit about weak crypto deployments however are completely correct. That needs to be fixed. Improving the situation takes time, and there are aligned economic and national interests in maintaining the global CA model with its numerous trust points.

dogecoinbase 9y ago
> DNSSEC doesn't actually protect DNS queries at their most vulnerable points That would make it useless if true. Correct. Clients do not validate DNSSEC and clients cannot be made to do so until DNSSEC deployment is universal (at which point you still have several other problems).
- phicoh 9y ago
  You are saying that the ssh client that I have that locally validates SSHFP records using getdns doesn't actually work because DNSSEC is not universally deployed? Strange if something I've been using for a couple of years cannot exist.
  - dogecoinbase 9y ago
    You are correct that using previously obtained information over a secure channel will allow you to continue connecting to an unchanged endpoint. Again, not helpful when connecting to new or changed endpoints over an untrusted path unless you assume that all endpoint implement the mechanism (and, of course, that you trust the CA).
    - xorcist 9y ago
      SSH does not operate with trust-on-first-use when using DNSSEC. It will not store key information locally in that case, specifically to be able to operate with changed endpoints over untrusted networks.

rphlx 9y ago

> Mitigations include browsers firing CAs and severely impacting their business (so effectively, there is regulation) Nit: Not when the browser developer and CA are part of one entity. Excepting some major change to corporate structure, there are presumably no or very nearly no circumstances under which Chrome will permanently remove the Google CAs. Their behavior is therefore essentially unregulated WRT Chrome users.

tptacek 9y ago
If you don't trust your browser vendor, none of these protections matter.
- rphlx 9y ago
  I agree with that. But that point is orthogonal to the (in)validity of the "CAs are effectively regulated by browser vendors" argument I was commenting on.

ietf-dane 9y ago

Other big problems with WebPKI: * DV certificate issuance is based on a leap of faith (TOFU) by the CA. It is vulnerable to BGP hijack, DNS cache poisoning, ... as amply illustrated by the "domain control" "proofs" in ACME. * The CA ecosystem is dying with Let's Encrypt's free certs removing the raison d'etre for most of the other CAs. Actual verification of identity does not scale, and DV "domain control" "verification" does not pay. Crypto: * The use of SHA1 in DNSSEC is not subject to collision attacks, only 2nd pre-image resistance is required, and there's no hint of SHA1 (or even MD5!) 2nd pre-images any time soon. While moving to SHA256 makes sense, there's no real problem with SHA1 in DNSSEC, it is adequately secure. * The domains using 512-bit keys are a tiny minority hosted by a couple of DNS hosting providers (one of them "free", so you get what you pay for). * Most zones have 2048-bit KSKs, and 1024-bit ZSKs. This can be addressed as more domains deploy ECDSA or 1280-bit and 1536-bit RSA keys (which have an estimated work-factor of 89 and 96 bits respectively, and there is ). The root zone keys are 2048 bits for both KSK and ZSK, and 1 in 3 TLDs has 1280-bit ZSKs, more will do that or switch to EC. * Logjam researchers estimated the cost for a single widely used DH key (embedded as a constant in software): "The researchers calculated the cost of creating logjam precomputation for one 1024-bit prime at hundreds of millions of USD". This is somewhat specific to DH rather than RSA, and leverages the fact that many users used the same fixed DH groups. ZSKs are not fixed and vary across providers. * Many estimates of RSA factoring cost ignore memory costs, for a more realistic analysis, see https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e68394bcf9f52bf.pdf https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e... Finally: the talk is about improving on unauthenticated opportunistic TLS in SMTP. The right comparison is with downgrades to cleartext, not with the latest fashionable crypto in browsers. The browsers moving from 1024-bit RSA directly to 2048-bit RSA is a bit of power-of-two numerology and was overkill (better optics more than better engineering). They did it because signing and verification are still adequately fast, so they can get away with turning it up to 11. That does not mean that more modest key sizes are not effective. Since DNSSEC is used only to authentication, not key agreement, there's no risk from future key compromise once a key is retired, so keys don't need to remain secure for decades, just a few months (for a ZSK) is enough. Generally, real-world attacks bypass the crypto and attack far weaker defenses. Why break the crypto when you can subpoena the private key material, install malware on the end-systems, break TOFU certificate issuance... Smug attacks on DNSSEC ignore many deficiencies of the alternatives, and are I suggest a case of letting the perfect be the enemy of the good.