Re: [dns-operations] summary of recent vulnerabilities in DNS security.
your text above shows a drastic misunderstanding of both dns and dnssec. a correctly functioning recursive name server will not promote additional or authority data to answers. poison glue in a cache can cause poison referrals, or poisoned iterations, but not poisoned answers given to applications who called gethostbyname(). dnssec was crafted with this principle firmly in mind, and the lack of signatures over glue is quite deliberate -- not an oversight -- not a weakness. Poisoning resolvers' caches is one issue, and what the resolvers return to applications is a different matter. IMHO `cache poisoning` is accepting and caching spoofed records. Cache poisoning is a building block that can be applied for more complex attacks, e.g., to redirect applications to malicious servers or for DoS attacks. As I wrote in an earlier email, poisoning glue records can result in denial of service attacks on resolvers, since they _cache_ those spoofed records (although they do not return them to applications). You have not addressed this concern in your response, the issue you discuss is different and it is what applications receive from resolvers. The vulnerability that I pointed out, is not related to returning the spoofed glue records to applications. The question whether DoS (as a result of cache poisoning) is a weakeness is a different issue, I simply wrote that we identified this new vulnerability, that even validating resolvers can cache spoofed glue from attacker, and then remain stuck with those records (which may result in degradation/denial of service). thanks for clarifying that. i cannot credit your work in the section of my article where i wrote about fragmentation, because you were not the discoverer. in 2008, during the 'summer of fear' inspired by dan kaminsky's bug, i was a personal information hub among a lot of the dns industry. at one point florian weimer of BFK called me with a concern about fragmentation related attacks. i brought kaminsky into the conversation and the three of us brainstormed on and off for a week or so as to how to use fragments in a way that could cause dnssec data to be accepted as cryptoauthentic. we eventually gave up, alas, without publishing our original concerns, our various theories as to how it might be done, and why each such theory was unworkable. i was happy to cite your work in my references section because your explaination is clear and cogent, but since you were not the discoverer, i won't be crediting you as such. Florian wrote in his response to me on this mailing list that he believed that the attack was not feasible since he did not succeed at deploying it. He identified that there was a vulnerability but did not provide a way to exploit it. For instance, Bernstein identified vulnerability with predictable ports long before Kaminsky attacks, yet you still call that attack `Kaminsky attack`. The point is: claiming that P not equals NP won't credit you the result, if someone else does the proof. Unless I am misunderstading, there was no published vulnerability prior to our result. Please clarify if I am wrong. your answer is evasive and nonresponsive, and i beg you to please try again, remembering that the vulnerabilities you are reporting and the workarounds you're recommending will be judged according to engineering economics. if we assume that dnssec is practical on a wide enough scale that it could prevent the vulnerabilities you are reporting on, then your work is of mainly academic interest. as vernon said earlier today, none of the vulnerabilities you are reporting on have been seen in use. i also agree with vernon's assessment that none of them will ever be seen in use. Even if they are of academic interest only, I still hope that the Internet community can learn from them, and have an option to protect themselves. Regarding applicability: initially there were claims that this attack was not feasible in lab setting (btw none with clear explaination why it is not feasible). I am glad that now that other groups are/have also validated them this has changed. Once a vulnerability is found, it will eventually be exploited, and the vulnerabilities that we found allow stealth attacks - so I think claiming that they are not launched in the wild is not based on a solid proof. BTW, I will appreciate it if you could clarify why you think they are not applicable and cannot be launched in the wild. As part of the research measurements that I do currently, I am running evaluations (against my own domain of course), and there are vulnerable networks (there are also networks that are not vulnerable to fragmentation attacks - e.g., since they block fragmented responses). that's too many e.g.'s and external references for me to follow. each fragmentary concept you've listed above strikes me as a nonsequitur for source port randomization. can you dumb it down for me, please? I think you asked me to provide few examples of
Re: [dns-operations] Can MX be working with CNAME?
Jeroen Massar jer...@massar.ch wrote: Don't use CNAMEs in combination with RRs which point to other names And thus CNAME - MX - A falls under that too. No, it is only names in RDATA that should not refer to CNAMEs. In practice, this depends a lot in the RR in question. NS pointing to CNAME is not going to work. MX pointing to CNAME probably will work. CNAME pointing to anything should work, except for the historical screwup in the way mail software handles CNAME. Note that this does not just affect CNAME pointing to MX, but also CNAME pointing to A and CNAME pointing to , when the CNAME is used as a mail domain. The problem with the above specifically is that Sendmail will cause some issues, as it will lookup the CNAME, and replace all headers with the destination, [...] Sendmail is one of the few and maybe only SMTP server that does though and hence you will just get very inconsistent results depending if the remote site (which you do not control) still uses that. This is a remnant of the pre-DRUMS email specifications, in particular the requirement in RFC 821 that domain aliases (i.e. CNAMEs) are not allowed in mail, and the clarification in RFC 1123 that CNAMEs should be interpreted as instructions to rewrite domains. Other MTAs do similar things, for instance qmail rewrites envelope domains (but not message headers) - http://fanf.livejournal.com/10.html The IETF Detailed Revision and Update of Messaging Standards working group decided to remove the ban on CNAME domains in the 1990s. But they are still an interop disaster. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
My problem with your findings is that your are grossly overstating their significance. None of them will ever be seen in the wild. As As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and as I've said, showing the inevitiable weakness of port randomization is good. We found and described the vulnerability and showed how to apply it against standard and patched resolvers. Can you please clarify in what way our results `grossly overstate` significance? Your second argument is not precise, we, and recently others, showed these attacks to be practical. Could you please explain why you are certain that the attacks do not pose a practical risk? I'm sorry, but I think the mention of DNSSEC in your paper exists only because others forced it. I'm forced to that belief by various things including your refusal admit the obvious about relative priorities and by statements like that sentence above that suggests that fixing port randomization could be easier than deploying DNSSEC in any except quite exceptional cases. This conspiracy theory is intriguing... On Sat, Oct 19, 2013 at 7:14 PM, Haya Shulman haya.shul...@gmail.comwrote: IMHO, DNSSEC is simply the natural defense against the attacks, which is why I did not explicitly mention it, but I definitely had it in mind :-) Regarding the proxy-behind-upstream: to prevent the attacks DNSSEC has to be deployed(and validated) on the proxy. Currently it seems that there are proxies that signal support of DNSSEC (via the DO bit), but do not validate responses, and validation is typically performed by the upstream forwarder. --- The complete absense of any mention of DNSSEC among those recommendations (or elsewhere) reads like an implicit claim that DNSSEC would not help. Even if that claim was not intended, would it be accurate? Would DNSSEC make any of recommendations less necessary or perhaps even moot? If DNSSEC by itself would be effective against cache poisoning, then isn't it among the recommendations, especially for Resolver-behind-Upstream? Why aren't efforts to protect port randomization, hide hidden servers and so forth like trying to make it safe to use .rhosts and /etc/hosts.equiv files by filtering ICMP dedirects and IP source routing, and strengthening TCP initial sequence numbers? On Sat, Oct 19, 2013 at 6:53 PM, Haya Shulman haya.shul...@gmail.comwrote: This is correct, the conclusion from our results (and mentioned in all our papers on DNS security) is to deploy DNSSEC (fully and correctly). We are proponents of cryptographic defenses, and I think that DNSSEC is the most suitable (proposed and standardised) mechanism to protect DNS against cache poisoning. Deployment of new Internet mechanisms is always challenging (and the same applies to DNSSEC). Therefore, we recommend short term countermeasures (against vulnerabilities that we found) and also investigate mechanisms to facilitate deployment of DNSSEC. On Sat, Oct 19, 2013 at 6:05 PM, Phil Regnauld regna...@nsrc.org wrote: P Vixie (paul) writes: M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie I was wondering about that, and went to look at the abstracts: http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 Security of Patched DNS [...] We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of DNSSEC (or other MitM-secure defenses). So at least this seems to be mentioned in the papers themselves (Id didn't pay to find out). But I agree that the summary would benefit from stating this, as it's currently only way to to avoid poisoning. Not stating it could lead some to believe that these attacks are immune to DNSSEC protection of the cache. Cheers, Phil -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can MX be working with CNAME?
Tony Finch wrote: Jeroen Massar wrote: Don't use CNAMEs in combination with RRs which point to other names And thus CNAME - MX - A falls under that too. No, it is only names in RDATA that should not refer to CNAMEs. CNAMES (and DNAMEs in a different form) cause all kinds of unexpected things, this is one of them. In practice, this depends a lot in the RR in question. NS pointing to CNAME is not going to work. MX pointing to CNAME probably will work. In practice you will find that Sendmail is a pain in a place. It will use the CNAME to rewrite all the headers involved as I indicated. CNAME pointing to anything should work, except for the historical screwup in the way mail software handles CNAME. Note that this does not just affect CNAME pointing to MX, but also CNAME pointing to A and CNAME pointing to , when the CNAME is used as a mail domain. Current Sendmail still does this. Hence why I highlighted this problem. Set up a sendmail default out of the box on a Debian box for instance and you will find this problem to be true when you use CNAMEs anywhere in the MX (thus either 'domain CNAME somethingelse MX final' or domain MX final CNAME somethingelse' will cause this). Greets, Jeroen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
From: Haya Shulman haya.shul...@gmail.com My problem with your findings is that your are grossly overstating their significance. None of them will ever be seen in the wild. As As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and as I've said, showing the inevitiable weakness of port randomization is good. We found and described the vulnerability and showed how to apply it against standard and patched resolvers. Can you please clarify in what way our results `grossly overstate` significance? Your claims that your issues are a significant security problem are grossly exaggerated, because they will never be seen in the wild. Your second argument is not precise, we, and recently others, showed these attacks to be practical. Could you please explain why you are certain that the attacks do not pose a practical risk? The existence of a vulnerability does not imply that it will be used. Bad guys only use profitable attacks, whether the profit is mischief or money. Exploiting your vulernabilities is too hard (less profitable) compared to other vulnerabilities. I'm sorry, but I think the mention of DNSSEC in your paper exists only because others forced it. I'm forced to that belief by various things including your refusal admit the obvious about relative priorities and by statements like that sentence above that suggests that fixing port randomization could be easier than deploying DNSSEC in any except quite exceptional cases. This conspiracy theory is intriguing... It would be conspiracy thinking if I claimed you worked with others to (not) do something. I'm only extrapolating from your consistent evasions of my question about the relative importance of port randomization and DNSSEC. I notice that besides not answering the priority question, you also did not say where we can read your paper to see whether you mention DNSSEC only as a coerced afterthought. However, I've been asking and you've been evading the wrong question. Whether DNSSEC work should be done before or after randomizing ports is moot, because I think everyone who might randomize DNS ports while it matters has already done so. The major DNS implementors have also done most of what they can for DNSSEC. That various junk CPE forwarders, proxies, and resolvers doesn't randomize won't be changed while it matters. Those vendors and their ISP customers aren't listening and care about neither DNSSEC nor port randomization. The only people who might act on your issues are DNS user who cannot do anything about port randomization but could deploy DNSSEC. And that brings me to something bad. Your are giving people an excuse to continue not deploying DNSSEC. By not admitting that DNSSEC is more important than randomizing ports, you are encouraging people to continue waiting for others to fix the problem. They are often the same people who are waiting for everyone else to comply with BCP 38. Note that BCP 38 violations would probably figure in any real exploit of your issues. ... } From: Haya Shulman haya.shul...@gmail.com } This year there were a number of injection attacks against TCP exploiting } port randomisation algorithms recommended in [RFC6056]. Once port is known, } TCP sequence number does not pose a significant challenge (although it is } 32 bits, it is incremented sequentially within the connection and there are } techniques to predict it) Port randomisation would prevent injections into } TCP. } For instance, name server pinning, identifying victim instances on cloud, } derandomisation of communication over TOR. There are limitations to these } attacks, but IMHO even if there are only few networks to which these } attacks apply - these are still attacls. Port randomisation would prevent } these attacks of course since the attacker would not know which . } Port randomisation was also proposed as a countermeasure against DoS } attacks (e.g., see here Denial of service protection with beaver). } } Please clarify why you think that port randomisation cannot prevent the } attacks described above. That is more wrong that right. Port randomization is worth doing, but it is a minor issue among TCP application security issues. Port randomization helps little because the range of ephemeral ports is tiny and so cannot contain much entropy. Attacks based on predicting TCP sequence numbers require either being able to see TCP sequence numbers, in which case you can also see port numbers, or brute force. If you're flooding the target hoping to it a TCP window, you need only increase your flood to hit a random port. } Bernstein identified preditable ports to be vulnerable long ago, it is } surprising to me, that after so many years, the community is still not } convinced that port randomisation is signfiicant. Outside the Steve Gibson School of Internet Security, significance is relative. There will always be an infinite number of vulnerabilities. Competent defenses don't
Re: [dns-operations] Can MX be working with CNAME?
Once upon a time, Jo Rhett jrh...@netconsonance.com said: On Oct 21, 2013, at 4:37 AM, Tony Finch d...@dotat.at wrote: MX pointing to CNAME probably will work. Not in my experience. Not with either sendmail or postfix. I've (unfortunately) seen many domains set up MX-CNAME-A, and sendmail and postfix both delivered to them just fine. -- Chris Adams c...@cmadams.net ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can MX be working with CNAME?
On 2013-10-21 16:26 , Chris Adams wrote: Once upon a time, Jo Rhett jrh...@netconsonance.com said: On Oct 21, 2013, at 4:37 AM, Tony Finch d...@dotat.at wrote: MX pointing to CNAME probably will work. Not in my experience. Not with either sendmail or postfix. I've (unfortunately) seen many domains set up MX-CNAME-A, and sendmail and postfix both delivered to them just fine. If lucky it works indeed, but it is quite likely that you then just hit a sendmail site that has: http://www.sendmail.com/sm/open_source/docs/m4/tweaking_config.html 8-- confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if FTP.Foo.ORG is a CNAME for Cruft.Foo.ORG, then with this option set a lookup of FTP will return FTP.Foo.ORG; if clear it returns Cruft.FOO.ORG. N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. 8 Note that the default is FALSE, hence that unless tweaked this is not happening and you will see the effect as described. Note also the N.B. there, everybody has to do this. As that won't happen the feature is pretty useless as it cannot be relied upon. I'll also add the following from djb to this thread: http://cr.yp.to/im/cname.html Greets, Jeroen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Mon, Oct 21, 2013 at 12:17 AM, Paul Vixie p...@redbarn.org wrote: i apologize for my sloppy wording. i mean full deployment, in either case. your claims and your proposed workarounds will be evaluated through the lens of engineering economics. as vernon schryver has been (unsuccessfuly thus far) trying to explain, effort expended to defend against vulnerabilities will have to be prioritized alongside of, and in competition with, effort expended to deploy dnssec. Economics also include costs. The operational cost of deploying DNSSEC validation on resolvers remains high - there are still frequent key rotation and signing errors that cause various DNS subtrees to be unresolvable. Very few users are willing to accept that that is better for them, which makes it hard to tell the average resolver operator that turning on validation is a good idea. a correctly functioning recursive name server will not promote additional or authority data to answers. poison glue in a cache can cause poison referrals, or poisoned iterations, but not poisoned answers given to applications who called gethostbyname(). dnssec was crafted with this principle firmly in mind, and the lack of signatures over glue is quite deliberate -- not an oversight -- not a weakness. If an attacker can cause the domain to be unresolvable, that seems like a weakness. thanks for clarifying that. i cannot credit your work in the section of my article where i wrote about fragmentation, because you were not the discoverer. in 2008, during the 'summer of fear' inspired by dan kaminsky's bug, Kaminsky wasn't the discoverer of the Kaminsky's bug either, it was long known, yet here you credit him. Not that I mean to deny credit to Kaminsky, he did a good job of publicising the vulnerability. Just as Haya has done here. your answer is evasive and nonresponsive, and i beg you to please try again, remembering that the vulnerabilities you are reporting and the workarounds you're recommending will be judged according to engineering economics. if we assume that dnssec is practical on a wide enough scale that it could prevent the vulnerabilities you are reporting on, then your work is of mainly academic interest. as vernon said earlier today, none of the vulnerabilities you are reporting on have been seen in use. i also agree with vernon's assessment that none of them will ever be seen in use. Back before Kaminsky made the need for port-randominsation undeniable with an actual working PoC, this sounds like the ISC/Bind response to port randomisation attacks. Other implementors and operators made a better judgement avoided the problem entirely, taking the cautious path. 5 years later, are you really saying we should ignore another attack vector? The impact even with DNSSEC fully enabled seems concerning enough to warrant attention. -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can MX be working with CNAME?
Jo Rhett jrh...@netconsonance.com wrote: Tony, you seem to be confused about how dns and mail work. Fallback to host deliver when an MX doesn't exist was poor behavior in the original RFC, and has been fully deprecated behavior for more than 20 years now. You might like to review section 5 of RFC 2821 and RFC 5321, and if you have the time you could read the discussions of this feature in the ietf-smtp mailing list archives. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Oct 21, 2013, at 11:54, Keith Mitchell wrote: Then ISC/BIND response to Kaminsky in 2008 was to burn perhaps 50% of the company's product-wide development and support resources over that year to co-ordinating, fixing, disclosing, patching, releasing and evangelizing the solution to the problem. While at the time it felt to us like great public benefit work was being done for the community, even by the end of that year it was becoming clear it was not a particularly great business decision. Over the weekend there was a CENTR Technical Workshop (the day before RIPE 67 and in the same location) where a panel was held on the recent DNS vulnerabilities as reported at DNS-OARC 7 days earlier. One of the thoughts that emerged (IMHO) was to set priorities like this: design-away the theoretic/academic described vulnerabilities, reserving trench-warfare techniques to battle attacks we learn from packet captures. Given limited resources, that is how I'd spend them. So, yes, I believe this - in retrospect (referring to Keith's report) a lot of resources were burned to stem an attack that never really materialized. Possibly because of the fix, but we will never know. Oddly, during the CENTR meeting and during the RIPE DNS WG meeting that followed, the quote in the long run we are all dead [0] was uttered independently (different speakers) to mean that it's fine to design into the future, but we need to eat now. Under that banner, RRL serves an important purpose by staving off the apocalypse, even if (and I do mean if) it's benefit is temporary. This assumes that there is someone designing away vulnerabilities into the future, which I fear is a bad assumption currently. Most delivered techniques are triage with anything requiring major architectural rework considered to be too far off into the future to even being. I don't think DNSSEC would stand a chance starting from scratch today, given how avenues of innovation have changed. [0] http://en.wikipedia.org/wiki/In_the_long_run_we_are_all_dead#Macroeconomic_usages -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= c...@stdlib.net Economics also include costs. The operational cost of deploying DNSSEC validation on resolvers remains high - there are still frequent key rotation and signing errors that cause various DNS subtrees to be unresolvable. On what do you base your claims about the fatal costs of DNSSEC validation? I claim relevant knowledge and experience, not just from code I wrote a few years ago to reduce the costs of DNSSEC on very large resolvers, but from signing my own domains and enabling validation on all of the resolvers that I control. My domains and resolvers are insignificant, but I hope I would have noticed any fatal costs. Are you aware that Comcast's resolvers have been validating for some time? I think Google is also validating based on a Webmaster, your web page is not available to your spider messages after a configuration error in my signing machinery, but am not sure. Does that conflict with your claims about the fatal costs of validating? Yes, I've noticed that Google is still not signing. Maybe the continuing hijackings of their ccTLD domains will move them. If an attacker can cause the domain to be unresolvable, that seems like a weakness. True, but the right question is not Does DNSSEC add vulnerabilities? but Overall, is DNS more or less secure with DNSSEC? or Among all of the things I can do, what will improve the security of my users and the Internet in general? Defenders who care about the security of their systems and the Internet in general don't pick and choose among weaknesses based only on what is easiest, what can be punted to others, or what contributes to their reputations. They don't do as Steve Gibson did and harp on the bogus catastrophy of Windows XP raw sockets to enhance his reputation and sell his services. Kaminsky wasn't the discoverer of the Kaminsky's bug either, it was long known, yet here you credit him. Not that I mean to deny credit to Kaminsky, he did a good job of publicising the vulnerability. Just as Haya has done here. I suspect Kaminsky got the credit because he had been contributing to the field for years. But who cares who got there first? Every request I see for credit is recorded in my private accounting as a debit against the credibility of the person demanding credit, because credit demands suggest interests which suggest biases and so inaccuracy. Yes, I've heard of Kaminsky's business interests, and so I don't take his announcements at face value. You should also discount my credibility based on my pecunary or other interests. Where you can't determine my interests, act on your best guess. Back before Kaminsky made the need for port-randominsation undeniable with an actual working PoC, this sounds like the ISC/Bind response to port randomisation attacks. Other implementors and operators made a better judgement avoided the problem entirely, taking the cautious path. 5 years later, are you really saying we should ignore another attack vector? Who besides you and Haya Shulman has said anything about not randomizing ports? What port randomization improvements do you think are needed in current releases of any major DNS implementation? Where port randomization problems exist such as in junk CPE that won't get fixed before I retire, what contributes most to solutions, selling $29.95/#24.95/£19.95 academic papers or turning on DNSSEC? The issue for me is one of relative priorities. Among all Internet security issues that I might touch, which should get my attention and effort? By remaining silent about emphasising port randomization over DNSSEC (or using distant instead of nearby validating resolvers) would I help or harm? The impact even with DNSSEC fully enabled seems concerning enough to warrant attention. Let's agree that ports ought to be as random as TCP ISNs, improve port randomness where each of us can, and stop implying that anyone thinks or says otherwise. Let's also stop the DNSSEC is a problem stuff. Finally let's consider how you are helping. Is there anything you can do to improve port randomization? If you are committer in any open or proprietary source trees, will you make any needed port randomization fixes? Have you deployed DNSSEC? What about BCP 38, since cache poisoning is likely to depend on BCP 38 violations? Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Mon, Oct 21, 2013 at 11:32 AM, Vernon Schryver v...@rhyolite.com wrote: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= c...@stdlib.net Economics also include costs. The operational cost of deploying DNSSEC validation on resolvers remains high - there are still frequent key rotation and signing errors that cause various DNS subtrees to be unresolvable. On what do you base your claims about the fatal costs of DNSSEC validation? I wrote that the costs are high, not fatal. http://dns.comcast.net/ serves as a reasonable, though not complete, public example list of issues. http://dns.comcast.net/ serves as a reasonable, though not complete, example list of real issues. If an attacker can cause the domain to be unresolvable, that seems like a weakness. True, but the right question is not Does DNSSEC add vulnerabilities? but Overall, is DNS more or less secure with DNSSEC? or Among all of the things I can do, what will improve the security of my users and the Internet in general? This thread concerns the vulnerabilities uncovered in the fragment attacks. One of those vulnerabilities is that domains can be rendered unresolvable; even when DNSSEC is enabled. That seems like something to take seriously. Kaminsky wasn't the discoverer of the Kaminsky's bug either, it was long known, yet here you credit him. Not that I mean to deny credit to Kaminsky, he did a good job of publicising the vulnerability. Just as Haya has done here. I suspect Kaminsky got the credit because he had been contributing to the field for years. But who cares who got there first? Evidently Paul Vixie does. That's what I was responding to. Let's agree that ports ought to be as random as TCP ISNs, improve port randomness where each of us can, and stop implying that anyone thinks or says otherwise. O.k., but what about fragmentation point randomisation, or randomized DNS payload padding? -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On 21 Oct 2013, at 19:32, Vernon Schryver v...@rhyolite.com wrote: Yes, I've noticed that Google is still not signing. Maybe the continuing hijackings of their ccTLD domains will move them. I suspect they're more interested in getting registry lock in place rather than DNSSEC. Most of the attacks against Google have involved changing the name servers completely .. Mr Michele Neylon Blacknight Solutions ♞ Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Oct 21, 2013, at 4:39 PM, Phil Regnauld regna...@nsrc.org wrote: Michele Neylon - Blacknight (michele) writes: Yes, I've noticed that Google is still not signing. Maybe the continuing hijackings of their ccTLD domains will move them. I suspect they're more interested in getting registry lock in place rather than DNSSEC. That'd be assuming most registries have the concept of lock, which is far from being the case. Some do, some don't… In some cases the registry lock is actually just a comment in a zone file, saying something along the lines of: ; WARNING - ; Don't change this! ; Call Warren at +1-xxx-xxx- before making any changes. ; WARNING --- In a number of cases registries don't officially support locks, but have been willing to do something unusual for a beer / friend. Most of the attacks against Google have involved changing the name servers completely .. Through social engineering and sometimes through directed attacks, yes. Sadly yes. W Cheers, Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs --- Tsort's Constant: 1.67563, or precisely 1,237.98712567 times the difference between the distance to the sun and the weight of a small orange. -- Terry Pratchett, The Light Fantastic (slightly modified) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
From: Warren Kumari war...@kumari.net I suspect they're more interested in getting registry lock in place rather than DNSSEC. Most of the attacks against Google have involved changing the name servers completely .. Through social engineering and sometimes through directed attacks, yes. Sadly yes. I trust we all agree that cache attacks with non-random ports, fragmentation, or padding are irrelevant except perhaps indirectly through the general (lack of) value of DNSSEC that I claim better prevents cache attacks than random ports. Wouldn't DNSSEC have not made things worse and possibly made them better by: - making the social engineering more difficult by forcing the bad guys to change key as well as NS RRs - possibly making the bogus records fail to validate for a while at the start of the attack, thanks what might look like an unplanned KSK change. - possibly making the bogus records fail to validate sooner and so get ignored sooner after the registrar records are restored, again thanks to what might look like an unplanned KSK change. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
