Re: [Asrg] DNSSEC is NOT secure end to end
Andrew Sullivan wrote: >>>With DNSSEC, a security aware resolver will want to check the signature. >>Except for glue A. > That's not a vector for attack. Glue is the vector for most, if not all, attacks including Kaminsky's and DNSSEC with forged certificates. > If you are validating data, why would > you not follow the chain to the glue record (secured on each side of > _that_ cut by the DS/DNSKEY pairs) and validate the signature on the > authoritative data you get? Following the chain over a forged certificate to confirm forged data have valid signatures? Or, what if the glue is inside a grand child zone on which no nameservers are responding? When DNSSEC was designed, I pointed out several detailed but fatal problems including that glue can not be secured. The WG had a different fantasy. The WG wasted about 10 years for experimental deployment only to confirm that I have been perfectly correct and the protocol was modified. So, you don't have to waste yet another 10 years only to reconfirm it. Just accept the current DNSSEC protocol: >>>With DNSSEC, a security aware resolver will want to check the signature. >>Except for glue A. which makes DNSSEC as insecure as plain old DNS. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Wed, Jun 10, 2009 at 09:18:22AM +0900, Masataka Ohta wrote: > > With DNSSEC, a security aware resolver will want to check the signature. > > Except for glue A. That's not a vector for attack. Glue records from the parent side of the cut are not authoritative data in the parent zone, because the zone in question has been delegated away. They're only to be used to stick the two sides of the cut together. (Indeed, treating the parent-source glue data as authoritative and reusing it as answer data is in fact a source of poison attacks, as you have quite cogently pointed out more than once.) If you are validating data, why would you not follow the chain to the glue record (secured on each side of _that_ cut by the DS/DNSKEY pairs) and validate the signature on the authoritative data you get? You'll get a signature over the A record from the child server, and that signature will either pass or fail validation according to the same rules as before. (Glue records on the child side do, of course, come with RRSIGs which can be validated just like anything else.) I think people have already heard enough from me on this topic, so I won't post on it any more. But if you have a real attack that actually works against DNSSEC in the cases you keep insisting it does, please show it. Otherwise, please stop insisting DNSSEC is broken. You haven't shown that it is, and you seem to be making no effort to provide such a demonstration. There's no question that DNSSEC is complicated, and that it provides a whole new pile of ways for zone administrators to screw things up: new features provide a new opportunity for mistakes. But that's nowise a proof that DNSSEC itself does not do what it says it does. Best regards, Andrew -- Andrew Sullivan [email protected] Shinkuro, Inc. ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: >>The provision is through hops of certificate authorities, > As I clearly stated, As we are discussing on concepts described in two papers, your own statement without proper quotation from the papers does not mean anything. > the actual signing is end to end, The security hole is located not between certificate authorities but within certificate authorities. To quote from the 2001 paper, Transactions based on a wellknown public key can be rather simple two-party interactions that fit well within the end to end paradigm. However, there is a key role for a third party, which is to issue a Public Key Certificate and manage the stock of such certificates; such parties are called certificate authorities. the first sentence roughly corresponds to your statement "the actual signing is end to end", however... And the third parties of certificate authorities constitute a chain, a channel, hops or whatever terminology you might use, which is not end to end. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: >>As has been discussed in the thread, DNSSEC is NOT a protection >>against cache poisoning, because caches poisoned with forged >>certificate breaks the security. > I think you need to explain how this happens in detail. In detail??? See below. > With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: > > This origin authentication and integrity is precisely what is > required > > to avoid the DNS cache poisoning which is the kind of vulnerability > > which prompted this discussion. > > As has been discussed in the thread, DNSSEC is NOT a protection > against cache poisoning, because caches poisoned with forged > certificate breaks the security. > I think you need to explain how this happens in detail. For instance, an attacker wishes to poison the cache of some ISP's DNS server for 'example.com.". Currently, it gets the server to request information about example.com from its authoritative server, and sends information that purports to be from that server. It needs to guess some properties of the original request, but there have been and are various features of DNS servers which make this easier than you might think. Without DNSSEC, the attacked DNS resolver simply accepts the information. With DNSSEC, a security aware resolver will want to check the signature. The information is only accepted if the signature checks out, and the key is trusted. If the key is a trust anchor, then the check is complete. If not, then the resolver needs to get the DS RR for example.com from com's DNS server. This information is itself signed with com's signing key. So, it will not accept that unless it verifies. If com's signing key is not a trust anchor, then it will get com's DS RR from the root. Also signed by root, and the root key is probably a trust anchor. If any of this information is not available, or is not signed, then the trust chain is not present, and the original information is not accepted by the security aware resolver. So, perhaps you can explain how an attacker can get a security aware resolver to accept information which will subvert this? I think you have proposed that an attacker might explicitly subvert the chain. In this case it would involve getting the com DNS server to accept a DS RR for example.com. This is altogether harder problem for the attacker, and is of a significantly different character than cache poisoning, as it involves actual changes to the DNS servers, rather than just persuading resolvers to accept incorrect information. But, perhaps this mechanism would better be reported to people other than the asrg. ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: > > DNSSEC provides two things. Firstly, it provides the means to > digitally > > sign RRsets. This provides data origin authentication and data > > integrity. > > The provision is through hops of certificate authorities, As I clearly stated, the actual signing is end to end, and if the receiver has chosen to trust the explicit key used to sign, there is no involvement of PKI. The presence of a valid digital signature is good evidence that the data originated in that form from the owner of the private key corresponding to the public key used for verification. > which is what is discussed in latter paper of David Clark published in > 2001. Read it. I have, and I cannot find any explicit sentence which uses the phrase "hops of certificate authorities". Nor can I find any statement which states anything to the effect "PKI is not end to end and is therefore bad". If these are present, please point them out. He does state "Each interaction is nominally ... but its robustness depends on the larger context composed of the whole sequence." It does state, in effect, "PKI is difficult" (particularly because of the revocation problem) but that is well known. But it also gives me the impression that it says that this kind of thing is necessary, because of the trust issue on the modern Internet. I'm not sure of the reason for your insisting that DNSSEC is not end to end. I must apologise to the Asrg list for continuing this discussion, which seems to have just gone down a pointless semantic hole. ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
Hi, [ASRG removed, since I cannot see even a little bit how this is on-topic there. But if you think it is, feel free to republish this as you like.] On Tue, Jun 09, 2009 at 08:54:48AM +0900, Masataka Ohta wrote: > As has been discussed in the thread, DNSSEC is NOT a protection > against cache poisoning, because caches poisoned with forged > certificate breaks the security. To beat the stain on the ground that betokens the long-since-passed equine presence, you haven't answered the question, posed to you several times, how this poison-with-forged-certificate is supposed to work. If I have a validating resolver, and I get data from a poisoned cache, then I attempt to validate the signature over that data, checking the chain of signatures from that data all the way back to some trust anchor I have configured. Therefore, in order to poison a cache with a forged certificate, one of two things has to have happened: 1. The forger managed to forge keys and inject them in the poisoned cache such that one of those keys will be valid according to the trust anchor I have installed. Is this the threat you claim? If so, and assuming you're not saying that the crypto is weak (in which case we have way bigger problems than forged DNS data), that just seems to be a claim that the signing procedures can be subverted. And yes, of course, a security system is possibly subverted by poor operation. I'm not sure what the surprise is supposed to be here. You can argue just as easily that the DNS is badly secured because it's possible to convince a registrar to publish the wrong data for a domain (a problem we've certainly seen in action more than once). It is indeed possible to get bad data into the system, and DNSSEC doesn't completely protect against such bad data coming in; but that is no criticism of DNSSEC. 2. The forger managed to forge data that is not validatable in a chain from any trust anchor I have, and managed to convince me to trust it anyway. If this is the threat you claim, I want to know how this works. If you're right, then DNSSEC is indeed completely broken. We need to know that now, before more deployment goes on. If neither of (1) or (2) happens, then my attempt to validate the data will fail, marking the data bogus. It is true that this is a vector for denial of service: I won't connect to a site with invalid DNS data. I'm having a hard time coming up with a reason why that is worse than "I go to the site controlled by Dr Evil." Best regards, Andrew -- Andrew Sullivan [email protected] Shinkuro, Inc. ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
RISC is end to end (was Re: [Asrg] DNSSEC is NOT secure end to end)
David Wilson wrote: >>As you say "IN NETWORKING", I'm afraid you haven't read his original >>paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system >>design" in general and not necessarily "in networking". For example, >>in the original paper, RISC (Reduced Instruction Set Computer) is >>given as an example of end to end design. > Er, no. The article states: The paper states: any attempt by the computer designer to anticipate the client's requirements for an esoteric feature will probably miss the target slightly and the client will end up reimplementing that feature anyway which is an end to end argument where communication is at high level between computer designers and their clients. > It is clear from both of these that the basic subject is data > communication over a communication system. That is true only with the widest meaning of "communication". However, "IN NETWORKING" by Phillip has a lot narrow meaning and even the original paper says: A version of the end-to-end argument in a non-communication application was developed in the 1950's by system analysts whose responsibility included reading and writing files on large numbers of magnetic tape reels. > So, applying this to DNSSEC's PKI, this is clearly an application layer If you want to draw some conclusion from the 2001 paper, quote text from the paper. There is no point to reiterate it with your subtly modified terminology only to give a subtly modified impression on the content of the paper. > The second article is a discussion about how the end-to-end design > principle might need to be modified in the light of the realities of the > modern Internet. That is an explanation on the motivation to write the paper and the conclusion of the paper is: We argue that the open, general nature of the Net, which derived from the end to end arguments, is a valuable characteristic that encourages innovation, and this flexibility should be preserved. which means the end to end argument is not modified. Instead, the paper, for example, says for regulations to be realistic, they should follow the end to end principle. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: >>According to the terminology of David Clark, PKI including DNSSEC >>is not secure end to end. > DNSSEC provides two things. Firstly, it provides the means to digitally > sign RRsets. This provides data origin authentication and data > integrity. The provision is through hops of certificate authorities, which is what is discussed in latter paper of David Clark published in 2001. Read it. > As this operates at the DNS application layer, this is > clearly "end to end" within David Clark's terminology. It does not rely > on any security services in the lower communication layers (in the way > that, for instance, relying on TCP would). If you read the paper, you can find the lower layer of PKI consists of communication with or between certificate authorities. Compromising a certificate authority in the lower communication layer breaks the security of data origin authentication and data integrity. > This origin authentication and integrity is precisely what is required > to avoid the DNS cache poisoning which is the kind of vulnerability > which prompted this discussion. As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. > This aspect of DNSSEC does not require the use of any PKI. Read the 2001 paper on why PKI not end to end and why DNSSEC no exception. The paper explains why scale breaks the end to end property. > I get the impression from you that DNSSEC is to be disregarded because > it is not "end to end". Being "end to end" has practical advantages. See above on how useless DNSSEC is to avoid cache poisoning, which was the motivation to deploy it. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Mon, 2009-06-08 at 14:22 +0900, Masataka Ohta wrote: > As you say "IN NETWORKING", I'm afraid you haven't read his original > paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN", which is on "system > design" in general and not necessarily "in networking". For example, > in the original paper, RISC (Reduced Instruction Set Computer) is > given as an example of end to end design. Er, no. The article states: "The arguments that are used in support of reduced instruction set computer (RISC) architecture are similar to end-to-end arguments." I.e. the arguments for end to end are similar to the arguments for RISC. This is not the same as saying that RISC is an example of end to end design. > Both of the papers are freely downloadable. > > The original paper: > > http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > > The paper in 2001: > > http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf > > You should have read both of them to make the dinner more valuable. > [Interesting articles, which took me back to discussions 20 years ago as regards connectionless vs. connection oriented networks.] It is clear from both of these that the basic subject is data communication over a communication system. Thus the second article quotes from the first article thus: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communications system. Therefore, providing that questioned function as a feature of the communications systems itself is not possible." So the basic object under consideration here is a "communication system". It is clear from the first article that what is envisaged is a layered model, (c.f. the conclusion). I would not be surprised if this kind of thinking was input to the development of the OSI model for data communications, which does set out to assign to each layer an appropriate function. The basic thesis of the article is that functions concerned with, for instance, security and reliability are best done in the upper layers, even the top (application) layer, as the application cannot rely entirely on the lower layers to "do their stuff". Thus "end to end" is about communication from one application layer to the peer application layer down through the layers at one system, and then up through the layers at the other system. So, I would paraphrase the "end to end design principle" as the "application to application" design principle. I note that in models like the OSI model, only the lowest layer have intermediate systems. (That's why layer 3 is called the network layer). The article in no way implies that it is the existence of intermediate systems which is the deciding factor in the design. "End to end" is not in contrast to "hop by hop". So, applying this to DNSSEC's PKI, this is clearly an application layer security system. The system does not depend upon the security or reliability of any lower layers (or, indeed, intermediate systems). So, it would seem to fit the "end to end design" of this article. The second article is a discussion about how the end-to-end design principle might need to be modified in the light of the realities of the modern Internet. In the present context of DNSSEC, the discussion of trust is important. best regards David ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote: > David Wilson wrote: > > > However, I think there is some difference in the way people are using > > some terms. > > According to the terminology of David Clark, PKI including DNSSEC > is not secure end to end. DNSSEC provides two things. Firstly, it provides the means to digitally sign RRsets. This provides data origin authentication and data integrity. As this operates at the DNS application layer, this is clearly "end to end" within David Clark's terminology. It does not rely on any security services in the lower communication layers (in the way that, for instance, relying on TCP would). This origin authentication and integrity is precisely what is required to avoid the DNS cache poisoning which is the kind of vulnerability which prompted this discussion. This aspect of DNSSEC does not require the use of any PKI. A security aware resolver can obtain by some out-of-band means the public signing key for some "island of security", and choose to trust that key. However, such bilateral arrangements do not scale to the Internet. So, DNSSEC provides a means for an Authentication Chain, to use the specific DNSSEC term. A signed zone can authenticate the key of a child zone. There is a chain here. However, it is of a significantly different character to a communication network. Whether it is "end to end" or not, is for a different discussion. > > > "End-to-end" security means that the security of that data item does not > > depend on the trustworthiness of any intermediate node, or channel. > > According to the terminology of David Clark, certificate authorities > are intermediate nodes. > > If you have different terminology, use it outside of the Internet > community but not within. I get the impression from you that DNSSEC is to be disregarded because it is not "end to end". However, the opinion of "the Internet community" as regards DNSSEC has been made clear in the last few days, given these announcements: http://www.nist.gov/public_affairs/releases/dnssec_060309.html http://pir.org/index.php?db=content/Website&tbl=ORG_Advantage&id=2 http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn If the Internet community agrees with you that DNSSEC is not "end to end", then this does not seem to divert them from implementing it. best regards David ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: > However, I think there is some difference in the way people are using > some terms. According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. > "End-to-end" security means that the security of that data item does not > depend on the trustworthiness of any intermediate node, or channel. According to the terminology of David Clark, certificate authorities are intermediate nodes. If you have different terminology, use it outside of the Internet community but not within. Masataka Ohta ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote: > Yes, security of DNSSEC is totally hop by hop. I am nervous of adding to this debate (and should it really be on ASRG?) However, I think there is some difference in the way people are using some terms. My understanding of the terms hop-by-hop and end-to-end is this: A data item traverses a number of nodes within a network. (E.g. a UDP datagram moving through an inter-network, or a Email message from its submitting UA via a sequence of MTAs to the recipient's UA). "End-to-end" security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. "Hop-by-hop" security means that you do rely on the trustworthiness of the intermediate nodes and channels. (E.g. CRC provides no defence against deliberate tampering, TLS for email is only as trustworthy as the least trusted intermediate MTA). PKI establishes a "chain of trust" between the signing certificate (i.e. the certificate containing the public key corresponding to the private key used to generate the signature) and your trust anchors (which you choose). This is not really "hop-by-hop" as data is not hopping. Like a real chain, it is only as strong as its weakest link. However, the chain operates in a different 'space' from that used to transfer the data being protected. As far as I understand, the key thing which DNSSEC gives you is data origin authentication (although that by itself without data integrity would be useless). The DNS attacks which were the start of the discussion are all based on the attacker sending false data to the system under attack. Having an effective means for determining from whom data comes is necessary to overcome this kind of attack. best regards David Wilson ___ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
