Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I seem to remember that some time back (two years or so?) RIPE-NCC also published data points and they were in about the same range. Some searching reveals: Ref:ripe-352 Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman RIPE NCC / NLnet Labs Date: October 2005 Format: PDF=5367108 The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf. Already three years ago, time flies jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Jaap Akkerhuis wrote: On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I seem to remember that some time back (two years or so?) RIPE-NCC also published data points and they were in about the same range. Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf. Already three years ago, time flies We also did another one for ripe a little bit later, but still more than two years ago: http://nlnetlabs.nl/downloads/publications/dnssec/dnssec-effects.pdf Jelte signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, 19 Aug 2008 15:43:14 -0400, Andrew Sullivan [EMAIL PROTECTED] said: On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I think Peter's data point sure warrants further investigation, yes. More data points from two authoritative servers for the ch ccTLD: 40-50% (I've attached the relevant DSC graphs for the past month). I looked more closely on one of the servers. Out of about 22 million queries in the past 11 hours, about 10 million from 161000 different sources had the DO flag set. -- Alex inline: domreg-do.pnginline: merapi-do.png___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Mark Andrews wrote: DO says that you *understand* DNSSEC and that it is ok to send a DNSSEC response. It does not mean that you will be validating the response. named in all production versions of BIND 9 (9.1.0 onwards) has set DO on all EDNS queries. BIND 9.1.1 onwards named copies DO to the response. Caching servers not validating the response? Then, the following argument applies. If a caching server is not required to perform public key computation to verify RRs before caching, cache poisoning won't be detected by the caching server, average clients of which suffer from long lasting DOS of DNSSEC verification failure, turn off DNSSEC and will be a victim of another poisoning on their own cache. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Aug 20, 2008, at 6:16 AM, Masataka Ohta wrote: Unlike me, you have no implementation expertise. Um. Right. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
David Conrad wrote: So far, I have seen what appears to be a lot of FUD from Masataka and the usual concerns/complaints about DNSSEC from folks who haven't implemented it in their products or services. Unlike me, you have no implementation expertise. I did implement server code for my proposal of Simple Secure DNS more than 10 years ago to confirm that, unlike DNSSEC, it can be implemented easily. From the beginning, I knew it is essentially (except to support read/write new RR types from/to zone file) less than 100 lines of modification to BIND and it actually was so. As a lazy implementor, I can design protocols to avoid useless implementation efforts. As a faithful protocol designer, I implement my design to confirm it actually require little implementation efforts. At that time, because of fundamental complexity, there was no DNSSEC implementation. Thus, I am the implementer who can authoritatively declare that all the impelementors and system administrators of DNSSEC do not understand both of DNS and PKI and are brain dead. I, of course, won't bother to implement proven-to-be-fundamentally- broken DNSSEC nor join proven-to-be-useless attempts to improve the proven-to-be-fundamentally-broken protocol. Anyway, the other problem of DNSSEC is that PKI, as a concept, is fundamentally broken, against which no PKI protocol can be useful. Masataka Ohta The current DNSSEC essentially matches Simple Secure DNS. NSEC + RRSIG(NSEC) = ZL RSIG(type) = RRD + NSIG DNSKEY = ZA RRSIG(DS) = ZSIG DS = RDD(ZA) The trust model is the same as Simple Secure DNS. The threat model is the same as Simple Secure DNS. ZL has the same issues as NSEC has. KSK/ZSK maps directly into this from Simple Secure DNS. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. DNSKEY uses public keys which you recommended. The signature can be verified by sharing secret information between related parties or by using private/public key technology. RRSIG = TYPE + 32768 would have been better than how we actually did it in RFC 4035. While things are encoded slightly differently RFC 4035 is a implementation of Simple Secure DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
In your previous mail you wrote: So please consider other options before repeating the holy mantra 'DNSSEC is the only solution'. = it is not a mantra but the reality: - transaction protection is not enough if we want to keep caching in the middle (the argument is it has to be a perfect protection to be efficient, a single hole somewhere can corrupt an unbound amount of clients) - data protection is the solution - the right granularity is the RRset because coarser (name for instance) is inefficient and finer (RR) is prone to specific DoS attacks - the needed protection is origin and integrity, this calls for a signature system So the complete solution for the cache poisoning issue is to sign RRsets. You can specify something new from zero but it shall look very similar to DNSSEC... Regards [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 08:55:31AM -0400, Andrew Sullivan wrote: Now, maybe that doesn't matter for many of these cases. It is entirely possible that DNSSEC deployment for most zones is just not worth it. If that's true, however, why are we so worried about poison attacks? Because quite a number of people care deeply about the success of DNSSEC, and this is a window of opportunity where DNSSEC finally addresses something operators worry about. The cost is not an issue that is dwelled upon now. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, 19 Aug 2008, Andrew Sullivan wrote: Sure, large organizations with large, mostly competent, and very conservative IT departments (think banks) will probably not have this problem and will probably deploy successfully. None of that will matter, however, if everyone else starts adopting policies like disable DNSSEC -- too risky. DNSSEC is purely optional though. Anyone can decide to 1) not publish DNSSEC auth data and 2) not use DNSSEC based resolvers. What happens after that, is not up to engineers. It will be up to lawyers to proof someone not deploying DNSSEC made the best decision in the interest of their customers. As for TLD's, I wonder what will happen if .eu decides to go DNSSEC, but .com won't. It will be interesting to watch and see if organisations start migrating away from .com then, at which point DNSSEC would have to be deployed to ensure not losing customers. Now, maybe that doesn't matter for many of these cases. It is entirely possible that DNSSEC deployment for most zones is just not worth it. If that's true, however, why are we so worried about poison attacks? Because this is only true for the authorative part of DNSSEC. Since Dan showed you can cache poison any non-DNSSEC resolver for ANY domain, not just the domains you are not protecting, you basically have no choice but to mitigate this problem. And DNSSEC, for good or bad, is what we have right now. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 12:07:04PM -0400, Paul Wouters wrote: Because this is only true for the authorative part of DNSSEC. Since Dan showed you can cache poison any non-DNSSEC resolver for ANY domain, not just the domains you are not protecting, you basically have no choice but to mitigate this problem. And DNSSEC, for good or bad, is what we have right now. Is there some sort of shield preventing people from reading or even arguing with http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html ? All those things can be done today, unilaterally, and they start working from the moment you enable them. In fact, I'm so far not having luck getting around even my 3-year old primitive anti-spoofing behaviour. I've reduced the number of ports I use to 10 to make things more doable, but no luck. So please consider other options before repeating the holy mantra 'DNSSEC is the only solution'. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Aug 19, 2008, at 10:00 AM, bert hubert wrote: In fact, I'm so far not having luck getting around even my 3-year old primitive anti-spoofing behaviour. Have you tried dsniff anywhere on the path the DNS packets take? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 01:13:44PM -0400, Paul Wouters wrote: On Tue, 19 Aug 2008, bert hubert wrote: In fact, I'm so far not having luck getting around even my 3-year old primitive anti-spoofing behaviour. Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to spoof based on bogus query types, since PowerDNS dropped those packets and You misunderstood Dan's talk in that case. See http://doc.powerdns.com/powerdns-advisory-2008-02.html for details. one of Dan's attacks. So don't come with this my 3 year old code was not vulnerable thing just because you didn't have the same bug as bind. You had a different bug, which would have not been an issue if three years ago instead you had DNSSEC. Perhaps I should explain myself better. The software I refer to has detected spoofing attempts in the past 3 years already, and acted on that. The software I refer to has further behaviour that, unintentionally, makes spoofing it very hard. Again - this is about TODAY. DNSSEC might be the end all solution but even if it is, it is not deployed widely today and it won't be 12 months from now. Countermeasures serve a function. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I think Peter's data point sure warrants further investigation, yes. I suspect the question as to what will break if the root is signed will be asked in venues that matter in the near future. It would be nice to have an answer, or at least an idea of what to look for, before hand. I completely agree with this. The reason I didn't answer the actual question you asked is, of course, I don't know. We haven't collected the data so far. The best we can say is, It shouldn't, assuming correct protocol implementations out there. We know, however, that the correct protocol implementations are not the only implementations, and therefore that we will have surprise breakages during deployment. I suspect this is a risk we will have to live with in the case of any deployment of significant new DNS features, unfortunately. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Aug 19, 2008, at 12:23 PM, bert hubert wrote: Again - this is about TODAY. DNSSEC might be the end all solution but even if it is, it is not deployed widely today and it won't be 12 months from now. Nobody's disputing that point. Is this why we are arguing? The reason I'm pushing DNSSEC is with a view to the future, not with the idea that we're going to solve the spoofing problem on a practical level right now. I just want us to start down the road, because if we don't start we will never get to the point where DNSSEC is a solution for anyone. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Fri, Aug 15, 2008 at 04:07:03PM -0700, David Conrad wrote: intervention) or they'll turn off DNSSEC. So, in the worst case, they'll get bitten and revert back to the same level of security (or lack thereof) they have today. Is this worth blocking DNSSEC deployment? It seems to me that that story is the one by which DNSSEC becomes permanently hobbled on the Interned, as various overworked or semi-incompetent system administrators make a mistake of this sort and cause sites to go dark for significant portions of the Internet. When the CTO receives the incident report, the CTO is going to say, So if we never turned on DNSSEC, this wouldn't have happened? Ok. New policy: no DNSSEC. At least, that's the way it would have worked in most large institutions I ever worked in/around. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Mon, 18 Aug 2008, Paul Wouters wrote: I wouldn't be using starbucks resolver, since i just installed my own DNSSEC-aware resolver? Ordinarilly , when you get a DHCP-supplied nameserver from starbucks, your stub resolver directs its requests to that caching server. It is indeed possible that your stub resolver could make its own queries, including to the root and TLD servers, but putting this non-cached end-user load on those servers is yet another unanticpated operational problem. No one has accounted for such increased load for DNSSEC. When the internal representation is updated, it is often done one RR at a time. So two responses updating the same two records could be interleaved. This is a simple database problem called a race condition. However, we have TTL's and signature life times, so older entries will only get updated with newer entries, so this race is not a problem. I don't think you understand the programming issues. This has nothing to do with TTLs or signature lifetimes. The point is that DNS servers don't currently perform transactions internally; normally, records don't depend tightly on other records (hence the term 'loosely coherent'). BTW, adding transaction capability greatly slows down database servers. This is probably one of the reasons people like to put stuff in DNS instead of databases. DNS is fast because of its stateless nature. DNSSEC changes that, and imposes speed-reducing demands on server architecture. Or else, won't work right. This change alters DNS from being loosely coherent to tightly coherent, with corresponding performance impacts to get correct operation. You lost me here. Sorry. When the RR isn't the same as the one for which the RRSIG was computed, the DNSSEC-aware stub resolver will reject the record. If it asks the caching server again, it gets the same records. So the resolver will fail, and will continue to fail until the TTL expires. The bad guy just creates two records with long TTL, and you have the DOS attack. Mark and Roy already explained why this is not the case. Who do you mean by 'Mark and Roy'? Mark Andrews and Roy Arends? When? If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. When your server can't handle the load of all these calculations on millions of queries sent by the attacker, its a DOS attack. So is not getting any traffic because you lost .com due to cache poisoning. True enough. Same problem continues after all the DNSSEC effort, and now we have created the additional problems of the other DDOS attacks using the signed records. Seems to be a giant step backward, with no step forward. In fact, what I understood is that resolvers mostly have problems switching to DNSSEC not due to DNSSEC but due to DNSSEC requiring EDNS0. And mind you, the EDNS0 was released in what? 1999? It's not the crypto that's the resolvers issue. That's easilly solved by adding a cpu or a box. The transition issue you speak of is a different problem. The DOS attack I speak of is when your caching server gets lots of requests for DNSSEC records, which it then must verify. These requests aren't 'legitimate' in the sense that users made these queries genuinely trying to get information. These requests are bogus, generated only with the purpose of creating load on the server. Verifying the crypto keys is not easy. Verifying millions is impossible. Now imagine the target spoofed IP's are the nameservers of, say yourdomain.com. When the roots (or TLDs, etc) get millions of forged UDP packets, the roots can't block the incoming packets---that would severely harm the target IP addresses. On the other end, the target IP addresses can't block the root servers---that would also seriously harm the target IP addresses. The target just has to 'take it'. The greater the amplification factor (Response size / request size-- perhaps only 64 bytes), the more damaging this attack is. Since there are (or may be--probably will be) a number of additional (and large) DNSSEC records in a response, the response could get quite large, causing significant damage. So yes, that is a reason not to deploy DNSSEC. This has also been explained earlier. Just get a botnet that's 100x the size to accomplish the same. This argument amounts to something like let's not do HDTV because the home user DSL might not be able to download it in real time anyway. No, actually, it isn't like that at all. If there is no amplification, the botnet will simply use ICMP or something it already has a program to do. When there is amplification (perhaps up to 100x in this case) a very small botnet can do a very great deal of damage, for a much longer time. A great deal of effort
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
2008/8/15 David Conrad [EMAIL PROTECTED]: Hi, On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote: But until we have root and .com signed, and until the average end-user is protected by a validating resolver, we aren't done yet, and I don't really get any actual benefit from my efforts. Which, tragically, is why it's taking so long. There are people who appear to think deploying DNSSEC as soon as possible would be a good thing. There are also people who appear to think deploying DNSSEC is a fools errand, that it won't get significant use because it makes things too hard, too complicated, too prone to failure, etc. However, because of DO, folks who don't configure their resolvers to do DNSSEC shouldn't ever see any DNSSEC goop. Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? If you build it, he will come. No, I don't see any problem. Since enabling DNSSEC validation is controlled process - ie. you need to change configuration - people will know what they are doing. Sure some people will get burnt once, twice, but then they will learn or just disable DNSSEC validation at all. But what we need to do is to properly educate users wishing to enable DNSSEC validation. But that doesn't differ from TLD signing and it's more task for TLD registry to speak to it's users. Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer - CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:[EMAIL PROTECTED] http://nic.cz/ sip:[EMAIL PROTECTED] tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Jaap Akkerhuis wrote: Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? Well,it will introduce a lot of large RRs, which may cause problems. No, it won't. As David already pointed out, people not interested won't set the DO bit so won't ask for DNSSEC. I'm talking about people who have, foolishly enough, interested in DNSSEC and asked for DNSSEC information sometimes in vain. And, the result is the instability. Also, a well behavng resolver has way less request to the root servers then to other servers. Why, do you think, that servers other than the root servers won't reply with oversized messages? Masataka Ohta PS Thank you and David for being a example of people blindly requesting for DNSSEC without understanding its so obvious negative effects, in addition to not so obvious lack of its positive effects. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Also, a well behavng resolver has way less request to the root servers then to other servers. Why, do you think, that servers other than the root servers won't reply with oversized messages? Don't twist my words. I never said that. jaa ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sat, 16 Aug 2008, Ted Lemon wrote: On Aug 16, 2008, at 9:35 PM, Dean Anderson wrote: - If Mal cracks someone else's server, that server still doesn't have the bank's certificate, and won't have the bank's dns domain, either. So the browser should think that it got the wrong certificate. No, that wasn't my point. My point is that sometimes browsers will warn you if you submit a form to a non-SSL server. So an attacker can get rid of that warning by suborning an SSL server and directing your response toward it. You won't get a warning that your data is being submitted over an insecure link, because it's not. The link is perfectly secure - the problem is that it's the wrong link, and someone's listening on the other end who shouldn't be. Anytime the browser takes a certificate that is not user-checkable as being both secure and trusted, there will be problems. So any attack that can make things not look funny is a valuable attack. And the Kaminsky attack is such an attack. You're right that it's not the only one, but eliminating it still has appreciable value. One can live with things that are untrustworthy, so long as you know they are untrustworthy and takes the appropriate steps to avoid placing trust decision on untrustworthy information. SSL/TLS certificate procedures the appropriate steps to obtain secure and trusted communication. Changing DNS doesn't eliminate the attack of misplaced trust. It merely eliminates one method we know of for accomplishing the attack, at great expense and great risk, I might add. Addressing the misplaced trust attack in the wrong place incorrectly signals to users/browsers that they don't need to check the certificates for trustworthiness. DNS spoofing isn't the only way to accomplish a misplaced trust attack. Cross site scripting and javascript viruses are another way. Cryptographic verification just proves the CA issued the certificate. Checking that the verified identity is one we trust is what ensures trustworthiness. The combination of both checks the only thing that ensures trustworthiness. One can't eliminate either check and remain trustworthy. Every certificate that a browser uses for trustworthiness has to be both verified cryptographically and checked by the user for trust. Multi-site secure operations have to either have multiple certificate checks, or depend on a private CA whose certificates are always trusted. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Jaap Akkerhuis wrote: Also, a well behavng resolver has way less request to the root servers then to other servers. Why, do you think, that servers other than the root servers won't reply with oversized messages? Don't twist my words. I never said that. That you didn't say that, I think is the point. Other, non-root, servers may respond with oversized messages. I agree with what Masataka is saying. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Masataka, No, it won't. As David already pointed out, people not interested won't set the DO bit so won't ask for DNSSEC. I'm talking about people who have, foolishly enough, interested in DNSSEC and asked for DNSSEC information sometimes in vain. If they have configured DNSSEC, then they either are aware of the operational issues that concern folks or will quickly learn of the issues. If they are aware of the issues, then presumably they can help debug the infrastructure that is failing to provide them the information they are asking for. If they are unaware of the issues, they can either learn and/or turn DNSSEC validation off at the first sign of problems. And, the result is the instability. The result, if they are unhappy with the behavior DNSSEC causes, will be to turn off DNSSEC until the issues that made them unhappy are resolved (e.g., new caching server software that makes using DNSSEC less onerous). According to your logic, no one should turn on IPv6 since it will obviously cause instability. An interesting point of view. Thank you and David for being a example of people blindly requesting for DNSSEC without understanding its so obvious negative effects, in addition to not so obvious lack of its positive effects. Yawn. Thank you for living up (or perhaps more accurately, down) to my expectations. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Mark Andrews wrote: Considering that two RRs each containing 2048 bit data will need oversized messages, they may not be properly treated by some servers. Those suffering from oversized messages may turn-off DNSSEC and there is instability for those moving with their laptops. And how is this different from the answers from TLDs which have already turned on DNSSEC? Though I never said answers from root servers is oversized, if some server under such TLD generates oversized messages, there should be instability observed. Masataka Ohta Define oversized? A referral to the COM servers already exceeds 512 octets. Lots of EDNS answers already result in fragmented responses. Lots of EDNS answers already exceed 2K. There are a few EDNS answers which even set TC. I fail to see how turning on DNSSEC at the root will change anything significant with respect to responses sizes which is not already highly visible elsewhere in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Ted Lemon wrote: On Aug 17, 2008, at 9:24 AM, Dean Anderson wrote: Changing DNS doesn't eliminate the attack of misplaced trust. It merely eliminates one method we know of for accomplishing the attack, at great expense and great risk, I might add. You may not add that unless you are willing to justify the assertion, which thus far you have not done. Changing DNS protocol is considered by many to be expensive and risky. Are you saying its not expensive or risky? That seems to be a far more bold assertion. And if you argue that we shouldn't close the DNS hole, your argument applies equally to these problems. Are you arguing that we shouldn't address them either? It may well impossible to close the problems of cross site scripting and javascript viruses. However, misplaced trust attacks can only be avoided by preventing the sending of trusted information to untrusted sites. Solve this problem correctly (which is entirely doable) and none of these attacks will be effective at obtaining trusted information. Changing DNS protocol is not necessary to prevent misplaced trust attacks. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Aug 17, 2008, at 4:12 PM, Dean Anderson wrote: Changing DNS protocol is considered by many to be expensive and risky. Are you saying its not expensive or risky? That seems to be a far more bold assertion. Actually, you and Ohta-san seem to be taking that position. That's not many. I just deployed DNSSEC. My servers are ticking over happily, and I haven't had any complaints from users. So I guess I don't think it's all that risky, no. It may be that I'm wrong, but you haven't said anything surprising yet, so I'm still waiting for the revelation that will convince me that your fears are justified. However, misplaced trust attacks can only be avoided by preventing the sending of trusted information to untrusted sites. Solve this problem correctly (which is entirely doable) and none of these attacks will be effective at obtaining trusted information. Forgive me for pointing this out, but about three exchanges ago you said that solving this problem was provably impossible. Have you changed your mind, or am I missing something? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Dean Anderson wrote: There are two more problems with this. First, Putting any kind of large record in the root creates the opportunity to use root servers in a DOS attack by sending queries for the large records to the root servers. Because of Root Anycasting, there are over 100+ root servers spread around the world that will respond to queries. A botnet distributed worldwide should be able to send queries to most or all of these servers. Most or many of these servers have very high bandwidth connections. Same would be true for TLD servers, and large, high traffic domains like microsoft.com, etc. It is very hard, if not impossible, to mitigate attacks coming from root, TLD or other significant sites. If it is TCP, due to large DNSSEC answers, you won't easilly be able to use these for amplifying your DOS attack. If the answer would fit in UDP, you wouldnt really have an issue. Second, as I start to look closer at DNSSEC It keeps amusing me how people who have critisied DNSSEC for years, end up asking me things like so how does it work? or in your case I actually looked at it now. , there appears to be a problem in the DNSSEC protocol in that if caching servers don't care about DNSSEC, then caches could store RRSIG records that are out of sync with the RR they sign. When the security-aware resolver obtains both records from the caching server, the resolver that finally checks one record against the other will find that the signature doesn't match. This is not the case, but if so, why would you bootstrap a DNSSEC enabled server using a non-DNSSEC forwarder? This scenario could happen by accident during zone updates between master and slaves after the RR was changed, if the cache gets one RR from the master and receives the RRSIG from another server (one might Don't you get the RRSIG as Authoritive or Additional data when getting the new RR? try to avoid this by adding RRSIG records as additional, but there is still a race on the internal representation if multiple responses are received from different servers). Or it could happen on purpose using a cache poisoning attack. Once the incorrect records are cached, a DOS occurs. (its only an attack if its on purpose) You lost me here. If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. The first problem is reason enough not to deploy DNSSEC. The second problem is serious, too, but I think only affects DNSSEC users who have shot themselves, other DNSSEC users, and those using DNSSEC-aware caching servers in the foot, so to speak. Back to the drawing board? Because root servers could potentialy amplify a single spoofed packet into more (which I described is not as bad as you make it appear), that would be a reason not to deploy secure DNS? This is an answer looking for a reasoning. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sat, 16 Aug 2008, Ted Lemon wrote: The hype surrounding the Kaminsky report is unjustified. For example, one can't steal bank information with this attack, as the mainstream press has reported. This isn't true, because if I can convince you that a naive user that he or she is talking to your bank, I can get them to enter their information into a web page that isn't protected by SSL. Alternatively, I can find a server that has a valid SSL cert, crack it, set Even easier, just grab the ones that were created on Debian. Funny how DNSSEC-phobic people keep referring to SSL as the solution. Reread Dan's slides to see how to combine the DNS and the Debian SSL issue into a mega attack. However, if part of the deployment involves putting DNSSEC-validating resolvers in the DNS caching servers, then there will be an opportunity for DoS attacks, and so deployments of that type will have to be done very carefully. At least you won't be receiving endless streams of DNS packets trying to race your DNS resolver using NXDOMAIN records using Dan's attack. I'd rather have some extra CPU load to mitigate the bandwidth losses. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Fri, Aug 15, 2008 at 4:51 PM, Paul Hoffman [EMAIL PROTECTED] wrote: security layers are good. If we don't give those people the right tools to properly configure and properly maintain those configurations, there will be stability issues, as I listed earlier. Let me tell you something. All this DNSSEC fud has been very very good for DNS consultants. One thing I make clear to the client base is that DNSSEC is just more bad patching on top of more bad patching. The BIND boys are patching freaks and have yet to build a BIND version that is stable. My advise to them is to watch the developments in DNSSEC and not believe everything they read. The solution I like implementing instead of DNSSEC is an IPS monitoring the resolver. And of course making sure their resolvers don't act as authoritative primaries or secondaries. One things for sure - many businesses are going to end up paying big bucks to protect themselves and even bigger bucks to deploy the DNSSEC patch. The BIND boys are marketing gurus. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Ted Lemon wrote: On Aug 17, 2008, at 4:12 PM, Dean Anderson wrote: Changing DNS protocol is considered by many to be expensive and risky. Are you saying its not expensive or risky? That seems to be a far more bold assertion. Actually, you and Ohta-san seem to be taking that position. That's not many. I just deployed DNSSEC. My servers are ticking over happily, and I haven't had any complaints from users. So I guess I don't think it's all that risky, no. It may be that I'm wrong, but you haven't said anything surprising yet, so I'm still waiting for the revelation that will convince me that your fears are justified. I'm always amazed when advocates of something come out and say I did it, and I'm still here, and assume that means that it can be done worldwide for free and that it also means there are no issues with scaling their effort, and that it means there are no downsides that might come to light after a lot of sites do what they did. SPF script DOS attacks come to mind as a good example. But if only myself and Ohta-san think changing DNS protocol is expensive and risky, then perhaps we should change the protocol even more and do it more often. However, misplaced trust attacks can only be avoided by preventing the sending of trusted information to untrusted sites. Solve this problem correctly (which is entirely doable) and none of these attacks will be effective at obtaining trusted information. Forgive me for pointing this out, but about three exchanges ago you said that solving this problem was provably impossible. Have you changed your mind, or am I missing something? You are indeed missing something. Constructing a system free of covert channels is not the same as limiting the distribution of trusted information. To put it another way, its fairly easy to limit the To: list on sending email, but its much harder to keep spam out of your mailbox. One problem is doable. The other isn't. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Paul Wouters wrote: On Sun, 17 Aug 2008, Dean Anderson wrote: There are two more problems with this. First, Putting any kind of large record in the root creates the opportunity to use root servers in a DOS attack by sending queries for the large records to the root servers. Because of Root Anycasting, there are over 100+ root servers spread around the world that will respond to queries. A botnet distributed worldwide should be able to send queries to most or all of these servers. Most or many of these servers have very high bandwidth connections. Same would be true for TLD servers, and large, high traffic domains like microsoft.com, etc. It is very hard, if not impossible, to mitigate attacks coming from root, TLD or other significant sites. If it is TCP, due to large DNSSEC answers, you won't easilly be able to use these for amplifying your DOS attack. If the answer would fit in UDP, you wouldnt really have an issue. I'm not sure you understand EDNSO. EDNSO UDP can be 8KB in size. TCP isn't susceptible to this kind of attack at all. TCP spoofing is just about impossible if you aren't in the path, because there is a 32bit random sequence ID. If you don't get that sequence id, you won't get the connection established, and the target won't get the DNS response. A botnet spread worldwide mostly won't be in the path. Second, as I start to look closer at DNSSEC It keeps amusing me how people who have critisied DNSSEC for years, end up asking me things like so how does it work? or in your case I actually looked at it now. This seems strange only if you don't know the history of DNSSEC. Because they keep messing up in major ways, and keep starting over on the protocol, what I looked at years ago has no bearing on DNSSEC now. And I thought it was a dumb idea years ago, too. , there appears to be a problem in the DNSSEC protocol in that if caching servers don't care about DNSSEC, then caches could store RRSIG records that are out of sync with the RR they sign. When the security-aware resolver obtains both records from the caching server, the resolver that finally checks one record against the other will find that the signature doesn't match. This is not the case, but if so, why would you bootstrap a DNSSEC enabled server using a non-DNSSEC forwarder? You haven't been following along with the discussion. There may be DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might use DNSSEC-oblivious intermediate caches. For example, suppose example.com signs its zone, and you install a DNSSEC-aware resolver on your laptop. Now suppose you go to starbucks, which didn't do DNSSEC and has a DNSSEC-oblivious caching server. Next you try to access example.com using the starbucks caching server. The DNSSEC-oblivious cache will just cache the records as ordinary (very large) records. This scenario could happen by accident during zone updates between master and slaves after the RR was changed, if the cache gets one RR from the master and receives the RRSIG from another server (one might Don't you get the RRSIG as Authoritive or Additional data when getting the new RR? I'm not entirely sure it works that way. I didn't see that specified. But it certainly could work that way, as I said below. try to avoid this by adding RRSIG records as additional, but there is still a race on the internal representation if multiple responses are received from different servers). When the internal representation is updated, it is often done one RR at a time. So two responses updating the same two records could be interleaved. This is a simple database problem called a race condition. Transaction isolation and locking is used to protect against this. DNS servers usually aren't designed to support transactions on the update of multiple records in one response. Or it could happen on purpose using a cache poisoning attack. Once the incorrect records are cached, a DOS occurs. (its only an attack if its on purpose) You lost me here. Sorry. When the RR isn't the same as the one for which the RRSIG was computed, the DNSSEC-aware stub resolver will reject the record. If it asks the caching server again, it gets the same records. So the resolver will fail, and will continue to fail until the TTL expires. The bad guy just creates two records with long TTL, and you have the DOS attack. If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. When your server can't handle the load of all these calculations on millions of queries sent by the attacker, its a DOS attack. The first problem is reason enough not to deploy DNSSEC. The second problem is serious, too, but I think only affects DNSSEC
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On 15 aug 2008, at 22.01, David Conrad wrote: Let me try to (hopefully) more clearly articulate my question: given the fact that caching servers only care about DNSSEC if they're explicitly configured to do so, does anyone anticipate any stability/ security concerns to those folks who _haven't_ configured DNSSEC if the root is signed? Good question David, thanks for asking it. My view is that the answer is NO. Yes, just because the root is signed, we will see an uptake in the number of resolvers choosing to verify DNSSEC signed responses. Yes, people will shoot themselves in the foot by forgetting the trust anchors, but as you have pointed out, they will discover this pretty quickly and then either go back to where they are today (turn off DNSSEC verification), or update the trust anchor. I am though of the view that we many times in the Internet Architecture have created tools that give the ability to people to shoot themselves in their foot. Sometimes both at the same time! But, as DNSSEC is an opt-in technology, people really have to first do a active opt-in action before they find their feet hurt. People can with a signed root choose themselves whether they want to participate or not. I am today much more worried about doing too much signing of leaf nodes of the DNS tree before we can start do the signing of nodes from root and down the tree. Regardless of how well TAR's will work, I claim the ability to damage ones feet increase with the number of signed zones before the root is signed. But don't ask me at what number of TLDs (say) we pass the line of too many. Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
David Conrad wrote: Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? Well,it will introduce a lot of large RRs, which may cause problems. Considering that two RRs each containing 2048 bit data will need oversized messages, they may not be properly treated by some servers. Those suffering from oversized messages may turn-off DNSSEC and there is instability for those moving with their laptops. And how is this different from the answers from TLDs which have already turned on DNSSEC? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sat, 16 Aug 2008, Ted Lemon wrote: On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote: For example, besides the previously mentioned key rollover issue, I understand that DNSSEC also doesn't allow the protocol to be changed securely. And we do expect the protocol to be changed. As a non-expert in DNSSEC, I have to admit that I am not aware of an expectation that the protocol will change. Can you expand on this? I'm also a non-expert on DNSSEC. I take this excerpt from Olaf Kolkman's message of December 1, 2007: as indicating that it will need to change: Begin quote == Please speak up if this change is of concern to you. If no one speaks up by Dec 7'th I will tell our AD the changes are fine. So the change is that the basic-4 steps procedure was removed and replaced with text that amounts to We'll solve this when we get to this. For those who are not up to speed with the issue that is being addressed, the thread causing all this starts here: http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html To me it is clear that the current text postpones dealing with the problem that starts with the premisses in Sam Weiler's observation: but we aren't (as far as I can tell) requiring that an NSEC3- SHA256-capable resolver also support NSEC3-SHA1 If the requirement to support old algorithms would exist, then the rollover is one that we currently understand. End quote === Also, is there a way to build the protocol so that it can be changed securely? Hopefully, there is. Though mainly, I think the problem is the hash change problem. I would think that the way this would happen would be that the resolver would ask different, or additional, questions. Does the current protocol preclude that? I suppose not. But changing resolvers repeatedly is a big problem, because you have to support the old resolvers. The zones are quite large with the current records. The hype surrounding the Kaminsky report is unjustified. For example, one can't steal bank information with this attack, as the mainstream press has reported. This isn't true, because if I can convince you that a naive user that he or she is talking to your bank, I can get them to enter their information into a web page that isn't protected by SSL. Alternatively, I can find a server that has a valid SSL cert, crack it, set up a redirect that sends the user's password through that server. They wind up doing an SSL-validated transaction that appears to be completely fine, but is not. Since I've suborned an existing server, even once the hack is discovered, if it is, it can't be traced back to me through the SSL cert trust chain. The above attacks aren't dependent on DNS attacks. - If the user is naive and doesn't check that connection is secure and that the certificate belongs to their bank, then they are subject to any number of schemes. - If Mal cracks someone else's server, that server still doesn't have the bank's certificate, and won't have the bank's dns domain, either. So the browser should think that it got the wrong certificate. The user should always check that they have the right certificate and that it verifies correctly. If the user doesn't do that, no amount of DNS security will save them from a variety of phishing or similar-URL/similar-domain attacks. Every browser that I know of allows the user to examine the certificate and its validation. If the user fails to check this, they lose. This thread is quite interesting: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00853.html There has been some assertions that SMTP anti-spam security depends on DNS security. These schemes don't hold water. In 2003, I showed that the information theory result that no communication system can be proven free of covert channels implies that no communication system can be designed 'spam-free'. I think you carry this argument a bit farther than is justified. It's probably true that no security system can be perfect. Locks don't keep out determined lock pickers. They certainly don't keep out people with fire axes. But they do raise the cost of entry. I'll try to keep it pertinent to DNSSEC. In this case, the cost of entry is the botnet, and the cost isn't altered at all by DNSSEC, or by SMTP alteration, micropayments, estamps, SPF, or what have you. Once the computer is controlled by a virus, the attacker has the user's credentials--all of the credentials. Adding more layers of authentication can't change anything. People seem to have a hard time understanding that the virus on their computer is, electronically, _them_. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Mark Andrews wrote: Considering that two RRs each containing 2048 bit data will need oversized messages, they may not be properly treated by some servers. Those suffering from oversized messages may turn-off DNSSEC and there is instability for those moving with their laptops. And how is this different from the answers from TLDs which have already turned on DNSSEC? Though I never said answers from root servers is oversized, if some server under such TLD generates oversized messages, there should be instability observed. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote: Hi, On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote: But until we have root and .com signed, and until the average end- user is protected by a validating resolver, we aren't done yet, and I don't really get any actual benefit from my efforts. Which, tragically, is why it's taking so long. There are people who appear to think deploying DNSSEC as soon as possible would be a good thing. There are also people who appear to think deploying DNSSEC is a fools errand, that it won't get significant use because it makes things too hard, too complicated, too prone to failure, etc. However, because of DO, folks who don't configure their resolvers to do DNSSEC shouldn't ever see any DNSSEC goop. Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? Having signed a large delegation centric zone and as expected not seeing any security/stability issue for a significant amount of time I would say NO. That is, if you don't care about DNSSEC, do you think it would be bad(tm) if the root were to be signed (for the sake of argument, ignore the time waste, administrative overhead, etc. associated with DNSSEC-signing)? If so, why? Ok, I do care but the answer is still NO. Besides the large amount of statements accusing if of being a pig-protocol it is really well thought on incremental deployment for clients. Thanks, -drc Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
At 11:29 AM -0700 8/15/08, David Conrad wrote: Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? Yes, at the time of the first root key rollover. Well, to be more specific, at the time that all of the keys in the first announced set of root keys have been retired. Given the little effort that has been made in helping rDNS operators understand that they have to keep their trust anchors up to date, we should expect them to treat trust anchors the same way they treat root hints. Even if the root rollovers are done following RFC 5011, this only helps rDNS operators running 5011-aware resolvers. All the rest will be out of luck when the last key they have in their dusty config file is removed. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Paul, On Aug 15, 2008, at 12:26 PM, Paul Hoffman wrote: At 11:29 AM -0700 8/15/08, David Conrad wrote: Given this, does anyone see any DNS security and/or stability concerns if a miracle were to happen and the root were to be signed tomorrow? Yes, at the time of the first root key rollover. If you haven't configured DNSSEC in your caching server (that is, you don't think DNSSEC is worth your time), I have some skepticism that you'd have concern about key rollover. You're asking a different question than the one I'm asking. While I agree the question you're answering (specifically, should DNSSEC be deployed without a better way of ensuring root key rollover doesn't spontaneously break the DNS) is important, I'm trying to understand something different. Let me try to (hopefully) more clearly articulate my question: given the fact that caching servers only care about DNSSEC if they're explicitly configured to do so, does anyone anticipate any stability/ security concerns to those folks who _haven't_ configured DNSSEC if the root is signed? Thanks, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Paul, On Aug 15, 2008, at 1:51 PM, Paul Hoffman wrote: If what you really, really mean to ask is given the fact that caching servers only care about DNSSEC if they're explicitly configured to do so, does anyone anticipate any stability/security concerns to those folks who _don't_ configure DNSSEC if the root is signed?, then I would say no, I don't see any. OK, thanks. I suspect this question will be coming from on high at some point... As to your question above: people who _haven't_ configured DNSSEC _will_ configure DNSSEC after the root is signed due to lots of press and the general feeling that more security layers are good. If we don't give those people the right tools to properly configure and properly maintain those configurations, there will be stability issues, as I listed earlier. This reads a bit to me like build it and they will come and hit themselves upside their heads with bats, so don't build it until we've figured out how to keep people from hurting themselves. If someone configures DNSSEC in their caching server and then forgets their care and feeding duties, they will at some point discover that their DNS lookups aren't working so well and they'll either undertake their care and feeding duties with a bit more diligence (and/or upgrade to newer technology that handles care and feeding duties with minimal manual intervention) or they'll turn off DNSSEC. So, in the worst case, they'll get bitten and revert back to the same level of security (or lack thereof) they have today. Is this worth blocking DNSSEC deployment? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
At 4:07 PM -0700 8/15/08, David Conrad wrote: Paul, On Aug 15, 2008, at 1:51 PM, Paul Hoffman wrote: If what you really, really mean to ask is given the fact that caching servers only care about DNSSEC if they're explicitly configured to do so, does anyone anticipate any stability/security concerns to those folks who _don't_ configure DNSSEC if the root is signed?, then I would say no, I don't see any. OK, thanks. I suspect this question will be coming from on high at some point... As to your question above: people who _haven't_ configured DNSSEC _will_ configure DNSSEC after the root is signed due to lots of press and the general feeling that more security layers are good. If we don't give those people the right tools to properly configure and properly maintain those configurations, there will be stability issues, as I listed earlier. This reads a bit to me like build it and they will come and hit themselves upside their heads with bats, so don't build it until we've figured out how to keep people from hurting themselves. s/keep people/keep most people/ Yes. If someone configures DNSSEC in their caching server and then forgets their care and feeding duties, they will at some point discover that their DNS lookups aren't working so well and they'll either undertake their care and feeding duties with a bit more diligence (and/or upgrade to newer technology that handles care and feeding duties with minimal manual intervention) or they'll turn off DNSSEC. The above assumes that all the DNSSEC-capable resolvers have error messages for the trust anchor for .tld has gone bad and here is what you can do about it that are as easy to understand as the trust anchor for .tld has gone bad and here is what you can do about it. That seems pretty unlikely from recent history. Even the you might want to turn off DNSSEC until you understand what is happening is a bit of a stretch with current resolver software. So, in the worst case, they'll get bitten and revert back to the same level of security (or lack thereof) they have today. Fully agree. Is this worth blocking DNSSEC deployment? Nope, but that is not what you asked. You asked for any stability/security concerns, not blocking concerns. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
