Re: [DNSOP] Cache poisoning on DNSSEC
On Wed, Aug 27, 2008 at 06:54:53PM -0400, Dean Anderson wrote: I suggest you review the past emails and the RFC's to find out what is meant by a 'non-verifying DNSSEC cache'. I have a passing familiarity with the RFCs, and the phrase non-verifying DNSSEC cache, and even non-verifying, appears nowhere in RFC 4033, RFC 4034, or RFC 4035, as near as I or grep can tell. I think you have some terms confused, which is why I asked. In particular, A DNSSEC-aware cache need not verify the responses it caches. I think that the word you want here is validate, not verify. The terminology is defined in RFC 4033 in particular. There are places in the documents where other terms -- authenticate is also used -- turn up, but for the purposes of this discussion, I think it's best that we stick to the strictly defined terms so that we don't get confused. Usually, I think it preferable to say that individual signatures are verified, and responses are validated. There is a subtle difference between these two notions, and understanding the difference is going to be crucial in evaluating some of the claims you are making. This is why I'm trying to be precise. So let me outline the cases I think there are, and you can say whether I've captured all the cases you think are relevant, and where you think the vulnerabilities are. In each case, let's assume we are asking for a name that has been signed so that we don't have to worry about cases that we know can't be secured. Case 0: security-oblivious stub resolver, security-oblivious recursive resolver, security-oblivious server. [Note: this case is effectively impossible under our assumption, since the server can't really serve a domain that's been signed. I have it here for completeness, but a deployment like this is already broken in operation. I'll skip cataloguing the other variants of security-oblivious server on these grounds.] Case 1: security-oblivious stub resolver, security-oblivious recursive resolver, security-aware server. Case 2: security-oblivious stub resolver, security-aware recursive resolver with a local policy of no DNSSEC, security-aware server. Case 3: security-oblivious stub resolver, security-aware recursive resolver with a local policy of DNSSEC, security-aware server. Case 4: security-aware stub resolver that does not set the CD bit, security-aware recursive resolver, security-aware server. Case 5: security-aware stub resolver that does set the CD bit. security-aware recursive resolver, security-aware server. Case 6: security-aware stub resolver that does not set the CD bit, security-oblivious recursive resolver, security-aware server. Case 7: security-aware stub resolver that does set the CD bit, security-obvlious recursive resolver, security-aware server. Have I missed something? Which of these are the cases where you think (a) cache poisoning is possible at the recursive resolver and (b) the stub resolver can be fooled by Mallory? Best, 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] Cache poisoning on DNSSEC
On Thu, 28 Aug 2008, Brian Dickson wrote: (I would posit that the folks generating the DNSKEY will also want to generate the DS hash on their known, trusted signing tools instead of trusting the parent w/ the DNSKEY materials) Well, here's why: - The DS is a deterministic function - Having DS sent to the parent, rather than calculated locally by the parent, introduces a host of human and/or process risks/requirements How does the parent know it is not getting spoofed, assuming this is the first time a DS record is created for the sub domain? - Nothing in the DNSKEY, or in the building of the DS, involves private keys, only public keys - so there is no trust issue with the materials. Getting the wrong public key in the DS record is a trust issue. - The DNSKEY is already published, so the parent can trivially get it, Really? Getting it securely is not that trivial. in a way that is not subject to poisoning (the NS glue is hardcoded in the parent zone, after all) IP spoofing is possible. See RFC5011 ? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote: The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. thats an interesting premise. why do you think this will be the case? (I would posit that the folks generating the DNSKEY will also want to generate the DS hash on their known, trusted signing tools instead of trusting the parent w/ the DNSKEY materials) Brian --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote: The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. thats an interesting premise. why do you think this will be the case? (I would posit that the folks generating the DNSKEY will also want to generate the DS hash on their known, trusted signing tools instead of trusting the parent w/ the DNSKEY materials) The parents can seen the public side of the DNSKEY materials which the DS identifies. Brian The problem is that *only* the child knows which DNSKEYs need DS records and which ones don't. The child may even want to have DS's published in advance of the associcated DNSKEY being published to reduce DNSKEY RRset size at KSK rollover by using a replacement strategy for the KSK. 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] Cache poisoning on DNSSEC
On Fri, Aug 29, 2008 at 10:23:53AM +1000, Mark Andrews wrote: - The parent is already trusted with DNSSEC tools, since the parent is signing the parent's zone (including the DS record!) assuming facts not in evidence. there is active discussion about having unsigned zones w/ DS records included. Well you are not talking about DNSSEC 4035 then. Such DS records are just noise to DNSSEC 4035. Well, i never said I was talking abt DNSSEC 4035. (what is that anyway? DNSSEC as defiend by RFC 4035?) I was talking about who generates DS rr's. Brian postualates the parent is always ready and willing to do so, I disagree, based on empirical evidence. --bill 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] Cache poisoning on DNSSEC
- The parent is already trusted with DNSSEC tools, since the parent is signing the parent's zone (including the DS record!) assuming facts not in evidence. there is active discussion about having unsigned zones w/ DS records included. Well you are not talking about DNSSEC 4035 then. Such DS records are just noise to DNSSEC 4035. Well, i never said I was talking abt DNSSEC 4035. (what is that anyway? DNSSEC as defiend by RFC 4035?) Yes. I was talking about who generates DS rr's. Brian postualates the parent is always ready and willing to do so, I disagree, based on empirical evidence. So do I. See my other posts. Mark --bill 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 -- 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] Cache poisoning on DNSSEC
On Tue, Aug 26, 2008 at 05:25:44PM -0400, Dean Anderson wrote: An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty Wait a minute. You're proposing to show that a DNSSEC cache that doesn't actually do DNSSEC (whatever that would mean) can be poisoned? I'm not sure I see the reasoning. I don't think that a positive result would be very big news at all -- in my view, a DNSSEC cache that doesn't validate responses is, well, not a DNSSEC cache at all. Is your concern that a DNSSEC-aware recursing resolver, with validation turned off, can be poisoned even though it correctly handles all the DNSSEC-requesting questions from a stub resolver, and correctly handles the data from a DNSSEC-offering server, in the case where Mallory can win the race and answer the non-validating DNSSEC-aware resolver before the legitimate server? 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] Cache poisoning on DNSSEC
Dean Anderson wrote: On Sun, 24 Aug 2008, Brian Dickson wrote: Dean Anderson wrote: On Sun, 24 Aug 2008, Dean Anderson wrote: Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. You say there is a crypto attack on re-signing. One using arbitrary data provided by the attacker - what is the arbitrary data, as opposed to some other kind of data? I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: Basically, if the attacker can pick a known-plaintext that corresponds to a large-prime, they can use the result and the public key to obtain the private key. This is consequence of modular arithmetic. I'm not entirely certain from memory if the plaintext has to be prime or if it can be a multiple of a prime. What Dean describes is a general attack on PKI math, not on (re-)signing as DNSSEC (RFC4034) specifies for RRSIG. His theory is, if the attacker can arrange for the thing being signed to be a prime (or possibly even the product of two known primes), then it may be possible to recover the key used for signing, based on the signature. The question is, is it possible for an attacker to arrange for the thing being signed to be a prime, or some arbitrary value? No. There is no way to deterministically cause a known value to be used for what gets signed. Here's why: signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) But: RRSIG_RDATA includes the expiry and incept date - chosen by the signer, not the attacker. Even worse, the contents of RR(1) are a DS record, which is itself a digest of a DNSKEY record. The DNSKEY record includes a few fields which are mostly 0's (7/8, 7/8, 6/8 on three octets). The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. So, there are 20 bits of zeros which get used in a digest, and 64 bits not under the attackers control, plus 16 bits of fixed value (Type Covered), an 8-bit fixed value field (Labels), plus the Signer's Name is also a fixed value. That's way more than 88 bits of data not under the control of the attacker. For perspective, 2^88 is the number of seconds in the age of the universe, estimated. To suggest that appending a digest value to that, and having the result be a prime, does not strike me as a serious threat to key recovery by an attacker. So, I would say that in all likelihood, re-signing with the *same* key is perfectly safe. (The inclusion of the signature's own timestamp values in the data being signed was, IMHO, genius.) Brian P.S. This does not, however, mean that there does not exist some other key recovery risk; if anyone knows of one, please detail it or give a reference. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
[EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote: The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. thats an interesting premise. why do you think this will be the case? (I would posit that the folks generating the DNSKEY will also want to generate the DS hash on their known, trusted signing tools instead of trusting the parent w/ the DNSKEY materials) Well, here's why: - The DS is a deterministic function - Having DS sent to the parent, rather than calculated locally by the parent, introduces a host of human and/or process risks/requirements - The DS only needs to be built when the DNSKEY changes (key rollover) - The parent is already trusted with DNSSEC tools, since the parent is signing the parent's zone (including the DS record!) - Nothing in the DNSKEY, or in the building of the DS, involves private keys, only public keys - so there is no trust issue with the materials. - The DNSKEY is already published, so the parent can trivially get it, in a way that is not subject to poisoning (the NS glue is hardcoded in the parent zone, after all) It isn't something that seemed obvious until I looked at the signing stuff. If the DS is deterministic, why create an avenue for expoiting? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Moin! On Aug 26, 2008, at 02:15 , Masataka Ohta wrote: Could you elaborate on how fast converging routing protocols can be a problem? Well I believe it was in our case as we did observe some strange behaviour when starting to test with anycast DNS. Anycast TCP fails only when route changes upon a link failure or recovery. So, anycast TCP should fail regardless of how quickly or slowly the route changes, shouldn't it? A link failure always is the root of all evil, but we observed different behaviour of anycast and unicast tcp with it. Let me tell you what we observed. In one of our initial test setups the anycast addresses where announced with our internal routing protocol on the router that connected the anycast server. Now the link had duplex mismatch between the router and the server and thus the link flipped several times per second. While we could reach the box on it's unicast address with tcp (ssh) and got some answers over udp, we couldn't do a tcp connection to the anycast address on it no matter how hard we tried. We then changed the design so that the server itself announces the anycast addresses via an external routing protcol (BGP) and didn't have the problem above even on a deliberately duplex mismatched link. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: [EMAIL PROTECTED] http://www.colt.net/ Data | Voice | Managed Services * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Sun, 24 Aug 2008, Brian Dickson wrote: Dean Anderson wrote: On Sun, 24 Aug 2008, Dean Anderson wrote: Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. You say there is a crypto attack on re-signing. One using arbitrary data provided by the attacker - what is the arbitrary data, as opposed to some other kind of data? I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: Basically, if the attacker can pick a known-plaintext that corresponds to a large-prime, they can use the result and the public key to obtain the private key. This is consequence of modular arithmetic. I'm not entirely certain from memory if the plaintext has to be prime or if it can be a multiple of a prime. (e.g. If the data being signed were limited to valid public key data that might, for example, be possible to itself be validated before signing)? Can you provide a reference to back up this assertion? I think there is a description of this in Schier's book, or other books that describe security and insecurity of PKI depending on modular arithmetic, like RSA. If you still can't find it, let me know and I'll send you detailed reference tomorrow. --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] Cache poisoning on DNSSEC
On Mon, 25 Aug 2008, Ralf Weber wrote: It should be noted that unicast TCP is unstable if unicast routing is unstable. Yes, but TCP usually adapts to the problem while anycast can't, as it may reach another target. Large UDP packets (think EDNSO DNSSEC as a good example of large UDP packets almost certain to be fragmented) suffer the same problem, as they can be fragmented by PMTU discovery. The server (operating system) has to maintain UDP state for PMTUD to work. If the ICMP fragmentation needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are fatal to the UDP transaction. As someone who has deployed anycast DNS within a carrier network there are some things to consider , e.g don't put anycast routes in fast converging routing protocols and be careful with multi links for similar destinations. FIB entries change at every hop. The more hops away, the more often the paths can change. What works close by, might not work far away, and vice versa. But if you follow the rules it can be deployed and also works with tcp transport for DNSat least for me. But the question is not whether your DNS works for you; The question is whether it works for everyone else. While you may be satisified with your own DNS operations, you may not care if they work for everyone. Different requirements apply to Root and TLD services. Everyone, everywhere has to be able to use Root and TLD DNS services reliably. This is precisely the 'deploy and hope for the best' attitude at its worst: It worked for me in a very limited scenario, and I don't worry about theory or about what works everyone. --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] Cache poisoning on DNSSEC
On Tue, Aug 26, 2008 at 02:44:08PM -0400, Dean Anderson wrote: I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: If you're claiming that, after 10 years and review unto death, people with significant profile in the crypto community got the math wrong, I don't think you're going to get a warm reception. I think you need to demonstrate that there is an actual problem. Certainly, we'll need an argument somewhat stronger than, The math could be wrong somewhere. I seem to remember you were going to spend this week producing a demonstration of an actual attack. It's early days yet; DNSSEC is not widely deployed. If you have such an attack, it would be a really significant service to all DNS operators to demonstrate it. To be clear, I'm not being even a little bit sarcastic: if you have such an attack, and it's not something that is already well-understood about the protocol, I believe that everyone wants to see it as soon as possible. I encourage you to perform your demonstration. 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] Cache poisoning on DNSSEC
Moin! On Aug 26, 2008, at 21:02 , Dean Anderson wrote: Large UDP packets (think EDNSO DNSSEC as a good example of large UDP packets almost certain to be fragmented) suffer the same problem, as they can be fragmented by PMTU discovery. The server (operating system) has to maintain UDP state for PMTUD to work. If the ICMP fragmentation needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are fatal to the UDP transaction. Ack that's the reason why the MTUs in todays networks get bigger and bigger. FIB entries change at every hop. The more hops away, the more often the paths can change. What works close by, might not work far away, and vice versa. FIB and path changes only matter when the final IP destination changes, again not a problem in todays network where IP is just one overlay transport of an underlying label switched network. And thus the path changes, but the final (anycasted) destination does not. But if you follow the rules it can be deployed and also works with tcp transport for DNSat least for me. But the question is not whether your DNS works for you; The question is whether it works for everyone else. While I get paid for that it does work four our customers, so this obviously this is my first concern. While you may be satisified with your own DNS operations, you may not care if they work for everyone. Well we are doing DNS anycasting for recursive resolvers and I know at least of three other carriers that do exactly the same and where it also works. Different requirements apply to Root and TLD services. Everyone, everywhere has to be able to use Root and TLD DNS services reliably. True, and I haven't spoken about that as I don't have experience there, I guess Peter Koch or Anand Buddhdev are some of the persons I would talk to about this, as they are doing it. As a consumer of anycast TLD dns services I so far haven't encountered a problem, despite that we are using tcp as fallback mechanism for suspected spoofing. And as external BGP routing usually is a lot more stable than internal routing service I would think that problems are less than in one ASes network. This is precisely the 'deploy and hope for the best' attitude at its worst: It worked for me in a very limited scenario, and I don't worry about theory or about what works everyone. Well we did test, discovered some problems, worked around them and now are happy deploying it. That's what engineers are for. There may be theoretically cases, but unless they can be proved in a lab and there is no way around it I don't care to much. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: [EMAIL PROTECTED] http://www.colt.net/ Data | Voice | Managed Services * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, 26 Aug 2008, Andrew Sullivan wrote: On Tue, Aug 26, 2008 at 02:44:08PM -0400, Dean Anderson wrote: I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: If you're claiming that, after 10 years and review unto death, people with significant profile in the crypto community got the math wrong, The text of mine that you quote was an explanation of how a chosen plaintext attack works on PKI like RSA. All that I said is that I can't quote the exact math of how the attack works. However, If you mean to suggest that DNSSEC has been checked over for 10 years by crypto experts without finding flaws, I think your drawing the wrong conclusion from DNSSEC history, as well as who has certified its security. DNSSEC work has proceeded in fits and starts for 15 years. Prior DNSSEC work has been almost completely abandoned by RFC4033-35. Not completely replaced, since there are new typecodes are needed to continue with incompatible use of SIG, KEY, and NXT records from prior (failed) attempts at obtaining secure and workable DNSSEC. I don't think you're going to get a warm reception. I think you need to demonstrate that there is an actual problem. Certainly, we'll need an argument somewhat stronger than, The math could be wrong somewhere. I never said 'the math could be wrong somewhere'. I said there is a PKI(RSA) chosen plaintext attack through which one can obtain the private key used to sign DNSSEC records. There is no ambiguity about the existance of that attack, but I will provide an authoritative reference tomorrow. I seem to remember you were going to spend this week producing a demonstration of an actual attack. An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty trivial; the code demonstrating the kaminsky poisoning will work with some DNSSEC changes. I won't be able to start on that until probably thurs or fri. I first have to find a non-verifying DNSSEC cache. I think BIND may work, but will have to check. If anyone has suggestions for a non-verifying cache, that would be appreciated. Or if some BIND experts have suggestions for making BIND not verify, that would save me some time. If someone wants to volunteer a non-verifying server that is otherwise in the wild for use, that would help. Contact me offlist. -- 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] Cache poisoning on DNSSEC
Large UDP packets (think EDNSO DNSSEC as a good example of large UDP packets almost certain to be fragmented) suffer the same problem, as they can be fragmented by PMTU discovery. The server (operating system) has to maintain UDP state for PMTUD to work. If the ICMP fragmentation needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are fatal to the UDP transaction. Actually you just turn off PMTUD on replies. This is recommended for *all* nameservers. It's pointless for authoritative nameservers to maintain PMTU state and may infact be a DoS vector if they do. IPv4 - Don't set FD. IPv6 - Fragment at the server at network MTU. The socket option IPV6_USE_MIN_MTU was a direct consequence of DNS operators looking at this issue over 10 years ago. http://www3.tools.ietf.org/html/draft-ietf-ipngwg-bsd-frag-01 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] Cache poisoning on DNSSEC
Brian Dickson wrote: Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. You say there is a crypto attack on re-signing. Do you know something about recent re-signing attack against Red Hat Linux distributions? One using arbitrary data provided by the attacker - what is the arbitrary data, as opposed to some other kind of data? Arbitrary forged data with forged, but, seemingly valid, signature on them, which is possible by attackers, including but not limited to those who knows the private key, having access to signature generation mechanisms. DNSSEC is not cryptographically secure against MitM attacks on intermediate entities of zones. PKI is not cryptographically secure against MitM attacks on intermediate entities of CAs. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Dean Anderson wrote: I recently read David Blacka's blog entry on Anycast, where Blacka asserted that Anycast had to be proven UNstable before anyone should consider stability questions. Blacka suggests that non-root operators had no experience or data to prove these things unstable--which is true and root operators aren't sharing their data. As the, seemingly, only expert on anycast in the world, anycast is stable as long as unicast routing is stable. It should be noted that unicast TCP is unstable if unicast routing is unstable. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Moin! On Aug 25, 2008, at 14:56 , Masataka Ohta wrote: As the, seemingly, only expert on anycast in the world, anycast is stable as long as unicast routing is stable. While that is true, there are situations where unicast reachabilty is working but anycast reachabilty is not. It should be noted that unicast TCP is unstable if unicast routing is unstable. Yes, but TCP usually adapts to the problem while anycast can't, as it may reach another target. As someone who has deployed anycast DNS within a carrier network there are some things to consider , e.g don't put anycast routes in fast converging routing protocols and be careful with multi links for similar destinations. But if you follow the rules it can be deployed and also works with tcp transport for DNSat least for me. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: [EMAIL PROTECTED] http://www.colt.net/ Data | Voice | Managed Services * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Ralf Weber wrote: It should be noted that unicast TCP is unstable if unicast routing is unstable. Yes, but TCP usually adapts to the problem while anycast can't, as it may reach another target. That unicast TCP fails in unusual cases means we, anyway, need retry mechanisms, which helps anycast TCP. As someone who has deployed anycast DNS within a carrier network there are some things to consider , e.g don't put anycast routes in fast converging routing protocols and be careful with multi links for similar destinations. But if you follow the rules it can be deployed and also works with tcp transport for DNSat least for me. Could you elaborate on how fast converging routing protocols can be a problem? Anycast TCP fails only when route changes upon a link failure or recovery. So, anycast TCP should fail regardless of how quickly or slowly the route changes, shouldn't it? I can understand that, with multi links, packet-wise load balancers disturbing packet ordering within TCP streams are, of course, harmful to anycast TCP. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Blacka, David wrote: If you had actually followed any of the discussions about DNSSEC over that last 13 years, you would know that this is false. Thinking about how it could break is what the vast majority of work on this topic has been about. I have paid attention to many of these discussions, and have recently reviewed some of the ones I didn't pay attention to. And indeed, there hasn't been a thorough analysis. Instead, critics (such as myself and Dr. Bernstein, perhaps others) were silenced. It appears that only Bernstein and myself were noisy about being silenced. Most people would just go away quietly, as many people expected myself and Bernstein to do, and some have even told me as much. Evidence of the lack of critical analysis is found in the several serious flaws identified so far. More evidence of a lack of analysis is found in the repeated cycles of going back to the drawing board and then reporting I think we have it this time, only to 'not have it', still. The tri fecta is found in the acts silencing critics. These acts conclusively discredit the claims that DNSSEC people were genuinely concerned with critical analysis of problems. Yet, despite all these contrary facts, Blacka still asserts DNSSEC advocates were somehow genuinely interested in solving security problem, rather than some other objective. There seems to be an irreconcilable difference of opinion here. Perhaps another example might shed light on the credibility of their approach: I recently read David Blacka's blog entry on Anycast, where Blacka asserted that Anycast had to be proven UNstable before anyone should consider stability questions. Blacka suggests that non-root operators had no experience or data to prove these things unstable--which is true and root operators aren't sharing their data. Hold on! Why should non-root operators have prove Anycast root operations are unstable using root-operations data? Why should anyone ASSUME a new, untested service will be stable? I think most people would agree that high stability operations must have some proof of stability BEFORE deployment of a new service. And once again, we see the same 'assume stability and deploy without extensive testing' as before. And after they asserted that TCP is stable for Anycast, they now want to deprecate TCP for DNS. (RFC 1546, analysis, and testing show TCP Anycast isn't stable) This is a lesson to be applied to DNSSEC deployment plans as well. Deploy untested and hope for the best is really not a credible operations strategy. And the delegation records are unsigned; the resolver has no way to know if they are correct; The delegation was picked so that NSEC3 RR's didn't change with the addition, and so the NSEC3 RRs verify correctly. The bad guy just uses those NSEC3 records 'as-is'. In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are unsigned. I noticed. This is not a problem because, if the delegation is secure (i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that matches one of the DS records. If not, then the response is considered bogus and (normally) thrown away. It is only 'not a problem' in the ideal case where no one is trying to trick the resolver. But when one is trying to trick the resolver, they can succeed as I described. This is just exactly what is meant by 'non-critcial analysis'. You only considered the ideal case. One can also do this exact same thing on signed delegations provided you have an earlier copy of a covering NSEC3 record signed with the same key. [So operators have to rekey anytime they create a new delegation.] No, you don't. This old NSEC3 (or NSEC) RRset isn't valid forever. The old record valid until its signature expires. As I noted, to avoid the attack, one must rekey everytime a change is made. It is well understood that you are vulnerable to a replay attack while the old RRSIGs are still valid. Which argues for short signature durations, not rekeying. Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. --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] Cache poisoning on DNSSEC
On Sun, 24 Aug 2008, Dean Anderson wrote: It is well understood that you are vulnerable to a replay attack while the old RRSIGs are still valid. Which argues for short signature durations, not rekeying. Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. --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] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Blacka, David wrote: So one can use poison on a validating DNSSEC resolver to achieve false resolution for any new unsigned zone. Put another way, the bad guy can create new delegations under opt-out NSEC3 records. This fact is specifically mentioned in the Security Considerations section of RFC 5155, so, true. And I should note that in the case of .com and .net zones signed with NSEC3, rather than going to the trouble of spoofing a domain into existence, a bad guy with ~USD 10 could just buy the domain. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Matt Larson wrote: Dean, On Fri, 22 Aug 2008, Dean Anderson wrote: It is manadatory in the _proper_ response. Of course, the _forged_ response can have anything the bad guy wants. If the bad guy decides not to follow 4035 (gasp! we never thought the bad guys might not follow RFCs!), and instead responds with a forged response that doesn't have the DS RR, and the delegation and glue records are normally unsigned, then the resolver will conclude the zone is unsigned, and place undeserved trust in the referral. Your analysis is incorrect. A referral from a signed zone either needs to have a DS and RRSIG(DS), indicating the child zone is signed and allowing the chain of trust to continues into the signed child, or an NSEC and RRSIG(NSEC) showing that no DS exists, proving that the child zone is unsigned and insecure. If a referral from a signed zone contains neither DS nor NSEC, the validating resolver assumes that a man in the middle has stripped them and the response is bogus. Good call. However, NSEC and NSEC3 records are static, and RRSIG(NSEC/NSEC3) records are statically calculated. The attacker need only read RFC5155 section 12 for instructions on how to compute a valid hash for use with the (known) NSEC/NSEC3 record. --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] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Ted Lemon wrote: On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote: Sigh. Above is precisely the sort of non-critical analysis that causes these things to have so many problems. Instead of making fun of other peoples' lack of critical thinking, you might want to take responsibility for your own thinking and let others take responsibility for theirs. I didn't make fun of anyone. The lack of critical analysis is no laughing matter. None of the promoters seems to ever make an effort to consider how things might break. There is far too much cheerleading and far too little of how it could break. The problem with your reasoning is that the resolver is configured with a trust anchor, and the zone with the missing DS records is below that trust anchor. There is no problem with my reasoning. Let me spell it out in more detail: The NSEC/NSEC3 issue has already been explained, but you didn't get the implications. The NSEC/NSEC3 opt-out records just signal that an unsigned zone exists (or could exist) From RFC5155: The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone. o When removing a delegation RRSet, if that delegation does not have a matching NSEC3 RR, then it was opted out. In this case, nothing further needs to be done. o When adding a delegation RRSet, if the next closer name of the delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone. And the delegation records are unsigned; the resolver has no way to know if they are correct; The delegation was picked so that NSEC3 RR's didn't change with the addition, and so the NSEC3 RRs verify correctly. The bad guy just uses those NSEC3 records 'as-is'. So one can use poison on a validating DNSSEC resolver to achieve false resolution for any new unsigned zone. Put another way, the bad guy can create new delegations under opt-out NSEC3 records. One can also do this exact same thing on signed delegations provided you have an earlier copy of a covering NSEC3 record signed with the same key. [So operators have to rekey anytime they create a new delegation.] In fact, it seems that rekeying has to be done on any change, else the old NSEC records can be used to poison caches. -- The assertion that validating DNSSEC caches can't be poisoned is false. -- This attack works on non-validating caches as well. -- Also, non-validating DNSSEC-aware caches are trivially poisonable to obtain a DOS attack. -- Key rollover is a much more frequent issue than has been described by promotors of DNSSEC. --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] Cache poisoning on DNSSEC
On Tue, 19 Aug 2008, Ted Lemon wrote: On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote: A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Do you mean that it can be convinced that an answer is valid when it is not? I mean that a validating cache can be convinced to think that a delegation is unsigned by getting unsigned glue records without a DS record. This glue can refer to a working (bogus) nameserver, or it can be a DOS on the delegation. I might try to demonstrate this by running code next week sometime. One might be able prevent this only if all zones and all delegations have been preconfigured keys, in which case RFC 4035 says a resolver SHOULD believe a zone is signed if it has a preconfigured key. (so one might still be spoof-able by an implmentation that doesn't reject unsigned responses in zones with preconfigured keys. Of course, updating all these preconfigured keys is going to be a PITA. This is another operational drawback, and significant operational expense. So DNSSEC is probably a self-inflicted DOS in practice after some key changes. --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] Cache poisoning on DNSSEC
Dean Anderson wrote: A property of Kaminsky's attack that it is effective against a single target is useful, here. I don't know if anyone noticed, but in fact, according to RFC4035 the delegation records and the glue records are not signed. Really? (I am not interested in reading RFC4035 only to confirm DNSSEC is broken beyond any attempt of repair) Then, it should not have been a problem if correct authority model of refferal was used, because cached glue records should have been used only for the refferal of same random domain name appears again, probability of which is negligible. However, according to Paul, most implementations are broken, upgrading of which is as time consuming as upgrading implementations to use modified protocol with, say, effectively 64 bit ID. A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Can you demonstrate it with existing implementations? Masataka Ohta PS Birtyday attacks can, seemingly, be protected against if outstanding query is invalidated (query fails) upon a reception of partially matching (query and server address but not ID matches) answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
[EMAIL PROTECTED] (David Ulevitch) writes: ... -- My goal is not to derail DNSSEC. It does that on its own. My goal is to make sure people don't buy into the kool-aid being poured that DNSSEC is the only solution. It isn't. that depends on the problem statement, really. if the problem statement is how can we secure hop-by-hop then there are other solutions on the table right now besides DNSSEC. if the problem statement is how can we secure end-to-end then there are no other solutions on the table right now. my chosen problem statement is how can we secure end-to-end because i am worried about corruption inside servers not just between them, and i want to defend against provider-in-the-middle attacks (including several that opendns currently monetizes.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Paul Vixie wrote: that depends on the problem statement, really. if the problem statement is how can we secure hop-by-hop then there are other solutions on the table right now besides DNSSEC. Wrong. PKI, including DNSSEC, does require hop-by-hop security between CAs, which is no different from hop-by-hop security between ISPs. Note that, at least in Japan, both ISPs and CAs are leagally required to be secure, which has nothing to do with cryptographic security. my chosen problem statement is how can we secure end-to-end And the answer is by sharing security information directly by both ends, which is not the case with PKI where security information is shared (or confirmed) hop-by-hop through multiple third party CAs. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, Aug 19, 2008 at 11:15:12PM -0400, Dean Anderson wrote: I don't know if anyone noticed, but in fact, according to RFC4035 the delegation records and the glue records are not signed. A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Please outline exactly how you think this will work. I just re-read section 5 of RFC 4035, and I can't see how it can, assuming you do in fact have a set of valid trust anchors for some superordinate zone to the victim domain. 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] Cache poisoning on DNSSEC
David Ulevitch wrote: Paul Vixie wrote: no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. Too many pronouns... DNSSEC provides the ability to determine that a given authoritative answer is signed (by DS on the delegation from the parent), and provides cryptographic signatures on such authoritative answers. The signatures can be chased up to a configured trust anchor, ideally a signed root. And without any private key in that chain of trust, he can't change signed authoritative data without causing validation to fail. With apologies to Meat Loaf: A Man in the middle can bedevil your wits, He can fiddle with packets, he can twiddle the bits, He can easily spoof your sequence numbers and such, But he can't spoof sigs, No he can't do that. Oh, no, No, he can't do that. -- Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David, On Aug 20, 2008, at 10:30 AM, David Ulevitch wrote: Paul Vixie wrote: no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. Yep. Question is, how many opportunities do you want to provide for MITM attacks? DNSSEC will not stop that. The full DNS lookup path is almost always different than the data content path. As such, it introduces a new MITM attack vector (and a particularly effective one at that as Kaminsky described). DNSSEC is intended to protect against that attack vector and does so albeit at some cost in terms of complexity of software and operations. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. please explain how i can get undetectably bad data in a dnssec environment, where bad means did not come from the zone editor. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote: So what? NAT at airport must be, unlike NATs in enterprises, consumer friendly. Unlike highe end NAT, low end NAT won't bother to interfere DNS. Right. Because low-end consumer gear is always so much better implemented than enterprise gear. Cloud you please provide us, not your personal experience, but an *EXHAUSTIVE*, or, at least exhaustive on high end, list on varieties of NAT functionalities? I'll get right on that. Actually, on second thought, you seem to be the one asserting fundamentally broken behavior on the part of high end gear. Shouldn't it be you that provides the data to back up your assertions? Increase on the nameservers directly interacting authoritative nameservers increases not only legitimate queries but also DDOS queries. You seem to be asserting that DDOS queries come from the same source as legitimate queries. Can I see your data that backs up this statement? Alternatively, we could move to a more distributed model of DNS operations in which the caching servers that are doing DNSSEC cache the entire root zone, perhaps zone transferring the signed root zone from some authoritative and trusted place. Are you seriously saying that you actively want to have intermediate caching servers between your laptop and authoritative servers? No. I'm suggesting that if the root zone is signed, the root zone data can be obtained from places other than the root servers without concerns about data corruption and installed in caching servers (something quite a few folks already do, ignoring the risk of corrupted data). This data can then be distributed out to the edge. This should address any concerns anyone might have with overloading the root servers. Anyway, your approach is meaningless against com.. Due to the thrash in the COM zone, yes. Fortunately, I didn't suggest applying the distributed model to COM. As the person who still understand the math of both, I can authoritatively declare that DNSSEC is fundamentally broken, Well, I guess that settles it then. You don't have to turn on DNSSEC. which you could have argue against 10 years ago but not now. It's such a shame that computer processing technology for doing stuff like cryptography hasn't advanced in 10 years. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David Conrad wrote: which you could have argue against 10 years ago but not now. It's such a shame that computer processing technology for doing stuff like cryptography hasn't advanced in 10 years. Unfortunately, the Internet has grown in 10 years, too. Do you want to fund my costs of supporting (and encouraging my clients to use) DNSSEC? If I'm going to spend cycles on improving the state of the art, it will be with a solution that is: 1) Solving a real customer need 2) Possible to evaluate 3) Realistic to implement I've yet to be shown how DNSSEC is any of those things. D-H key exchanges, DTLS, DNS PING, all sound far more appealing. -David ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Another 10 year delay would benefit all our respective businesses ;-) But to move forward you sometimes have to take chances. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ulevitch Sent: Tuesday, August 19, 2008 9:09 AM To: David Conrad Cc: dnsop@ietf.org WG Subject: Re: [DNSOP] Cache poisoning on DNSSEC David Conrad wrote: which you could have argue against 10 years ago but not now. It's such a shame that computer processing technology for doing stuff like cryptography hasn't advanced in 10 years. Unfortunately, the Internet has grown in 10 years, too. Do you want to fund my costs of supporting (and encouraging my clients to use) DNSSEC? If I'm going to spend cycles on improving the state of the art, it will be with a solution that is: 1) Solving a real customer need 2) Possible to evaluate 3) Realistic to implement I've yet to be shown how DNSSEC is any of those things. D-H key exchanges, DTLS, DNS PING, all sound far more appealing. -David ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote: A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Do you mean that it can be convinced that an answer is valid when it is not? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David Conrad wrote: If a caching server is required to perform public key computation to verify RRs before caching, it can't support much clients and will be a so easy victim of DDOS. Hence, one of the reasons for the desire to push DNSSEC towards the end user. You mean all the DNSSEC clients should directly ask authoritative nameservers and all the firewalls preventing so should be modified. OK. Let's assume all the clients agree with you and start using DNSSEC and all the administrators of firewalls agree with you and perform modification (though I don't know how NAT can be modified). Then, the increased load is a very good reason for root servers not support DNSSEC. I am curious what you propose as an alternative. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Paul Wouters wrote: (distributed) point to point encryption (or validation) is the future! It's no future. I see no problem for port 53 through NAT's. NAT often captures and modifies packet to port 53. But really, so many desktop applications do direct DNS now themselves with disregard of the OS, Today, most of them are using a DHCP-supplied server. Then, the increased load is a very good reason for root servers not support DNSSEC. I believe 99% of the load of root servers is bogus queries anyway. The amount of bogus queries will also increases, of course. Plus, I'm sure they wouldn't mind an increase to signal/noise ratio. Plus, those are addressed my things like anycast. It all scales fairly well, DNS being a distributed system and all. I'll take this argument as valid as soon as a root server operator comes forward and tells us this is a problem. For YOUR objections, let's stick to YOUR problems. FYI, root server load was my problem and anycast is my thing. More anycasting means more cost. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. That's not an alternative (nor correct) That's the reality with no alternatives. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Aug 18, 2008, at 8:22 PM, Masataka Ohta wrote: You mean all the DNSSEC clients should directly ask authoritative nameservers Yes. and all the firewalls preventing so should be modified. The vast majority of firewalls allow 'connections' (even UDP ones) to be initiated from the inside. Those that prevent DNS from working correctly could be modified or upgraded or the administrators could trust in that firewall to protect the caching server used by multiple clients from the DDoS attacks you are concerned about. Let's assume all the clients agree with you and start using DNSSEC and all the administrators of firewalls agree with you and perform modification (though I don't know how NAT can be modified). NAT does not need to be modified. As I type this, I am behind a commercial (relatively low end -- an Apple Airport Extreme basestation) NAT with firewalling enabled. It works just fine. Then, the increased load is a very good reason for root servers not support DNSSEC. The root server operators have demonstrated that they are quite capable of ramping capacity to meet demand (actually, the root servers are wildly over provisioned to try to deal with DDoS attacks so I doubt the increase in load caused by what I'm suggesting would even be an issue). Alternatively, we could move to a more distributed model of DNS operations in which the caching servers that are doing DNSSEC cache the entire root zone, perhaps zone transferring the signed root zone from some authoritative and trusted place. Since the root trust anchor would be published, the root zone data would be verifiable so fears of a corrupted root zone would be eliminated. I suspect a combination of both would more than suffice. What's more, recent studies have indicated that approximately 98% of the traffic hitting the root servers is pure crap. Interestingly, when the L-root server was renumbered, it seems the quantity of traffic hitting that root server is significantly lower than the others. One possible reason for this could be that people just don't like ICANN. Another reason could be that a really tremendous amount of crap is being generated by servers that are so old that they don't notice a root server address change. In the latter case, pushing caching servers out towards the edges would almost certainly entail upgrading those name servers. As a result, the root servers might actually see a reduction in traffic. I am curious what you propose as an alternative. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. Ah. The Math is hard. Let's go shopping. alternative. Not sure this is particularly helpful. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
