Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Mark Andrews wrote: Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. I'm afraid DNSSEC people have been arguing against SCTP saying DNSSEC is good enough. Worse, though I have been warning for these 15 years that cached glue may be used only for glue with same refferal, a broken concept of bailiwick was introduced only to enable so called Kaminsky attack. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Protection of DNSSEC at the registy level is equivalent to protection against lifting tiles. Not practical at all. Locking the doors and windows stops most attacks however. Then, let's lock the doors and windows first, before working on DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. If an attacker can get its bogus data into the referring zone, who cares whether it's NS data or DS data? One of the important things we are trying to add with DNSSEC is some means of assuring ourselves that the referral we got was the one that comes from the actual authority for that referall, rather than some other agent spoofing the response. DNSSEC appears to provide that assurance, and so far you have provded not one jot of evidence that it does not. I fail completely to see how it is easier to put the wrong DS record in the parent than it is to inject bad NS data in there. If you can put illegitimate data in, there are two possibilities: 1. You put it in via some legitimized mechanism (e.g. via SQL injection, you manage to get data that wasn't intended to be in the zone into the zone). This causes that illegitimate data to be treated as legitimate, and probably signed and such. This is a bad attack, of course, but it is available today. This is no different than being able to plant some evil file on the corporate file server inside the VPN: the security is breached not by failure of its mechanisms, but by failure of authentication. DNSSEC doesn't solve this, I agree; that's because the _provisioning_ of data is beyond the scope of the DNS protocol itself. In any case, surely a more effective attack in this case is to get phony NS or A data (or whatever) into the zone than to put phony DS data. The latter will get you at best a DoS, whereas the former allows you to take control of the target zone. 2. You put it in via some illegitimate mechanism (e.g. by intercepting the wire transmission and adding the data to the stream). Unless the keys are somehow compromised, this vulnerability is exactly what DNSSEC aims to stop. I don't see any argument from you that this DNSSEC capability is not effective. If you have such an argument, it'd be nice to hear it before we continue with the efforts at deployment. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a285750.9010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Locking the doors and windows stops most attacks however. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Mark Andrews wrote: A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. Zone administration involves multiple operations. Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. I guess what Masataka was referring to is a different source of variance, i.e. an impersonation of JPNIC's authority over its domain of control (using a compromised JPNIC's private key). All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. Reliable through a chain fo digital signatures. Reliable to the extent an impersonation attack (on the locus of control) does not occur based on a compromised private signature key. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. Then you reduce the chain of digital signatures to a single one, raising confidence level at the cost of more key management hindrance. Indeed, this thread seems to be another attempt to understand the basic DNSSEC properties. - Thierry --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. Then, it is legitimate to appraise the overall confidence in the DNSSEC chain of signatures, and to pinpoint the weakest link (e.g. the zone manager having the greatest likelihood of lousy private key protection in place). Indeed, DNS+DNSSEC is no different from plain DNS for those who are satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some uses, it is useful to understand DNSSEC chains of digital signatures. Accesssorily, the zones above you means nothing to a relying party that is not validating its own domain. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organization. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a25b8ef.70...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. There is no scalable way to avoid that trust issue. We don't have to trust the router adminstration or caching server administration or authoritative server adminstration. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organizati on. I've been on plenty of LAN's which I would treat as hostile. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Which is not a arguement for not doing DNSSEC. Knowing where the risks are is how you do risk management. If you arn't willing to accept some risks then don't connect to the net. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022034140.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. Mark Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022057560.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul If you are bribing personel you need to assume they can do anything the orginisation they work for can do. HSM's don't help in this case. HSM's have their place but you need to understand the limitations of the devices. HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
At 09:09 PM 6/2/2009, Mark Andrews wrote: HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. It depends on the HSM. For example, there are HSMs that allow you to program just about any policy you want - including the requirement to have at least N people agree that something needs to be signed. The size of N is chosen to balance need for accountability with that of usefulness. I.e. requiring 20 people to turn the keys to get something signed is probably not useful. Permitting 1 person to sign without further oversight is probably not enough accountability. So saying they don't add much more security is really a statement that might be correct under really bad management practices, but mostly isn't. For example, even a simple version of keeping the set of HSM PIN holders distinct from set of people allowed to physically access the HSM for signing provides a substantial amount of operational security. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
