- techsec-wg - mailman.ripe.net

Announcement DNSSec Training Courses
by RIPE NCC Training 21 Jul '04

21 Jul '04

Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the DNSSec Training Course. The main objective of the DNSSec Training Course is to provide LIRs with sufficient background to be able to deploy DNSSec in their own organisation as soon as the protocol is standardised. This course also explains the specific procedures set up by the RIPE NCC to to secure the in-addr.arpa zone. The Domain Name System (DNS) is one of the main parts of the Internet infrastructure. At the moment DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSec is a set of extensions to provide this end-to-end authenticity and integrity. It is currently being developed within the IETF dnsnext Working Group. The protocol is about to be finalised and the code implementing the protocol is available in alpha releases. The DNSSec course consists of two parts: an "Introduction to DNSSec" and a real life demonstration. The "Introduction to DNSSEC" will cover: - DNS security threats - DNSSec security mechanisms - DNSSec server protection - DNSSec data protection - Delegation issues - Key management issues - Current developments Examples are based on the BIND name server. Please note that DNSSec is an advanced course. It will: - NOT teach the basics of DNS. - NOT describe how to receive Internet resources from the RIPE NCC not describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network & system operators, engineers, etc. This course is not intended for administrative or management staff (e.g. Hostmasters). It is assumed that all attendees are familiar with common DNS terminology, have a practical knowledge in operating DNS servers and are interested in learning the concepts and mechanisms that DNSSec offers. The DNSSec course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the DNSSec Training Course can be found at: http://www.ripe.net/training/dnssec/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> In order to register for a DNSSec Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with the RIPE NCC as authoritative contact persons. It is expected that most of those interested in the DNSSec Training Course will not be an authorative contact persons for their LIR, and therefore will be refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Training Team RIPE NCC COURSE DATES AND VENUES ======================= Date: Friday 8 October 2004 Time: 0900 - 1700 Location: Amsterdam, the Netherlands AND: Date: Friday 5 November 2004 Time: 0900 - 1700 Location: Novosibirsk, Russia REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

(no subject)
by Surguy, Jason 10 Jun '04

10 Jun '04

confirm 390900 This e-mail has come from Experian International: winner of the UK's National Business of the Year Award 2003. ========================================================================== Information in this e-mail and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient Experian Limited (registration number 653331) Registered office: Talbot House, Talbot Street, Nottingham NG80 1TH Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer virus, you are advised to take your own steps to ensure that they are actually virus free.

1 0

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

TechSec agenda RIPE 48
by ted＠tednet.nl 21 Apr '04

21 Apr '04

The agenda for the TechSec meeting at RIPE 48 on Wednesday 5 May, 9:00 - 10:30. A. Administrative Matters - scribe - list of participants - agenda - minutes B. Report from the Monday DNSSEC session, Steve Crocker (20 min) C. Resolver application interface, Miek Gieben (10 min) D. Secure resolver develoments at NLnet Labs, Jelte Jansen (10 min) E. Open discussion on secure resolvers and application/validator interaction, Bill Manning. F. AOB -- ted

1 0

Proposed agenda RIPE 48
by ted＠tednet.nl 19 Apr '04

19 Apr '04

The proposed agenda for the TechSec meeting on Wednesday 5 May, 9:00 - 10:30. A. Administrative Matters - scribe - list of participants - agenda - minutes B. Report from DNSSEC session, Steve Crocker (20 min) C. Resolver application interface, Miek Gieben (10 min) D. Secure resolver develoments at NLnet Labs, Jelte Jansen (10 min) E. Open discussion on secure resolvers and application/validator interaction, Bill Manning. F. AOB -- ted

1 0

Re: [techsec-wg] TechSec meeting, RIPE 48
by ted＠tednet.nl 25 Mar '04

25 Mar '04

[Quoting bill, on Mar 25, 13:53, in "Re: [techsec-wg] Tec ..."] > Well... Some of this has to do w/ my view that the > validator function is independent of the resolver > and that the application/validator interaction is > not well understood from either the app.developer > or the validator spec writer. > > So its not really a DNS issue, to my mind. :) OK, when more subjects popup for the TechSec meeting, let's do it. -- ted

1 0

Re: [techsec-wg] TechSec meeting, RIPE 48
by ted＠tednet.nl 25 Mar '04

25 Mar '04

[Quoting bill, on Mar 25, 13:33, in "Re: [techsec-wg] Tec ..."] > > So, please, anyone with an agenda points, a contribution > > or anything else to discuss of present: speak up NOW! > > I'd like to have a brief, open-ended discussion > on DNSSEC validation. I'd be happy to put some > talking points together, but have no definitive > answers. Only questions. :) Such a discussion seems very worthwhile, and NLnet Labs can certainly contribute also, but... for what reason do you want to do this in the TechSec working-group, instead of in the DNS working-group? -- yed

2 1

TechSec meeting, RIPE 48
by ted＠tednet.nl 25 Mar '04

25 Mar '04

Dear Working Group people, In five weeks we have RIPE 48. The TechSec meeting at RIPE 47 was cancelled due to lack of interest. There is a slot for the TechSec WG at RIPE 48, but I'm wondering whether there is enough interest now to not have to it cancel it again. So, please, anyone with an agenda points, a contribution or anything else to discuss of present: speak up NOW! Regards, -- ted

2 1

Launch of the Security Plugtests Registration
by Muriel Souville 10 Mar '04

10 Mar '04

Dear all, The ETSI Plugtests(tm) Service is pleased to announce the opening of the Security Plugtests registration. The event will take place from 24 till 28 May at the ETSI premises, in Sophia Antipolis (France). Deadline to register is 5th May. All details about the event are to be found at http://www.etsi.org/plugtests/security.htm Feel free to forward this email to as many people as you want in order to have a really interesting test opportunity this week. For any enquiry you may have, please write to plugtests(a)etsi.org. Thanks for your attention. We look forward to welcoming you at our Headquarters in May. Best regards Muriel SOUVILLE ETSI Consultant Tel: +33 (0) 3 90 23 63 63

1 0

TechSec meeting, RIPE 47, cancelled
by ted＠tednet.nl 12 Jan '04

12 Jan '04

There was one agenda item for the TechSec meeting at RIPE 47: the DISI report by Olaf Kolkman. However, this item has been moved to the DNS-wg. So, as there are now no items left for the TechSec meeting, I propose to cancel the meeting. Regards, -- ted

1 0