techsec-wg

Download

techsec-wg@ripe.net

May 2004

1 participants
1 discussions

Draft minutes RIPE48-TechSec
by ted＠tednet.nl 05 May '04

05 May '04

RIPE48 TechSec Working Group Amsterdam, 5 May 2004, 9:00-10:30 Chair: Ted Lindgreen Notes: Olaf Kolkman with help from Daniel Karrenberg and Scott Rose Agenda A. Administrative Matters * scribe * list of participants * agenda * minutes B. Report from the Monday DNSSEC session Steve Crocker (20 min) C. Secure resolver developments at NLnet Labs Jelte Jansen (10 min) D. Resolver application interface Miek Gieben (10 min) E. Open discussion on secure resolvers and application/validator interaction Bill Manning F. AOB ---------------------------------------------------------------------- A. Administrative Matters Ted Lindgreen (TL): Session is dedicated to DNSSEC. TL: Based on Jan 2004 experiences the server side is done. We will focus on deployment and validator/resolver issues. * minutes No remarks on the minutes ---------------------------------------------------------------------- B. Report from the Monday DNSSEC session Steve Crocker (20 min) Notes on the presentation, in addition to the slides. SC: The DNSSEC spec is about to be done. Will the deployment happen easily? The purpose is to identify the interdependencies and see where and what work needs to be done. SC identifies a number of deployment steps, and alternatively looks at the phases of deployment. A pair of meetings was organized one May 3 in Amsterdam and one in San Francisco May 23. Some of the topics discussed: key-management, anchor points, end system procedure, training and privacy considerations. These where presented in a series of talks that will be available from [http://www.sdl.sri.com/other/dnssec]. Rough conclusions: - Server side looks good but tricky for larger zones - Privacy issues are not put to rest yet - End systems will be the biggest headache - Lot of operational details such as key distribution and rollover schemes - Training material and policy advice is crucial. Next steps: Meeting in San Francisco, and the formation of a 'steering group' that build an maintains a roadmap TL: When will the root will be signed. SC: Don't know, one line of thinking says that technical hurdles are taken and that signing can be done pretty soon, another line is more careful and wants to move with large amounts of caution. The effort is about identifying the FUD and to close the polemic loops by documenting the issues. It is clear that if the root were to be signed, deployment of DNSSEC would be faster. Patrick Falstrom (PAF): The IAB is responsible for some zones like e164.arpa. What would your advice be if the request would come if a zone is to be signed SC: Signing is good, rather sooner than later. The order in which things need to happen will need to be established. Johan Ihren: While introducing new DNSSEC there are two considerations: introduce security, and avoid breaking stuff. The root is old, lots to break, e164.arpa is new, little legacy and therefore an easier place to deploy. TL: If the root is not signed, secure island will be popping up and secure islands may endanger the common namespace. Rudolf van der Berg (RvdB): once the technical issues are solved it becomes a political issues, how do we get geographical spread politicians to buy in? SC: It is clear that this should not be a US centric, having the meeting in Europe was in an effort to make this a global effort. Only having technicians is not sufficient for deployment, one needs vendors and registries buy in. ---------------------------------------------------------------------- C. Secure resolver developments at NLnet Labs Jelte Jansen (10 min) DNSSEC awareness in resolvers. Notes on the presentation, in addition to the slides. Jelte (JJ) describes the various manners in which a keys for validation can be done top down or bottom up. He bases his design on a top down approach. This recursive top-down resolver is to be implemented in libc and will only use authoritative servers. OK: is this going to be wide spread? Since bypassing caches is dangerous. JJ: Essentially this will be proof of concept. Sam Weiler (SW): How will you configure your trust-anchor. JJ: It is preconfigured. Bill Manning (BM): How long have you been working on this? Asked since we have no idea when/if the root is signed. SW: If you are assuming a signed root do you allow trusted anchors lower in the tree? JJ: Only one trusted anchor, at the root, is implemented currently. ---------------------------------------------------------------------- D. Resolver application interface Miek Gieben (10 min) Notes on the presentation, in addition to the slides. Miek describes in which states a validator can end up and explains that there is a need for resolvers to pass validation data to the applications. Miek proposes a method where error bit arrays are used to indicate the error status. draft-gieben-resolver-application-interface-00.txt No questions. ---------------------------------------------------------------------- E. Open discussion on secure resolvers and application/validator interaction Bill Manning Notes on the presentation, in addition to the slides. The presentation was intentionally interrupted by discussion a few times. Bill explains that we are still exploring this problem space and that there is a shared view on what is needed. The common ground Bill identifies is that one bit is not enough and that apps want to use their local policies. "Users/Apps" may want to have diagnostics and audit trails. Is our idea on the set of classes of apps complete? Leslie Daigle (LD): Concludes a small discussion in the room; we all agree that information needs to be transfered to the application so that local policy can be enforced. Summary of discussion between SC - DFK: Although it is not clear users care about this applications will need some default policy, or some mechanism to set the policy for specific part of the network. RvdB: The question is how much information is there in DNSSEC that we can display to the user/application so that an informed choice can be made. BM: There is a proposal on this information in Giebens draft. In his presentation Bill presents his view that delegation and chain validation are independent and may need to done at different times and different places. OK: Observes that BM splits validation from resolving. That validator is closer to PKI than to the DNS. TL: expands, DNSSEC was designed for preventing DNS problems like cache pollution. We are now discussing how applications would like to authenticate. While the caching forwarders must distinguish valid (secured and unsecured) data from bogus data, the applications may only want to know whether a query response is secure or not. SW: Is it sufficient to require to have end host have full resolvers so we can get rid off resolver-resolver or to push the full security aware resolvers into applications so you can rid of the API? To prevent cache poisoning one needs to do validation at the cache. DFK: Having to put validators in apps will delay deployment because the legacy resolvers are not protected. SW: Putting the validator at the application sets requirements to cache. DFK: Feels that the complications related to this discussion may not be beneficial to deployment. Back to the presentation. With all these ideas floating around we might end up with competing different solutions. Will this ever be a DNS protocol? There was some discussion on where this problem needs to be solved and if the IETF is the proper forum. Miek has not found a IETF WG to adopt his draft. Where do we have to discuss these requirements to make sure that we converge? LD: Suggest to move Miek's draft to the application area in the IETF. MG: Asked a clarifying question: will the application do the validation. BM: The application will drive the validation. MG: Feels that applications should not implement a validator BM: If that happens it should show the same external behavior as the 'other' validators. MG: Process does resolving and validation. Administrator can set local policy for the whole machine Application can do apply the second phase of local policy. OK: Fears that working on the requirements will take years unless we find the most simple common ground. Is there a complete set of requirements like Miek suggests or are there *many* more requirements like Bill suggests. If we go down for solving all problems it will never converge. DFK: Find essential elements. MG: We will need to enumerate what are the error cases are that we can end up with. TL: Concludes by reminding the audience that we can secure the infrastructure today. And that getting validator info to the application is a "second" phase. ---------------------------------------------------------------------- F. AOB Nothing. ---------------------------------------------------------------------- ----------------------------------------------------------------------

1 0