Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, Nov 27, 2008 at 07:49:13PM +, Matthew Ford [EMAIL PROTECTED] wrote a message of 13 lines which said: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. That would prove nothing: failures will DNSSEC do not happen every day. Signatures expire, people stop signing without telling the parent zone, keys rolls over, but it may not happen during these few days. You see the actual problems with DNSSEC (which are *not* FUD) when you run it every day, for several months. flameRead the pro-DNSSEC responses to US govermnent's survey http://www.ntia.doc.gov/dns/dnssec.html and see how many of these people who tell Obama to sign, signed themselves their zone./flame ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, Nov 27, 2008 at 03:52:50PM -0500, Steve Crocker [EMAIL PROTECTED] wrote a message of 161 lines which said: the intent is to simply include the DNSSEC-compliant recursive resolver in the standard DHCP configuration during the plenary. That is, during the plenary, DHCP responses will include the DNSSEC-compliant recursive resolver. Even though the normal DNS requests will thus go through the DNSSEC-compliant recursive resolver, the end system will see no difference unless the end system asks for a a signed response. Hold on, you mean the recursive resolver will NOT validate by default? If so, this is not an experiment, this is MUCH LESS than what many people on this list already do every day (having a recursive resolver which validates even without any specific request). % dig A futuredate-A.newzsk-ns.test.dnssec-tools.org ; DiG 9.5.0-P2 A futuredate-A.newzsk-ns.test.dnssec-tools.org ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 57934 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, Nov 27, 2008 at 03:52:50PM -0500, Steve Crocker wrote: All of the above should invisible unless the end system explicitly invokes the DNSSEC-compliant recursive resolver AND asks for a signed response. Steve for me, this statement is the crux of the issue. it is crucial for there to be signed infrastructure. no question about that. but for what purpose? as noted elsewhere in this thread, the IETF network has already implemented signed zones in the past (Dallas) and actually had an application under test (FreeSwan). for those of us who already run DNSSEC validators on our local machines, I welcome the idea of a persistent signed IETF infrastructure. (e.g. there will not be the DNSSEC compliant recursive resolver... there will be many of them. but that is not the subject of an experiment. i beleive that some clarity would be helpful here. if the folks in charge would clearly state what the experiment is, expected outcome, how the community will be able to gauge the success or failure of the experiment, and future actions... then much of the discussion would disipate or shift. back to my question - to what purpose? if all this is invisible to the end-system, of what purpose is the exercise of creating signed data? I think that there should be some nod to end-system awareness/impact. And the primary point of visability (under the IETF control) is key roll. at least imho. others will no doubt have their own points. I look forward to more clarification on this proposed experiment. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On 28/11/08 09:44, Stephane Bortzmeyer wrote: On Thu, Nov 27, 2008 at 07:49:13PM +, Matthew Ford [EMAIL PROTECTED] wrote a message of 13 lines which said: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. That would prove nothing: failures will DNSSEC do not happen every day. Signatures expire, people stop signing without telling the parent zone, keys rolls over, but it may not happen during these few days. You see the actual problems with DNSSEC (which are *not* FUD) when you run it every day, for several months. I said it would be a milestone. I didn't say it was the end of the road. Mat ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Steve, While I very much appreciate the background, I think the fundamental point I was trying to make remains unchanged and part of your response further muddies the waters. Russ's note suggests DNS-enabled clients. There is a serious shortage of those clients for what I believe is still the most-used operating system platform among IETF participants. Your note seems to suggest concentrating on caching servers and full-service resolvers. I think there are differences in how various of us have done and interpreted the risk analysis but, from what I've seen, well-known caching servers (such as ISP ones) are the most likely targets of attacks. If they are, then having DNSSEC verification only to those servers, with client machines trusting the nearby caching servers without DNSSEC protection, provides very little protection at all. Put differently, if we cannot extend DNSSEC protection and verification to the desktop, DNSSEC provides very little marginal security advantage. As several people have pointed out, effective use of DNSSEC to the desktop requires sufficient work on APIs and UIs that an application, or the user, can distinguish between signed and validated, signed but does not validate, and unsigned. As long as verification is performed on the desktop machine (or on a completely trusted, protected, and user-controlled local-LAN caching server), it is reasonable for us to take the position that those interfaces are a problem outside the IETF's scope. But, as soon as we shift the verification problem to an external caching server --whether an IETF one or one belonging to an ISP-- and even if those are trusted, then one needs, not just APIs but actual pieces of protocol to communicate that information in an appropriate way. Without such pieces of protocol, we put the DNS into the middle of the very worst of the middlebox problem, with servers not under the user's control making decisions about whether or not particular strings are resolved or reported to the user machine as non-existent. I have not been following the DNSSEC protocol work closely enough to be sure, but my impression is that such protocol work has not even been started, much less concluded and standardized. With regard to the transparency of all of this to client machines that don't do their own validation, it rather reminds me of the distinction made in the stages of drug testing between safe and effective. Running DNSSEC-capable caching servers --whether the ietf.org zone is signed or not-- should be transparent to non-DNSSEC-aware clients unless there has been a really major failure in protocol design or implementation. That would demonstrate safe, but not effective. Perhaps that is worthwhile, but I think it is a modest goal indeed and one that has been accomplished many times already. To demonstrate effective, one not only needs signed zones (and, IMO, zones signed from the root down, not locally-configured look-aside arrangements which could prove something rather different), but also needs enough carefully-seeded failure cases to demonstrate actual protection of client machines from invalid or hostile DNS records. If one were to depend on look-aside mechanisms, then an experiment to demonstrate effectiveness (and even some aspects of safety) would need to test interoperability among look-aside databases, different sequences of testing such databases, etc. Any of those things would require very serious experimental design. Some would require protocol or other work. For example, if some zones are signed via one look-aside database, others via another, and a few with the relevant keys stored in several of them, do we need search rules for look-aside databases and are we confident that the databases themselves, and the paths to and from them, can be validated or are they just another potential attack vector? If all we have in front of us is a general proposal to turn DNSSEC on during the plenary, plus or minus your note, I think we might have the potential for a demonstration of safe, but, unlike, e.g., the IPv6 experiment, we are no where near showing effective. I'd really like to see a plan that brings us a lot closer to effective and preferably one that more strongly identifies some of the loose ends that this discussion has brought out and is used as the basis of initiating IETF work to get those loose ends tied up. john --On Thursday, 27 November, 2008 15:52 -0500 Steve Crocker [EMAIL PROTECTED] wrote: [As entertainment for the audience, I am sure everyone will enjoy seeing my brother and I take opposite sides in this discussion. Enjoy ;) ] I too have been watching this thread but from the vantage of having been deeply involved in DNSSEC deployment and, more specifically, as one of the people urging deploying DNSSEC at the IETF meetings. This thread began with Russ Housley sending a brief message yesterday: ... ___ Ietf mailing list
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Fri, Nov 28, 2008 at 10:09:16AM -0500, John C Klensin wrote: ones) are the most likely targets of attacks. If they are, then having DNSSEC verification only to those servers, with client machines trusting the nearby caching servers without DNSSEC protection, provides very little protection at all. Put differently, if we cannot extend DNSSEC protection and verification to the desktop, DNSSEC provides very little marginal security advantage. This doesn't actually follow, because there could be another way to validate the link between the end host and the validating recursive resolver. For instance, we could use TSIG between a non-validating stub resolver and a validating recursive resolver in order to ensure that attacks between those two points aren't successful. If I know I have the right node doing the validation for me, then attacks against the ISP's validating recursive resolver require complete takeover of that machine: by no means impossible, for sure, but a bigger deal than just spoofing answers to a stub resolver. That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. As several people have pointed out, effective use of DNSSEC to the desktop requires sufficient work on APIs and UIs that an application, or the user, can distinguish between signed and validated, signed but does not validate, and unsigned. Why? It seems to me that acceptable definitions of works and doesn't work in a security-aware context could include validated or insecure delegation and bogus delegation respectively. In my opinion, any plans that involve users making sensible security trade-offs due to validation failures will get us right back where we are with self-signed or expired (or both) certificates for https. It seems a perfectly good idea to me that bogus means exactly the same thing as site off the air. As a DNS geek, I'd _prefer_ more-intelligent end points with respect to the DNS. But I don't buy the argument that they're a necessary condition for DNSSEC deployment. the middlebox problem, with servers not under the user's control making decisions about whether or not particular strings are resolved or reported to the user machine as non-existent. I have not been following the DNSSEC protocol work closely enough to be sure, but my impression is that such protocol work has not even been started, much less concluded and standardized. You have exactly two options: allow the recursive server to make the decisions you seem to dislike -- and I think people who like that approach think it's a feature, not a bug -- or else to do validation out at the end nodes. The end node gets a bit to tell upstream validators that it is going to do all validation itself, and those upstream systems are required to pass along all the data necessary for such validation. So it's still possible to do everything at the end node. This is quite independent of the question of whether applications have the ability to understand the results from the validator. I agree that OS APIs seem to be missing. I'm not sure that's something the IETF ought to be solving, but I'd happily entertain arguments either way. several of them, do we need search rules for look-aside databases My personal reading of the current specifications is that, if you have at least one path to validation, then validation is supposed to work. So search rules ought not to be needed. What the implementations actually do is currently at variance with my interpretation, however. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Fri, Nov 28, 2008 at 10:58:59AM -0500, Andrew Sullivan wrote: As a DNS geek, I'd _prefer_ more-intelligent end points with respect to the DNS. But I don't buy the argument that they're a necessary condition for DNSSEC deployment. apparently you and john (and me too) do not share a common POV on what is ment by the term, DNSSEC deployment. if I may borrow some phrasing from Steve and put words in your mouth a linked suite of signed zones with the DNSKEY/DS records imbedded in the parents zones, all the way to the root zone, and or a look aside system where these records are kept constitutes DNSSEC deployment. end point visability or use of this chain of custody is immaterial to DNSSEC deployment. Is that really what you are trying to say? several of them, do we need search rules for look-aside databases My personal reading of the current specifications is that, if you have at least one path to validation, then validation is supposed to work. So search rules ought not to be needed. What the implementations actually do is currently at variance with my interpretation, however. I think the problem occurs when you have -two- paths to validation and the answers conflict. --bill A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Fri, Nov 28, 2008 at 08:58:19AM -0800, Bill Manning wrote: a linked suite of signed zones with the DNSKEY/DS records imbedded in the parents zones, all the way to the root zone, and or a look aside system where these records are kept constitutes DNSSEC deployment. end point visability or use of this chain of custody is immaterial to DNSSEC deployment. Is that really what you are trying to say? Maybe sort of. My point is that I don't think it's obviously bad if we have no DNSSEC-aware applications or if end points on the network start seeing lookup failures due to DNSSEC validation getting a bogus result, and returning SERVFAIL to the end node. In one way of looking at things, people not being able to reach a site _at all_ because it looks like there is a MiTM attack going on is a step forward. It will, however, be at least frustrating. Immaterial, however, might be going too far, for at least these reasons: 1. DNSSEC-enabled operation is somewhat more fragile than the operation to which we have become accustomed. (Note that other tricks travelling under the guise of additional forgery resilience, changing the way caches are populated, are also likely to increase that fragility.) So we'll see more failures than are actually warranted by attacks. That makes me unhappy. 2. Failures of the sort in (1) may mean that people will decide DNSSEC is too risky, and turn it off. 3. Overloading SERVFAIL as a response means debugging will be painful. It's also ugly, because it takes a response code that used to mean one thing, and makes it mean two (see other rants about overloading data types for why I hate this). The fact is, however, that we're attempting to graft some data assurances onto a distributed, loosely-cohernet database designed with extremely naive assumptions about data validity from the network. If we want that feature, and we don't want to have to wait until the entire Internet upgrades its infrastructure, we will have to live with some very unhappy compromises, while noting that if you replace all your infrastructure, you get a greater benefit. That seems to me to be the only realistic deployment strategy. And I sure think it's time we deploy our own stuff: that I couldn't get proper responses from `dig +dnssec` in Minneapolis is, I think, a serious failure of the IETF to eat its own dog food. My personal reading of the current specifications is that, if you have at least one path to validation, then validation is supposed to work. So search rules ought not to be needed. What the implementations actually do is currently at variance with my interpretation, however. I think the problem occurs when you have -two- paths to validation and the answers conflict. Right, but my _personal_ reading of the RFCs is that they are perfectly clear on how this is supposed to work. As it happens, they don't have a feature that many people seem to want. Pity that feature request didn't come in sooner, but I guess we'll have to come up with something to accommodate it. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
[As entertainment for the audience, I am sure everyone will enjoy seeing my brother and I take opposite sides in this discussion. Enjoy ;) ] I too have been watching this thread but from the vantage of having been deeply involved in DNSSEC deployment and, more specifically, as one of the people urging deploying DNSSEC at the IETF meetings. This thread began with Russ Housley sending a brief message yesterday: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? There was actually considerably more context behind this note, and it's perhaps unfortunate the thread has lurched off in a negative direction. I can't speak for the IAOC or others involved in the mechanics, so the following is my best understanding -- and also what I recommend -- of what's intended. There are three distinct elements of what's being planned. 1. Signing of the ietf.org zone 2. Providing a DNSSEC-compliant recursive resolver as part of the IETF net at the next IETF meeting. 3. An experiment during the plenary. Russ's note initiated discussion of this last piece without setting the context with the first two pieces. Let me say a few words about each piece. 1. Signing ietf.org Quite a few zones are already signed, and some top level domains, Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation. Many of us are running signed zones below the top level, and there is already a decision and commitment for the key zones related to the IETF to be signed. Based on the discussions I heard during the last IETF, the plan is to sign ietf.org immediately after the parent zone, .ORG, is signed. I would prefer for the signing of ietf.org to be independent of whether the parent zone is signed, but that's a separate discussion. In any case, it's my understanding that the people in charge of running ietf.org have been tasked with getting it signed. Once signed, I would expect it will stay in operation. That is, the timing and operation of the signed zone don't depend on the IETF meeting and have no direct relationship to the meeting's network. 2. Providing a DNSSEC-compliant recursive resolver as part of the IETF net at the next IETF meeting. The other side of the DNSSEC equation is having software that checks the signatures. This is done by a validating resolver, either a recursive resolver or the stub resolver. A handful of organizations, notably Telia in Sweden, Comcast, University of California Berkeley, and OARC are running DNSSEC-compliant recursive resolvers. I believe the ISPs, Telia and Comcast, are providing these resolvers as optional alternatives to the resolvers they regularly run and they are not including the addresses of these resolvers in the DHCP configuration parameters. Presumably they will become part of the standard DHCP configuration at some future time. The proposed action for the next IETF meeting is to do the same thing. That is, the IETF network will include a DNSSEC-compliant recursive resolver as an additional service which is not included in the list of DNS servers returned during the DHCP process. All of the above should invisible unless the end system explicitly invokes the DNSSEC-compliant recursive resolver AND asks for a signed response. 3. An experiment during the plenary I have not been involved in a discussion of this third piece, but I presume the intent is to simply include the DNSSEC-compliant recursive resolver in the standard DHCP configuration during the plenary. That is, during the plenary, DHCP responses will include the DNSSEC-compliant recursive resolver. Even though the normal DNS requests will thus go through the DNSSEC-compliant recursive resolver, the end system will see no difference unless the end system asks for a a signed response. I believe Russ was essentially asking what people think about this third piece of the plan. (Apologies, Russ, if I have incorrectly channeled you.) In line with David's note, there are indeed a lot of details to cover, including explanatory notes on how end systems need to be configured to ask for signed responses. measurements, etc., etc. All normal stuff and all part of what we are more than capable of doing all the time. Steve On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote: Peter Koch wrote: On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote: I agree with others' views that validation alone is not very helpful and some frequently queried for domains' zones should be signed as part of that experiment. By IETF74, the IANA (I)TAR might also be available as one source of TLD trust anchors. Still that date might be too early to encourage end system
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Andrew, I don't want to stretch this discussion out too much because I think the point has been made, but a few comments below. --On Friday, 28 November, 2008 10:58 -0500 Andrew Sullivan [EMAIL PROTECTED] wrote: On Fri, Nov 28, 2008 at 10:09:16AM -0500, John C Klensin wrote: ones) are the most likely targets of attacks. If they are, then having DNSSEC verification only to those servers, with client machines trusting the nearby caching servers without DNSSEC protection, provides very little protection at all. Put differently, if we cannot extend DNSSEC protection and verification to the desktop, DNSSEC provides very little marginal security advantage. This doesn't actually follow, because there could be another way to validate the link between the end host and the validating recursive resolver. For instance, we could use TSIG between a non-validating stub resolver and a validating recursive resolver in order to ensure that attacks between those two points aren't successful. If I know I have the right node doing the validation for me, then attacks against the ISP's validating recursive resolver require complete takeover of that machine: by no means impossible, for sure, but a bigger deal than just spoofing answers to a stub resolver. Sure. But I suspect that the number of systems that fully support TSIG that do not support client validation are few. I'd be happy to be proven wrong about that. One could also run the DNS queries between stub resolver and validating recursive resolver over a properly-validated and secured tunnel, but the number of those isn't huge either. We could also debate what is, and isn't difficult -- depending on network topology and operations quality, it is often much easier and more effective in practice to mount an attack against a server than against the network. That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Exactly. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. I would never go so far as to say only path to useful I'm actually a big believer, in the present environment, in LAN-local validating caching resolvers. But that is not a popular setup, especially for the residential, SOHO, and small business setups, that are often at the greatest risk. But, unless one can either take advantage of special cases or harden the servers and data paths well past current norms, I don't see the potential of DNSSEC living up to the expectations and hype unless one has end node (or at least end-network) validation. As several people have pointed out, effective use of DNSSEC to the desktop requires sufficient work on APIs and UIs that an application, or the user, can distinguish between signed and validated, signed but does not validate, and unsigned. Why? It seems to me that acceptable definitions of works and doesn't work in a security-aware context could include validated or insecure delegation and bogus delegation respectively. In my opinion, any plans that involve users making sensible security trade-offs due to validation failures will get us right back where we are with self-signed or expired (or both) certificates for https. It seems a perfectly good idea to me that bogus means exactly the same thing as site off the air. We are in agreement about end users doing security validation and decision-making. But, unless you can deploy DNSSEC, with signing of all relevant zones, on a flag day basis, the end user software needs to be able to distinguish between address validated with DNNSEC and address accepted because no signatures are present. Otherwise, one has to treat every address as equally untrusted and that is more or less equivalent to DNSSEC not being present. Whether it is appropriate to treat failed validation was equivalent to no domain or no server response is a much more subtle question, one I'm much more comfortable trying to answer with a signed root and tree than I am with lookaside. ... the middlebox problem, with servers not under the user's control making decisions about whether or not particular strings are resolved or reported to the user machine as non-existent. I have not been following the DNSSEC protocol work closely enough to be sure, but my impression is that such protocol work has not even been started, much less concluded and standardized. You have exactly two options: allow the recursive server to make the decisions you seem to dislike -- and I think people who like that approach think it's a feature, not a bug -- or else to do validation out at the end nodes. The end node gets a
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Fri, 28 Nov 2008, Andrew Sullivan wrote: That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. It's worse. Before you can start validating on your own, or use some trusted remote TSIG accessable resolver, you are likely to need to accept some spoofs to get past the hotspot authentication. Then you need prevent your browser from caching them too much (they do fastflux protection), and your own potential resolver needs to dump the answers once it has a real IP link to the real world. I don't know of any method to both allow hotspot access and fully use DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
In message [EMAIL PROTECTED], Paul Wout ers writes: On Fri, 28 Nov 2008, Andrew Sullivan wrote: That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. It's worse. Before you can start validating on your own, or use some trusted remote TSIG accessable resolver, you are likely to need to accept some spoofs to get past the hotspot authentication. Which is something the IETF should be providing / promoting a standard alternative for. At present normal protocol operations are being hijacked to do this. Browsers could then have a HOTSPOT button which just looked up this information, for example. Mark Then you need prevent your browser from caching them too much (they do fastflux protection), and your own potential resolver needs to dump the answers once it has a real IP link to the real world. I don't know of any method to both allow hotspot access and fully use DNSSEC. 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: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Sat, 29 Nov 2008, Mark Andrews wrote: It's worse. Before you can start validating on your own, or use some trusted remote TSIG accessable resolver, you are likely to need to accept some spoofs to get past the hotspot authentication. Which is something the IETF should be providing / promoting a standard alternative for. At present normal protocol operations are being hijacked to do this. Browsers could then have a HOTSPOT button which just looked up this information, for example. I'd be very interested in trying to come up with something for this within the IETF to standarize hotspot cooperation. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ I have been approached about a plenary experiment regarding Russ DNSSEC. The idea is for everyone to try using DNSSEC-enabled Russ clients during the plenary session. I like the idea. What do Russ others think? In this case, it's really not about the clients, I think. It's about making the IETF DNS servers (the recursive ones), have DNSSEC processing on. They would authenticate the answers, and discard responses which should have been signed, but were not. An appropriate set of trust anchors would need to be agreed upon, and a decision whether or not to enable DLV or not would need to be made. I will point out that (unless we close port-53 outgoing), that anyone who wants to run their own recursive name server (a requirement if you run windows and the room is IPv6 only...), or who points their /etc/resolv.conf to their own name server, will not really be affected. I do not suggest we close port 53 :-) I am in favour (and hope to be there). I would also volunteer to help set it up. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? I agree with others' views that validation alone is not very helpful and some frequently queried for domains' zones should be signed as part of that experiment. By IETF74, the IANA (I)TAR might also be available as one source of TLD trust anchors. Still that date might be too early to encourage end system validation, so adding validation and an interesting set of TAs to the meeting's recursive name servers is another option, even if on the WLAN we can't trust the path between stub and recursive resolver. However, I'd hope the limited time did not imply the proponent(s) offered a demonstration during the plenary ... Central resolvers would also provide for easy access to raw data for statistics purposes. -Peter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Peter Koch wrote: On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote: I agree with others' views that validation alone is not very helpful and some frequently queried for domains' zones should be signed as part of that experiment. By IETF74, the IANA (I)TAR might also be available as one source of TLD trust anchors. Still that date might be too early to encourage end system validation, so adding validation and an interesting set of TAs to the meeting's recursive name servers is another option, even if on the WLAN we can't trust the path between stub and recursive resolver. However, I'd hope the limited time did not imply the proponent(s) offered a demonstration during the plenary ... If I understand the thread, so far, there is a current reality that suffers from missing too many pieces of necessary DNSSec infrastructure, documentation, maybe software, and definitely training. Without all of these additional pieces, it's not reasonable to expect any sort of casual use -- even for testing. However it might be possible to put enough pieces in place to exercise some interesting scenarios. If the above is anywhere in the vicinity of correct, it would probably be helpful to formulate an actual project plan for this, complete with web-site, collaboration tools, etc. Absent something organized like this, the likelihood of producing anything useful at test-time would, apparently, be at risk. Or am I misunderstand the disparity between current reality and necessary enhancements? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Dave == Dave CROCKER [EMAIL PROTECTED] writes: Dave Or am I misunderstand the disparity between current reality Dave and necessary enhancements? You are. It's all ready. DNSSEC can be done in the plenary by changing the recursive servers. It's pretty close to being completely apt-get/yum/pkg_add able as being on. What's missing is someone to decide what are the set of TAs to use... Go read: http://www.dnssec-deployment.org/ -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Dave, On Nov 27, 2008, at 10:03 AM, Dave CROCKER wrote: If I understand the thread, so far, there is a current reality that suffers from missing too many pieces of necessary DNSSec infrastructure, documentation, maybe software, and definitely training. Without all of these additional pieces, it's not reasonable to expect any sort of casual use -- even for testing. No. DNSSEC is in production use today in various places. It's more that no one would notice. The IETF NOC folks could trivially set up a set of DNSSEC-validating caching name servers that would validate any/ all signed zones that are covered under the existing trust anchor(s). The NOC folks could then configure DHCP/RA to hand out the IP addresses for those validating caching name servers to folks who use the IETF network. The problem is that, like most plumbing, this would be entirely transparent to the folks using that network. One of the problems with deploying DNSSEC is that there are no standardized APIs that allow applications to determine whether or not a name has been validated. What's worse, with the standardized APIs, the typical indication of validation failure to applications is essentially indistinguishable from authoritative server misconfiguration. Also, since attacks DNSSEC protect against are exceedingly rare, it is unlikely there would be any actual behavior beyond normal DNS resolution for anyone to observe. However, with that said, I personally believe the IETF network should turn on DNSSEC validation in their caching servers and the IETF secretariat should sign the IETF-related zones. I can't think of any reason why this should not occur at this point. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, 27 Nov 2008, Michael Richardson wrote: You are. It's all ready. DNSSEC can be done in the plenary by changing the recursive servers. It's pretty close to being completely apt-get/yum/pkg_add able as being on. What's missing is someone to decide what are the set of TAs to use... Even that is done with autotrust and dnssec-keys packages. The only thing that needs to happen is for someone at the distribution to flip the switch. (dnssec-keys package allows that for Fedora/RHEL machine by using a simple dnssec-configure command, including DLV support)[*] The problem is really that there are not many signed zones out there that are reachable. As I talked at IETF-73 with people such as Roy and Sam, there is not really any benchmarking one can do. One can benchmark DNS and one can benchmark crypto, but benchmarking DNSSEC is not the sum of those two. Without the additional signed zones, the IETF Plenary testing really just becomes a much smaller version of a bind/unbound test at a large ISP. We'd be better of asking COMCAST to give a presentation about their experience enabling DNSSEC on their resolvers. And I think testing key rollover during the Plenary might be too disturbing for the plenary itself if it breaks. Paul [*] That and hardware crypto acceleration is basically our DNSX Secure Resolver appliance due Q1 2009. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, 27 Nov 2008, David Conrad wrote: However, with that said, I personally believe the IETF network should turn on DNSSEC validation in their caching servers and the IETF secretariat should sign the IETF-related zones. I can't think of any reason why this should not occur at this point. I agree. And they should push their keys into the ISC DLV, and at IETF enable DLV. But in general, everyone at IETF to should do this, not just the IETF secretariat. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On 27/11/08 19:36, David Conrad wrote: It's more that no one would notice. After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. Mat ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Nov 27, 2008, at 8:49 PM, Matthew Ford wrote: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. Data point: IETF65 (Dallas) had a DNSSEC enabled recursive nameserver (and, if I recall well, signed reverse zones). No impact noticed whatsoever. I wonder how many people actually knew. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
[As entertainment for the audience, I am sure everyone will enjoy seeing my brother and I take opposite sides in this discussion. Enjoy ;) ] I too have been watching this thread but from the vantage of having been deeply involved in DNSSEC deployment and, more specifically, as one of the people urging deploying DNSSEC at the IETF meetings. This thread began with Russ Housley sending a brief message yesterday: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? There was actually considerably more context behind this note, and it's perhaps unfortunate the thread has lurched off in a negative direction. I can't speak for the IAOC or others involved in the mechanics, so the following is my best understanding -- and also what I recommend -- of what's intended. There are three distinct elements of what's being planned. 1. Signing of the ietf.org zone 2. Providing a DNSSEC-compliant recursive resolver as part of the IETF net at the next IETF meeting. 3. An experiment during the plenary. Russ's note initiated discussion of this last piece without setting the context with the first two pieces. Let me say a few words about each piece. 1. Signing ietf.org Quite a few zones are already signed, and some top level domains, Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation. Many of us are running signed zones below the top level, and there is already a decision and commitment for the key zones related to the IETF to be signed. Based on the discussions I heard during the last IETF, the plan is to sign ietf.org immediately after the parent zone, .ORG, is signed. I would prefer for the signing of ietf.org to be independent of whether the parent zone is signed, but that's a separate discussion. In any case, it's my understanding that the people in charge of running ietf.org have been tasked with getting it signed. Once signed, I would expect it will stay in operation. That is, the timing and operation of the signed zone don't depend on the IETF meeting and have no direct relationship to the meeting's network. 2. Providing a DNSSEC-compliant recursive resolver as part of the IETF net at the next IETF meeting. The other side of the DNSSEC equation is having software that checks the signatures. This is done by a validating resolver, either a recursive resolver or the stub resolver. A handful of organizations, notably Telia in Sweden, Comcast, University of California Berkeley, and OARC are running DNSSEC-compliant recursive resolvers. I believe the ISPs, Telia and Comcast, are providing these resolvers as optional alternatives to the resolvers they regularly run and they are not including the addresses of these resolvers in the DHCP configuration parameters. Presumably they will become part of the standard DHCP configuration at some future time. The proposed action for the next IETF meeting is to do the same thing. That is, the IETF network will include a DNSSEC-compliant recursive resolver as an additional service which is not included in the list of DNS servers returned during the DHCP process. All of the above should invisible unless the end system explicitly invokes the DNSSEC-compliant recursive resolver AND asks for a signed response. 3. An experiment during the plenary I have not been involved in a discussion of this third piece, but I presume the intent is to simply include the DNSSEC-compliant recursive resolver in the standard DHCP configuration during the plenary. That is, during the plenary, DHCP responses will include the DNSSEC-compliant recursive resolver. Even though the normal DNS requests will thus go through the DNSSEC-compliant recursive resolver, the end system will see no difference unless the end system asks for a a signed response. I believe Russ was essentially asking what people think about this third piece of the plan. (Apologies, Russ, if I have incorrectly channeled you.) In line with David's note, there are indeed a lot of details to cover, including explanatory notes on how end systems need to be configured to ask for signed responses. measurements, etc., etc. All normal stuff and all part of what we are more than capable of doing all the time. Steve On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote: Peter Koch wrote: On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote: I agree with others' views that validation alone is not very helpful and some frequently queried for domains' zones should be signed as part of that experiment. By IETF74, the IANA (I)TAR might also be available as one source of TLD trust anchors. Still that date might be too early to encourage end system
Re: Proposed DNSSEC Plenary Experiment for IETF 74
Steve Crocker wrote: [As entertainment for the audience, I am sure everyone will enjoy seeing my brother and I take opposite sides in this discussion. Enjoy ;) ] ... There are three distinct elements of what's being planned. ... Russ's note initiated discussion of this last piece without setting the context with the first two pieces. Let me say a few words about each piece. ... In line with David's note, there are indeed a lot of details to cover, including explanatory notes on how end systems need to be configured to ask for signed responses. measurements, etc., etc. All normal stuff and all part of what we are more than capable of doing all the time. Steve, et al, Damn. Given your opening, I was hoping for something a little more entertaining. Especially since the only side my note was intended to take was to observe the stated objections and suggest moving into a project-planning mode, so that debate was about concrete details. What you've done is to agree that there are quite a few details. As you note, the mailing list didn't yet have the context to be aware that, apparently, many are already in place. So I'd class your note as a follow-through of mine, rather than opposing it... Reference to signing ietf.org suggests that the intent is to limit the experiment to operation within the ietf.org domain name. But since you and others have refereed to other branches that are signed, I assume more elaborate scenarios are intended to work. That is, since we know that the full DNS tree isn't signed, I assume that there are constraints on the scenarios that can be tested. What are they? And in line with your final paragraph, we do need details for the many client platforms: linices, windows, and mac platforms... and maybe some of the mobile ones, such as WM7, Android, ...? A quick google for windows dnssec produces no useful points high in the sequence. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
As I remember it, the flood in the NOC was much more exciting then the DNSSEC bits. - Lucy On Nov 27, 2008, at 8:49 PM, Matthew Ford wrote: After all the years of FUD surrounding DNSSEC deployment, I feel quite strongly that having the IETF do as you suggested and then be able to point to 'no discernible impact' on the network would be a significant milestone. Data point: IETF65 (Dallas) had a DNSSEC enabled recursive nameserver (and, if I recall well, signed reverse zones). No impact noticed whatsoever. I wonder how many people actually knew. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Proposed DNSSEC Plenary Experiment for IETF 74
I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
--On Wednesday, 26 November, 2008 10:50 -0500 Russ Housley [EMAIL PROTECTED] wrote: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? I think it is a wonderful idea. I must have a DNSSEC-enabled client for WinXP floating around here somewhere (not a browser extension, but something my email and Jabber clients can call and that has a well-sorted-out UI to deal with verification failures). I also assume those clients will be performing validation against a signed root zone, signed ORG, COM, and several national ccTLD zones, signed IETF.ORG, IAB.ORG, RFC-EDITOR.ORG, and IANA.ORG zones, etc. Do you have a plan about who is going to supply the low-velocity flying pigs for this meeting? Perhaps we could get them to listen for DNS queries and cache and transport responses. Sorry for the sarcasm, but some operational reality would be a good idea for ideas like this. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? Russ nifty! jck shares my concerns. as far as I can determine, the only way this would work at all is if everyone ran their own copy of a validating resolver on their own machines, each with a manually configured suite of Trust Anchors. Now what would be a truely interesting test is to have multiple, independent implementations of RFC 5011 and agreement by the TA owners to roll their keys during the IETF... and see how the various implementations fo RFC 5011 break - or not. or - we can all run pre-beta versions of windows-7 and statically point to either of the two third-party trust anchors in the Internet, the ISC DLV registry or the ICANN-ITAR. either of which is one minor step removed from simple static configuration. then there is the tiny problem of the lack of a standard DNSSEC API - it can be as simple as a single bit (validated or not) or can have a range of options. i don't think there is consensus on what to do here. and I am dubious that there will be significant change before IETF 74. but I could be wrong and may have to show up just to see how well the IETF recreates Interop! --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
+1 John C Klensin wrote: --On Wednesday, 26 November, 2008 10:50 -0500 Russ Housley [EMAIL PROTECTED] wrote: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? I think it is a wonderful idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
In message [EMAIL PROTECTED], Russ Housley writes: I have been approached about a plenary experiment regarding DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients during the plenary session. I like the idea. What do others think? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf The first thing we should address is the lack of signed zones under the control of the IETF. ; DiG 9.3.5-P2 dnskey ietf.org ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ietf.org. IN DNSKEY ;; AUTHORITY SECTION: ietf.org. 7200IN SOA ns0.ietf.org. glen.amsl.com. 120073 1800 1800 604800 7200 ;; Query time: 344 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Nov 27 10:06:43 2008 ;; MSG SIZE rcvd: 79 Secondly we should just turn on DNSSEC validation on the recursive servers offered by DHCP and RAs. This should be on for the entire week. This is what we are asking ISP's to do and I see no reason why we shouldn't do the same. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Nov 26, 2008, at 10:05 AM, John C Klensin wrote: I also assume those clients will be performing validation against a signed root zone, Sure, if they configure their trust anchor according to https://ns.iana.org/dnssec/status.html (There are other testbeds too, but I don't recall where to dig up their trust anchors) signed ORG, Might be in limited testing by the next IETF -- I don't remember offhand the schedule of when ORG was going to be signed... COM, Won't be ready by the next IETF so I understand. and several national ccTLD zones, Yep: SE, BR, PR, BG, CZ at this point. And, of course: MUSEUM and the test IDN TLDs. Might be more by the next IETF. Also, if you're using the ns.iana.org IANA testbed, you'll also get INT, ARPA, and ARPA children. Do you have a plan about who is going to supply the low-velocity flying pigs for this meeting? Perhaps we could get them to listen for DNS queries and cache and transport responses. Unnecessary. All it would take would be for the folks who set up the caching servers to configure the appropriate root (or TLD) trust anchors. It isn't really that hard. I've been doing it on my laptop now for over a year. Of course, the real issue is whether or not anyone would actually notice. The vast majority of folks (the ones who get the IP addresses for their caching servers via DHCP) would see absolutely no change unless there is a validation failure, in which case they'll get back a SERVFAIL response which will likely be interpreted as 'host not found'. Sorry for the sarcasm, but some operational reality would be a good idea for ideas like this. The operational reality is that folks are deploying DNSSEC and there are even folks who are validating responses with it. Turning on DNSSEC in the IETF-supplied caching servers should probably be the default. Any reason not to? Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
