From matthijs at nlnetlabs.nl Mon Jan 6 12:33:23 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 06 Jan 2014 12:33:23 +0100 Subject: [dns-wg] Framework for DNSSEC audits Message-ID: <52CA9483.8070400@nlnetlabs.nl> Hi all, This might be of interest to you. In collaboration with SWITCH, we have developed a DNSSEC audit framework: http://www.nlnetlabs.nl/downloads/publications/dns-audit-framework-1.0.pdf The scope of the framework is largely based on the documents RFC 2870, RFC 6841, RFC 6781 and the Secure Domain Name System (DNS) Deployment Guide from NIST. Having this publicly available we believe it will improve the deployment of DNSSEC. Best regards, Matthijs Mekking NLnet Labs From Ralf.Weber at nominum.com Mon Jan 6 17:18:42 2014 From: Ralf.Weber at nominum.com (Ralf Weber) Date: Mon, 6 Jan 2014 16:18:42 +0000 Subject: [dns-wg] Framework for DNSSEC audits In-Reply-To: <52CA9483.8070400@nlnetlabs.nl> References: <52CA9483.8070400@nlnetlabs.nl> Message-ID: Moin! On 06 Jan 2014, at 12:33, Matthijs Mekking wrote: > This might be of interest to you. In collaboration with SWITCH, we have > developed a DNSSEC audit framework: > > http://www.nlnetlabs.nl/downloads/publications/dns-audit-framework-1.0.pdf > > The scope of the framework is largely based on the documents RFC 2870, > RFC 6841, RFC 6781 and the Secure Domain Name System (DNS) Deployment > Guide from NIST. > > Having this publicly available we believe it will improve the deployment > of DNSSEC. I admire your efforts and the document is well written from my quick glancing over it. But we IMHO need a big boilerplate upfront that this is not needed for deploying DNSSEC. The document might be good for TLD and registries/registrars with huge security requirements. But if we want to get widespread deployment we need to get further down the tree and wider. And my fear is that such a document can cause people to delay or not do DNSSEC deployments as the requirements (based on this document) are huge (none of my currently signed domains would pass an audit). I will add it to my reading list for a more detailed review. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.weber at nominum.com From anne-marie.eklund-lowinder at iis.se Tue Jan 7 09:00:54 2014 From: anne-marie.eklund-lowinder at iis.se (=?Windows-1252?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Tue, 7 Jan 2014 09:00:54 +0100 Subject: [dns-wg] Framework for DNSSEC audits In-Reply-To: References: <52CA9483.8070400@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B5CE4D546E66@EXCHANGE2K7.office.nic.se> > -----Ursprungligt meddelande----- > Fr?n: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] F?r Ralf > Weber > Skickat: den 6 januari 2014 17:19 > Till: Matthijs Mekking > Kopia: dns-wg at ripe.net > ?mne: Re: [dns-wg] Framework for DNSSEC audits > > Moin! > > On 06 Jan 2014, at 12:33, Matthijs Mekking wrote: > > > This might be of interest to you. In collaboration with SWITCH, we > > have developed a DNSSEC audit framework: > > > > > > http://www.nlnetlabs.nl/downloads/publications/dns-audit-framework-1.0 > > .pdf > > > > The scope of the framework is largely based on the documents RFC 2870, > > RFC 6841, RFC 6781 and the Secure Domain Name System (DNS) Deployment > > Guide from NIST. > > > > Having this publicly available we believe it will improve the > > deployment of DNSSEC. > I admire your efforts and the document is well written from my quick > glancing over it. But we IMHO need a big boilerplate upfront that this is > not needed for deploying DNSSEC. The document might be good for TLD and > registries/registrars with huge security requirements. But if we want to > get widespread deployment we need to get further down the tree and wider. > And my fear is that such a document can cause people to delay or not do > DNSSEC deployments as the requirements (based on this document) are huge > (none of my currently signed domains would pass an audit). > > I will add it to my reading list for a more detailed review. I've read the document carefully, and from my perspective, this is exactly what you need to make sure that a specific dnssec implementation put up to the requirements that are addressed, no matter the kind of organization. The audit framework must be able to cover all kinds of implementations, from registry and registrar down to a smaller entity. But doing an audit gives you the freedom to express when a requirement is applicable or not, imho that is. Kind regards, Anne-Marie Eklund L?winder Chief Information Security Officer .SE -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 182 bytes Desc: not available URL: From matthijs at nlnetlabs.nl Tue Jan 7 09:23:25 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Tue, 07 Jan 2014 09:23:25 +0100 Subject: [dns-wg] Framework for DNSSEC audits In-Reply-To: References: <52CA9483.8070400@nlnetlabs.nl> Message-ID: <52CBB97D.80805@nlnetlabs.nl> Hi Ralf, On 01/06/2014 05:18 PM, Ralf Weber wrote: > Moin! > > On 06 Jan 2014, at 12:33, Matthijs Mekking > wrote: > >> This might be of interest to you. In collaboration with SWITCH, we >> have developed a DNSSEC audit framework: >> >> http://www.nlnetlabs.nl/downloads/publications/dns-audit-framework-1.0.pdf >> >> >> The scope of the framework is largely based on the documents RFC 2870, >> RFC 6841, RFC 6781 and the Secure Domain Name System (DNS) >> Deployment Guide from NIST. >> >> Having this publicly available we believe it will improve the >> deployment of DNSSEC. > I admire your efforts and the document is well written from my quick > glancing over it. But we IMHO need a big boilerplate upfront that > this is not needed for deploying DNSSEC. The document might be good > for TLD and registries/registrars with huge security requirements. > But if we want to get widespread deployment we need to get further > down the tree and wider. And my fear is that such a document can > cause people to delay or not do DNSSEC deployments as the > requirements (based on this document) are huge (none of my currently > signed domains would pass an audit). Yes, the framework is indeed in the first place applicable to TLDs. But also further down the tree people can benefit from this document. Note that this audit framework tries to be complete with respect to all possible controls, but these are not necessarily requirements. There may be controls that are not implemented or implemented differently, and if that is backed up with a managerial decision, the audit of the control may still pass. It is also possible for an auditor to do a partial audit, for example by only looking at the technical controls. > > I will add it to my reading list for a more detailed review. Thanks. We appreciate all feedback and discussion in order to mature this framework. Best regards, Matthijs > > So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum > Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 > ralf.weber at nominum.com > > > From benno at NLnetLabs.nl Tue Jan 14 14:11:01 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 14 Jan 2014 14:11:01 +0100 Subject: [dns-wg] Call for Presentations: RIPE 68, 12-16 May 2014 in Warsaw, Poland Message-ID: <52D53765.1080706@NLnetLabs.nl> Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 68 will take place from 12-16 May 2014 in Warsaw, Poland. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 68. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: * IPv6 deployment * Managing IPv4 scarcity in operations * Commercial transactions of IPv4 addresses * Data centre technologies * Network and DNS operations * Internet governance and regulatory practices * Network and routing security * Content delivery * Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe68.ripe.net/submit-topic/presentation-formats/. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe68.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice---in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe68.ripe.net/submit-topic/presentation-formats/. - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From mir at ripe.net Wed Jan 22 14:59:58 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 22 Jan 2014 14:59:58 +0100 Subject: [dns-wg] New on RIPE Labs: NTP Reflections Message-ID: <52DFCEDE.4080003@ripe.net> Dear colleagues, After the recent amplification attacks involving NTP servers, John Kristoff, a researcher with Team Cymru, kindly agreed to publish an analysis of the history and timeline leading up to the attacks. Please find his contribution on RIPE Labs: https://labs.ripe.net/Members/mirjam/ntp-reflections Kind regards, Mirjam Kuehne RIPE NCC