Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I seem to remember that some time back (two years or so?) RIPE-NCC also published data points and they were in about the same range. Some searching reveals: Ref:ripe-352 Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman RIPE NCC / NLnet Labs Date: October 2005 Format: PDF=5367108 The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf. Already three years ago, time flies jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
* Paul Vixie: better still, let's deprecate these bit patterns altogether for OP=QUERY: QTYPE=255 Breaks some sendmail versions and qmail. QCLASS=255 QCLASS != IN seems more reasonable to me. RA=1 AND RD=0 By the responder or the initiator? and let's also make explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. I strongly oppose this approach. Unsolicited TCP has its place. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Jaap Akkerhuis wrote: On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I seem to remember that some time back (two years or so?) RIPE-NCC also published data points and they were in about the same range. Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf. Already three years ago, time flies We also did another one for ripe a little bit later, but still more than two years ago: http://nlnetlabs.nl/downloads/publications/dnssec/dnssec-effects.pdf Jelte signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Tue, 19 Aug 2008 15:43:14 -0400, Andrew Sullivan [EMAIL PROTECTED] said: On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I think Peter's data point sure warrants further investigation, yes. More data points from two authoritative servers for the ch ccTLD: 40-50% (I've attached the relevant DSC graphs for the past month). I looked more closely on one of the servers. Out of about 22 million queries in the past 11 hours, about 10 million from 161000 different sources had the DO flag set. -- Alex inline: domreg-do.pnginline: merapi-do.png___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
* Alexander Gall: More data points from two authoritative servers for the ch ccTLD: 40-50% (I've attached the relevant DSC graphs for the past month). I looked more closely on one of the servers. Out of about 22 million queries in the past 11 hours, about 10 million from 161000 different sources had the DO flag set. Interesting, thanks. It seems that the BIND 9.3 recursor sets the DO bit by default, even if it does not support DNSSEC on the client interface without dnssec-enable yes; (IOW, the DO bit is ignored there). (Unbound sets the DO bit, too, but it processes it on the responder side as well.) -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Dean Anderson wrote: A property of Kaminsky's attack that it is effective against a single target is useful, here. I don't know if anyone noticed, but in fact, according to RFC4035 the delegation records and the glue records are not signed. Really? (I am not interested in reading RFC4035 only to confirm DNSSEC is broken beyond any attempt of repair) Then, it should not have been a problem if correct authority model of refferal was used, because cached glue records should have been used only for the refferal of same random domain name appears again, probability of which is negligible. However, according to Paul, most implementations are broken, upgrading of which is as time consuming as upgrading implementations to use modified protocol with, say, effectively 64 bit ID. A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Can you demonstrate it with existing implementations? Masataka Ohta PS Birtyday attacks can, seemingly, be protected against if outstanding query is invalidated (query fails) upon a reception of partially matching (query and server address but not ID matches) answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
Mark Andrews wrote: DO says that you *understand* DNSSEC and that it is ok to send a DNSSEC response. It does not mean that you will be validating the response. named in all production versions of BIND 9 (9.1.0 onwards) has set DO on all EDNS queries. BIND 9.1.1 onwards named copies DO to the response. Caching servers not validating the response? Then, the following argument applies. If a caching server is not required to perform public key computation to verify RRs before caching, cache poisoning won't be detected by the caching server, average clients of which suffer from long lasting DOS of DNSSEC verification failure, turn off DNSSEC and will be a victim of another poisoning on their own cache. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 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] A different question
* Masataka Ohta: Caching servers not validating the response? Yes, this is still a widely-held view. To be honest, I don't think it makes much sense. We need DNSSEC right now, not at some unknown future date when operating system vendors have shipped security-aware, validating stub resolvers for a while, so that there is finally a client population which supports end-to-end DNSSEC. What's worse, end-to-end DNSSEC support for mobile devices (which move from networks with resolvers which support end-to-end DNSSEC to networks which don't) is a completely unsolved problem. We are basically at stage 0: denial that the problem exists. Not good at all. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
Florian Weimer wrote: Anyway, the other problem of DNSSEC is that PKI, as a concept, is fundamentally broken, against which no PKI protocol can be useful. I think we need to recast DNSSEC as mere transport protection measure. It might be a overengineered for this purpose, but DNSSEC is too overengineered and, thus, complex to be a reliable protection. I doubt that a simpler, more lightweight protocol could be deployed with less effort. Isn't port randomization enough? If not, DNS over TCP is no more difficult to deploy than DNSSEC. I think I can understand your pains. With hindsight, the original IPv6 design (Simple Internet Protocol) turned out to be superior to the current spec, too. My understanding is that, though IPv6 is more complex than SIP, neither really addresses the issue of routing table explosion that they are equally bad. So, I'm recently working on a protocol named IP--, which is carefully desinged to enable automatic renumbering of not only customers but also ISPs, which is an essential part to solve routing table explosion. It 's not fair, but unfortunately, it doesn't matter. 8-( It doesn't matter, because we keep using PODS and IPv4. DNS in a new generation network will use 64 bit IDs. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Aug 20, 2008, at 6:16 AM, Masataka Ohta wrote: Unlike me, you have no implementation expertise. Um. Right. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Paul Vixie wrote: that depends on the problem statement, really. if the problem statement is how can we secure hop-by-hop then there are other solutions on the table right now besides DNSSEC. Wrong. PKI, including DNSSEC, does require hop-by-hop security between CAs, which is no different from hop-by-hop security between ISPs. Note that, at least in Japan, both ISPs and CAs are leagally required to be secure, which has nothing to do with cryptographic security. my chosen problem statement is how can we secure end-to-end And the answer is by sharing security information directly by both ends, which is not the case with PKI where security information is shared (or confirmed) hop-by-hop through multiple third party CAs. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, Aug 19, 2008 at 11:15:12PM -0400, Dean Anderson wrote: I don't know if anyone noticed, but in fact, according to RFC4035 the delegation records and the glue records are not signed. A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Please outline exactly how you think this will work. I just re-read section 5 of RFC 4035, and I can't see how it can, assuming you do in fact have a set of valid trust anchors for some superordinate zone to the victim domain. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
David Conrad wrote: So far, I have seen what appears to be a lot of FUD from Masataka and the usual concerns/complaints about DNSSEC from folks who haven't implemented it in their products or services. Unlike me, you have no implementation expertise. I did implement server code for my proposal of Simple Secure DNS more than 10 years ago to confirm that, unlike DNSSEC, it can be implemented easily. From the beginning, I knew it is essentially (except to support read/write new RR types from/to zone file) less than 100 lines of modification to BIND and it actually was so. As a lazy implementor, I can design protocols to avoid useless implementation efforts. As a faithful protocol designer, I implement my design to confirm it actually require little implementation efforts. At that time, because of fundamental complexity, there was no DNSSEC implementation. Thus, I am the implementer who can authoritatively declare that all the impelementors and system administrators of DNSSEC do not understand both of DNS and PKI and are brain dead. I, of course, won't bother to implement proven-to-be-fundamentally- broken DNSSEC nor join proven-to-be-useless attempts to improve the proven-to-be-fundamentally-broken protocol. Anyway, the other problem of DNSSEC is that PKI, as a concept, is fundamentally broken, against which no PKI protocol can be useful. Masataka Ohta The current DNSSEC essentially matches Simple Secure DNS. NSEC + RRSIG(NSEC) = ZL RSIG(type) = RRD + NSIG DNSKEY = ZA RRSIG(DS) = ZSIG DS = RDD(ZA) The trust model is the same as Simple Secure DNS. The threat model is the same as Simple Secure DNS. ZL has the same issues as NSEC has. KSK/ZSK maps directly into this from Simple Secure DNS. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. DNSKEY uses public keys which you recommended. The signature can be verified by sharing secret information between related parties or by using private/public key technology. RRSIG = TYPE + 32768 would have been better than how we actually did it in RFC 4035. While things are encoded slightly differently RFC 4035 is a implementation of Simple Secure DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
... let's deprecate these bit patterns altogether for OP=QUERY: QTYPE=255 Breaks some sendmail versions and qmail. i once hacked sendmail internals, and what i remember is that it would try a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the hopeful assumption that they had the same domain name. an earlier version had a bug whereby it didn't know ANY was hop-by-hop even in the presence of RD=1, so a partial answer of A alone was taken to mean there was no MX, but this was fixed before my son (who is now 17) was born. no version i know of will fail to make an explicit MX query if ANY comes up dry, or fail to make follow-on A queries if ANY comes up without an A. so, can you explain what you mean by breaks, both for sendmail and qmail? QCLASS=255 QCLASS != IN seems more reasonable to me. i don't think we should foreclose the possibility that QCLASS != IN will be useful to somebody some day. do you know a specific risk for QCLASS != IN? RA=1 AND RD=0 By the responder or the initiator? nonrecursive queries of recursive servers are a useful diagnostic but also an information leak that can help an attacker shape their flows. peter koch has reminded me that a server that's both authoritative and recursive would not be able to answer wearing its authoritative hat if this were literally enforced, and while i think there should be no server wearing both a recursive hat and an authoritative hat, i don't think we should legislate against it in this proposal. so we can't literally outlaw a bit pattern, but we can say, if RD=0 then no non-authority data should be returned. and let's also make explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. I strongly oppose this approach. Unsolicited TCP has its place. are you strongly in favour of amending RFC 1035 4.2.2 to say that responders initiate close, or that timeouts of less than two minutes are allowed? this is the one of the least scalable and most vulnerable elements in all of DNS. with rich stevens gone and nobody to complete or champion T/TCP, we're left with several bad multipacket protocols including IP fragmentation and TCP for handling data larger than the MTU. i don't know how to make TCP scale for this, it's not like TCP/80 where server operators who want to handle a million simultaneous queries know that they'll need a lot of silicon+power to do it. did RDP (RFC 908, RFC 1151) ever achieve critical mass? -- 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] deprecating dangerous bit patterns and non-TC non-AXFR
i answered this on namedroppers, where the thread actually belongs. -- 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] A different question
Florian Weimer wrote: Caching servers not validating the response? Yes, this is still a widely-held view. To be honest, I don't think it makes much sense. We need DNSSEC right now, not at some unknown future date when operating system vendors have shipped security-aware, validating stub resolvers for a while, so that there is finally a client population which supports end-to-end DNSSEC. Fortunately enough, we don't need DNSSEC at all. What's worse, end-to-end DNSSEC support for mobile devices (which move from networks with resolvers which support end-to-end DNSSEC to networks which don't) is a completely unsolved problem. We are basically at stage 0: denial that the problem exists. Not good at all. What's wrong with resolvers on mobile hosts? I'm afraid you are assuming roaming over private IP networks without end-to-end visibility, which is often the case with 3GPP, which is not a problem of the Internet. BTW, DNS is definitely not end-to-end, because it relies on intelligent intermediate eitities of name servers. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
At 5:36 PM +0200 8/20/08, Florian Weimer wrote: * Masataka Ohta: Now, I'm saying, for these 10 years, that PKI, including DNSSEC, is broken. Can't you simply believe me? No, because DNSSEC, as it will be deployed, is not a PKI. Masataka is right that PKI as it is widely used (PKIX) is broken. Florian is right that DNSSEC as it stands today is not PKI. The trust model in DNSSEC is completely parallel to the data model. In the PKIX world, it is bolted on to the side in a way that often surprises users. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David Ulevitch wrote: Paul Vixie wrote: no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. Too many pronouns... DNSSEC provides the ability to determine that a given authoritative answer is signed (by DS on the delegation from the parent), and provides cryptographic signatures on such authoritative answers. The signatures can be chased up to a configured trust anchor, ideally a signed root. And without any private key in that chain of trust, he can't change signed authoritative data without causing validation to fail. With apologies to Meat Loaf: A Man in the middle can bedevil your wits, He can fiddle with packets, he can twiddle the bits, He can easily spoof your sequence numbers and such, But he can't spoof sigs, No he can't do that. Oh, no, No, he can't do that. -- Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David, On Aug 20, 2008, at 10:30 AM, David Ulevitch wrote: Paul Vixie wrote: no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. Yep. Question is, how many opportunities do you want to provide for MITM attacks? DNSSEC will not stop that. The full DNS lookup path is almost always different than the data content path. As such, it introduces a new MITM attack vector (and a particularly effective one at that as Kaminsky described). DNSSEC is intended to protect against that attack vector and does so albeit at some cost in terms of complexity of software and operations. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. please explain how i can get undetectably bad data in a dnssec environment, where bad means did not come from the zone editor. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
In your previous mail you wrote: So please consider other options before repeating the holy mantra 'DNSSEC is the only solution'. = it is not a mantra but the reality: - transaction protection is not enough if we want to keep caching in the middle (the argument is it has to be a perfect protection to be efficient, a single hole somewhere can corrupt an unbound amount of clients) - data protection is the solution - the right granularity is the RRset because coarser (name for instance) is inefficient and finer (RR) is prone to specific DoS attacks - the needed protection is origin and integrity, this calls for a signature system So the complete solution for the cache poisoning issue is to sign RRsets. You can specify something new from zero but it shall look very similar to DNSSEC... Regards [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
In your previous mail you wrote: Yes. I've just been told by a fairly authoritative source that BIND 9.5.1 (at least) sets the DO bit on by default, regardless of whether DNSSEC is configured. This would explain the high number of queries coming in with DO set. = as you know the DO bit means DNSSEC RRs are accepted, so an implementation which supports them should set the DO bit. The implication of this implementation decision is that if the root is signed, folks using BIND 9.5.1 (at least) will be requesting DNSSEC = s/requesting/accepting/ regardless of whether the caching server operator has configured DNSSEC or is prepared to handle a DNSSEC-related response. = I agree only for the second (is prepared to handle). Note this is bound to EDNS0, without it no DO, IPv6, size negotiation, etc. P.S. Seems I need to revise 3225... = this was the intented side effect of 3225 so if you change you mind you know what to do (-:). Regards [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
Francis, On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote: as you know the DO bit means DNSSEC RRs are accepted, so an implementation which supports them should set the DO bit. Mumble. So, DO=1 by default will result in DNSSEC-related RRs being returned, regardless of whether those RRs will actually be used. What my intent was with 3225 is no longer particularly relevant since shipping code has been doing this for quite some time. The implication of this is that the day the root gets signed, the root servers will be responding with DNSSEC-related RRs, regardless of whether caching servers intend on doing anything with them. This raises a few potential operational issues: - if the advertised EDNS0 buffer size is not large enough, it will trigger truncation and, as a result, an increase in the number of TCP sessions going to the root. - if the advertised EDNS0 buffer size is large enough, but the network MTU is too small, fragmentation will occur which may cause the response to be dropped (for a variety of reasons). - if there are middle boxes in the way that do stupid things (e.g., disallow DNS over TCP), those middle boxes will likely drop the larger responses. The concern I see (that I had hoped would be avoided by DO being set to 1 only when the caching server administrator had explicitly configured DNSSEC awareness) is that folks who are blissfully unaware of the root being signed would, through no fault or action on their part, could begin to see odd DNS failures due to one of the three issues I mention above. In any event, I have an answer to my question... Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
In your previous mail you wrote: nobody to complete or champion T/TCP = it seems T/TCP is dead because of some security issues. In another thread about fragmentation (vs firewalls) someone proposed DCCP. At least, it avoids RFC 1035 4.2.2 (:-)! [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
Florian Weimer wrote: Caching servers not validating the response? Yes, this is still a widely-held view. To be honest, I don't think it makes much sense. We need DNSSEC right now, not at some unknown future date when operating system vendors have shipped security-aware, validating stub resolvers for a while, so that there is finally a client population which supports end-to-end DNSSEC. Fortunately enough, we don't need DNSSEC at all. What's worse, end-to-end DNSSEC support for mobile devices (which move from networks with resolvers which support end-to-end DNSSEC to networks which don't) is a completely unsolved problem. We are basically at stage 0: denial that the problem exists. Not good at all. What's wrong with resolvers on mobile hosts? I'm afraid you are assuming roaming over private IP networks without end-to-end visibility, which is often the case with 3GPP, which is not a problem of the Internet. BTW, DNS is definitely not end-to-end, because it relies on intelligent intermediate eitities of name servers. Actually it doesn't. It can be configured that way but there is no requirement to actually use a caching nameserver. Authoritative nameserver to iterative client works. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
Mark Andrews wrote: Because DNS is not end to end, DNSSEC is not secure end to end. Root, TLD and other zones between you and a zone of your peer are the targets of MitM attacks on DNSSEC. Which can be removed if needed by exchanging trust anchors with peers. You can't. To exchange the trust anchors, you need cryptographically secure end to end security, which is not provided by DNSSEC. If you and your peer already have secure channel, you have no reason to use DNSSEC for secure identification nor communication with the peer. Anything other that one-to-one exchange of secrets/public keys involves some trust in the introducer is doing the right thing. As the level of security is no different from PODS, it is the worst thing to bother to exchange public keys. If you have a solution that scales I'd love to hear it. Because DNS is not end to end, DNS does not really scale, manifestation of which is load on root servers. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
On Aug 20, 2008, at 6:57 PM, Masataka Ohta wrote: If you and your peer already have secure channel, you have no reason to use DNSSEC for secure identification nor communication with the peer. Ohta-san, this is clueless in so many ways. It's inspiring. First of all, perhaps you do have a secure channel to your trust anchor. This doesn't mean that you have a secure channel to all the zones that depend from it. So you can get the trust anchor key, and because you have it, you can now validate all those zones for which you have no such secure channel. Secondly, secure channels can be automatic or manual. Frequently they're manual. So you use the manual channel to set up an automatic channel. This is what, e.g., the PGP key signing that happens at every IETF is all about. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
On Aug 20, 2008, at 6:56 PM, Mark Andrews wrote: DO is not controlled by dnssec-enable or dnssec-validation. DNSSEC is designed to be validator to authoritative server. If you introduce caches then you need to ensure that your cache is doing something sensible. This implies you need to control your cache. So I guess the question is, do the versions of BIND that set DO have problems when they get big answers. No. They advertise what they are capable of accepting. If there is broken middlewhere in between that clobbers the response they retry. [EMAIL PROTECTED] - [EMAIL PROTECTED] - plain DNS If they don't, we should be okay, since (correct me if I'm wrong, Mark), they will not send those answers out in response to queries that don't have the DO bit set. The server side honours the clients DO requests. However, that's a pretty big if. Do we have any data one way or the other? How about years of operation (going back to 9.1.0) without people even noticing that DO is set. If DO caused non recoverable problems we would have seen them long before now. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
On Aug 20, 2008, at 7:32 PM, Mark Andrews wrote: How about years of operation (going back to 9.1.0) without people even noticing that DO is set. If DO caused non recoverable problems we would have seen them long before now. It would be helpful to have some hard data. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
