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 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. > > - 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. > > well... lets agree to disagree here. > > > - 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) May be published. 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 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 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? DS/DNSKEYs need to be supplied to the parent over the same channel that NS updates are supplied over. If you are not already applying anti-spoof techniques to NS updates you can't trus DS/DNSKEY updates. > > - 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. So's getting the wrong NS RRSet or getting bad glue A and records. > > - The DNSKEY is already published, so the parent can trivially get it, > > Really? Getting it securely is not that trivial. It doesn't need to be secure it should just be for conformation of the existing information over the existing channel. > > in a way that is not subject to poisoning (the NS glue is hardcoded in > > the parent zone, after all) > > IP spoofing is possible. DNSSEC really does not change the level of security parents should be applying to delegation updates. If the parent is using a third party then that third party for delegation updates also needs to apply similar proceedures for DS/DNSKEY as for NS, A and . Mark > See RFC5011 ? > > Paul > ___ > 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 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:56:09AM -0400, Brian Dickson wrote: > [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 no arguement there > - Having DS sent to the parent, rather than calculated locally by the > parent, introduces a host of human and/or process risks/requirements as opposed to sending the DNSKEY? > - The DS only needs to be built when the DNSKEY changes (key rollover) yes - and the child rolls the DNSKEY, not the parent. > - 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. > - 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. well... lets agree to disagree here. > - 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) and the NSset comes from the child like the DNSKEY and (in my case) the DS rr. The rational for the child creating the DS is matching key validity periods with the TTLs at the child. > > 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? see above. :) > > Brian YMMV - my current policy is to create my DS rrs and send them to the parents. just like sending the paretn the right NSsset. --bill ___ 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 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
[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
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
I suggest you review the past emails and the RFC's to find out what is meant by a 'non-verifying DNSSEC cache'. A DNSSEC-aware cache need not verify the responses it caches. It can leave that task to the stub-resolver. By having the stub resolvers perform the crypto checks, the crypto computation resources scale. Of course, if the cache doesn't verify, it can't tell its been poisoned, and so ordinary poisoning will work. But if the cache does verify, then it has to perform a complex signature check, for which there are only limited computational resources available to perform the check. DNSSEC caches are cursed, either way. --Dean On Wed, 27 Aug 2008, Andrew Sullivan wrote: > 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 > > -- 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 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
> 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
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
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, 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
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 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
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
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
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
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
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: > 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? (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? Thanks, Brian ___ 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: > 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 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 Aug 22, 2008, at 6:27 PM, Dean Anderson wrote: 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. 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. 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) Unsigned delegations, not zones. 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'. In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are unsigned. 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. 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. 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. In fact, it seems that rekeying has to be done on any change, else the old NSEC records can be used to poison caches. No, this is why RRSIG records have expiration times. 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. -- David Blacka <[EMAIL PROTECTED]> Sr. Engineer Platform Product Development ___ 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 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 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. 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. So the resolver is required to validate the entire trust chain up to the trust anchor. When it does this, it will discover a problem. Suppose this is a host in .SE, and you have a trust anchor configured for .SE. And the name you're looking up is avalon.fugue.se. So you go to .SE, and it tells you that fugue is unsigned, because your attacker has forged the response. The signature doesn't verify. So you discard the response from the fake .SE, and try again. If the attacker has complete control of your path, the lookup will never succeed, which is the desired result. If the attacker is doing a scattershot attack, the next response that comes back will probably be the correct one, and you'll be back in business. Suppose the response from .SE is correct, but the response from fugue is modified to remove the DS records. .SE says fugue is signed. So you discard the forged response from fugue, and the same thing happens. Is there some avenue of attack I've missed here? Do I fail to correctly understand how the protocol works in some subtle way that makes your argument correct, and mine mistaken? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Thu, 21 Aug 2008, Frederico A C Neves wrote: > On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote: > > 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. > > Even knowing that this will probably ruin our deprive of your company > for the following week I'll point you out to carefully read 4035 > sections 3.1.4, 4 and 5. > > If the child is signed the DS is mandatory with the referrals, if it's > not signed the NSEC that proofs it's inexistence is mandatory. So > you'll still need to make the RRSIG for the NSEC, and AFAIK you'll > need access to the parents private key to make it happen. Sigh. Above is precisely the sort of non-critical analysis that causes these things to have so many problems. 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. --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 Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote: > 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. Even knowing that this will probably ruin our deprive of your company for the following week I'll point you out to carefully read 4035 sections 3.1.4, 4 and 5. If the child is signed the DS is mandatory with the referrals, if it's not signed the NSEC that proofs it's inexistence is mandatory. So you'll still need to make the RRSIG for the NSEC, and AFAIK you'll need access to the parents private key to make it happen. Fred ___ 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
In your previous mail you wrote: If a caching server is required to perform public key computation to verify RRs before caching, it can't support much clients... => the common assumption that public key computation is slow or expensive is *wrong*. According to 'openssl speed rsa', My old 20EUR/month box is at 2900 verify/s (1024 bits) and any recent desktop should be >> 1 verify/s. DNSSEC has a cost but it is not in the asymmetric crypto part! Regards [EMAIL PROTECTED] PS: I (as many Frenchs) believe in Elliptic Curves (mainly because of the size, i.e., not only for the speed). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
At 10:30 AM -0700 8/20/08, 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. DNSSEC will stop some of "that". It will prevent you from accepting changed data. --Paul Hoffman, Director --VPN Consortium ___ 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
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
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
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. ___ 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
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
[EMAIL PROTECTED] (Paul Vixie) writes:
> 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.)
i forgot to mention, i'm also worried about on-path attackers not just the
off-path attackers kaminsky, klein and dagon have recently noted. no hop-
by-hop solution can address the problem of a MiTM who can see and/or alter
your queries and responses.
therefore even though end-to-end ("DNSSEC") has been painful and has taken
too long to get deployable and is rather ugly, i'm backing it.
--
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
[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
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 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
2008/8/19 kevin graham <[EMAIL PROTECTED]>:
>
> On Tue, 19 Aug 2008, David Conrad wrote:
>
>> 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.
>
> At least in IOS's case, there was some gross misunderstanding that CNAME's
> should have their TTL's 0'ed (CSCsj10772) as a part of their translating
> payloads that contain A's and PTR's that are within nat address pools.
>
> The behavior is now configurable ("no ip nat service dns-reset-ttl"), but
> the stance was that "it's been this way so long we can't change the
> default". Ultimately, it was the breakage due to DNSSEC (rather than simple
> incorrectness) that got it addressed.
It took me hell lot of time and emails to explain this problem to tacman :-(.
Origin of this bug comes from broken implementation of RFC2694. And
unfortunatelly
I was not able to explain to them that they should modify TTL only in cases
covered by RFC2694.
The bad side of this bug is, that it breaks TSIG :(. I tried to have my own
public resolvers protected by TSIG.
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] 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
The claims that verifying DNSSEC caches can't be poisoned isn't true after all. On Tue, 19 Aug 2008, Masataka Ohta 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. A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. --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, David Ulevitch wrote: Sort of. It means I have to start another company that will charge slightly less egregious fees than the rest of you plan on doing to do DNSSEC management for companies the same way Thawte and Verisign did for SSL certs. Except now, there are no browser vendors dictating who gets a cert or at what price one can start selling certs or at which policy one is allowed into the browser's pre-installed trusted SSL treasure trove. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, 19 Aug 2008, David Ulevitch wrote: Nonetheless, I'll share some data. I've yet to have a single person, who was not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS. Well duh. For once, anyone who is asking you gets qualified as "fan boy", so your statement is self-fullfilling. Second, anyone using OpenDNS has already outsources their DNS security with you, so they expect you to do 'the right thing'. This is like saying just because i tell my car mechanic "replace my tires when you think they need replacement", and no one has asked for Good Year tires, you as the car mechanic conclude there is no demand for Good Year tires. On the contrary, I assume you give me the best tires. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, 19 Aug 2008, David Conrad wrote:
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.
At least in IOS's case, there was some gross misunderstanding that CNAME's
should have their TTL's 0'ed (CSCsj10772) as a part of their translating
payloads that contain A's and PTR's that are within nat address pools.
The behavior is now configurable ("no ip nat service dns-reset-ttl"), but
the stance was that "it's been this way so long we can't change the
default". Ultimately, it was the breakage due to DNSSEC (rather than
simple incorrectness) that got it addressed.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David, On Aug 19, 2008, at 10:27 AM, David Ulevitch wrote: Do you want to fund my costs of supporting (and encouraging my clients to use) DNSSEC? I don't use your service. If your customers feel there is value in what DNSSEC can provide, they'll presumably pay you for DNSSEC functionality and if you don't have it, they'll find some other way of meeting their needs. Of course, the decision is yours as to whether and/or at what point in time you want to take the risk/cost of adding DNSSEC functionality to your service. You forgot to wrap that in airplane>. Hmm. Sorry if you feel your business model is threatened. But I'll take your non-answer as a "no." That is indeed my answer. Sorry if that wasn't clear. Not sure why you'd think it would be an appropriate question to even ask. Nonetheless, I'll share some data. I've yet to have a single person, who was not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS. Nice to know. How many people requested "D-H key exchange, DTLS, DNS PING"? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Ted Lemon wrote: On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote: 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. The answer to that question has to take into account what benefit accrues to you from preventing DNSSEC from being deployed. And that is why David asked the question he asked. What benefit accrues to you from stopping the deployment of DNSSEC? First -- this is the most rational email on this thread. Thanks. Second -- 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. It's really silly for us to be debating whether or not we personally want to use DNSSEC. If you don't want to use it, don't use it. But I *do* want to use it. And in order for me to use it, the root zone and the TLDs have to start using it. So the question is, is that bad for you for some reason? Sort of. It means I have to start another company that will charge slightly less egregious fees than the rest of you plan on doing to do DNSSEC management for companies the same way Thawte and Verisign did for SSL certs. And my plate is pretty full at the moment. -David ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David Conrad wrote: Do you want to fund my costs of supporting (and encouraging my clients to use) DNSSEC? I don't use your service. If your customers feel there is value in what DNSSEC can provide, they'll presumably pay you for DNSSEC functionality and if you don't have it, they'll find some other way of meeting their needs. Of course, the decision is yours as to whether and/or at what point in time you want to take the risk/cost of adding DNSSEC functionality to your service. You forgot to wrap that in airplane>. But I'll take your non-answer as a "no." Nonetheless, I'll share some data. I've yet to have a single person, who was not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS. -David ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote: 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. A simple solution that doesn't work always sounds better than a complex solution that does work, particularly if you analyze neither solution deeply enough to understand what each one buys you, and what each one does not buy you. The question is not, "do you want to implement DNSSEC?" Clearly you don't. It's not "can we use DTLS to protect the last mile in the current DNS model?" Clearly we can, if people want to, and nobody's saying not to do that. The real question is, "are you harmed if people who *do* see DNSSEC as solving a real need that they have do implement it?" Or perhaps better stated, "should people who need DNSSEC be prevented from implementing for your benefit?" The answer to that question has to take into account what benefit accrues to you from preventing DNSSEC from being deployed. And that is why David asked the question he asked. What benefit accrues to you from stopping the deployment of DNSSEC? It's really silly for us to be debating whether or not we personally want to use DNSSEC. If you don't want to use it, don't use it. But I *do* want to use it. And in order for me to use it, the root zone and the TLDs have to start using it. So the question is, is that bad for you for some reason? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David, On Aug 19, 2008, at 9:09 AM, David Ulevitch 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. Indeed it has. However, I gather Masataka is concerned about (D)DoS against caching servers due to the increased workload of validating cryptographic signatures. If the caching server is moved down closer to the end node, the fact that the Internet has grown becomes irrelevant since the validation load is being spread across many machines. Do you want to fund my costs of supporting (and encouraging my clients to use) DNSSEC? I don't use your service. If your customers feel there is value in what DNSSEC can provide, they'll presumably pay you for DNSSEC functionality and if you don't have it, they'll find some other way of meeting their needs. Of course, the decision is yours as to whether and/or at what point in time you want to take the risk/cost of adding DNSSEC functionality to your service. Regards, -drc ___ 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
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
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: > 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. 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. 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? >> 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). Increase on the nameservers directly interacting authoritative nameservers increases not only legitimate queries but also DDOS queries. > 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? Then, as I mentioned, the caching server are so easy victims of DOS. Anyway, your approach is meaningless against "com.". > 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. Thank you for providing yet another evidence that DNSSEC won't be deployed so much. >> 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. Remember that I was the only person who understood the math of both DNS and PKI, when DENSEC was initially discussed. Yes, "Math is hard" for you. As the person who still understand the math of both, I can authoritatively declare that DNSSEC is fundamentally broken, which you could have argue against 10 years ago but not now. 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
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 Tue, 19 Aug 2008, Masataka Ohta wrote: You mean all the DNSSEC clients should directly ask authoritative nameservers and all the firewalls preventing so should be modified. (distributed) point to point encryption (or validation) is the future! 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). I see no problem for port 53 through NAT's. That is when using DNSSEC. When not using DNSSEC, you have issues with NAT devices undoing your source port randomizations. Also, firewall admins can still do things like transparent proxying of DNS. But really, so many desktop applications do direct DNS now themselves with disregard of the OS, those networks would be broken anyway. 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. 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. 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. That's not an alternative (nor correct) Paul ___ 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
On Aug 18, 2008, at 5:21 PM, Masataka Ohta wrote: The fact is DNSSEC is the *only* game in town for preventing cache poisoning. Not at all. Which game do you propose? If a caching server is not required to perform public key computation to verify RRs before caching, ... Then the caching server isn't really implementing DNSSEC. 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. For example, I am fairly confident the validating caching server running on my laptop isn't going to be any more subject to a DDOS due to the increased cost of crypto verification that it would be subject to a DDOS due to (say) a ping flood. I am curious what you propose as an alternative. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
