Category: DNSSEC

Sep 08

Watch UKNOF Today To Learn About IPv6, IXPs, Internet Connectivity

UKNOF 29 - ION BelfastWant to learn about IPv6, Internet Exchange Points (IXPs) and some of the latest connectivity ideas in the United Kingdom? If so, you can watch the live webcast of UKNOF 29 starting today, September 8, 2014, at 13:30 British Summer Time (BST, which is UTC+1). The critical links to know are:

Today’s sessions are mainly focused on network operations and Internet connectivity and include:

  • HEAnet’s Optical Backbone & School’s Connectivity
  • Watery Wireless
  • Options for Metro 100Gig
  • Network Function Virtualisation, bringing virtualised network infrastructure into the cloud
  • Broadcast editing and delivery over IP (from the BBC)
  • LINX’s UK regional peering strategy
  • An overview of BT’s network infrastructure in Ireland and Northern Ireland including connectivity to the the rest of the UK
  • UKNOF Status Update

Tomorrow, Tuesday, September 9, 2014, the morning sessions include some that may be of interest to our readers and then the afternoon will be our ION Belfast event.  Here’s the current UKNOF agenda going from 09:30-12:35 BST:

  • Latest Internet Plague: Random Subdomain Attacks  (about DNS security)
  • Tales of the unexpected – handling unusual DNS client behaviour
  • Using 100 Billion DNS Queries to Analyse the Name Collision Problem
  • What went wrong with IPv6?
  • IPv6-only Data Centres
  • Introduction of UK IPv6 Council

In particular I would point your attention to the “What went wrong with IPv6?” talk at 11:30 BST by Dave Wilson from HEAnet. He recently gave a version of this talk at RIPE 68 and both the video and the slides from that talk are available. He asks some great questions and, I think, has some great ideas for we can advance IPv6 deployment – definitely worth listening to!

ION Belfast LogoAfter a lunch break, our ION Belfast event will then begin with a packed agenda talking about IPv6, DNSSEC and securing BGP.  That, too, will be webcast live for all to see!

All in all it will be two days of outstanding sessions talking about the Internet’s infrastructure and how we can make it work better, faster and more secure!

I hope you will join me in tuning in to watch!

Sep 05

New RFC 7344 – Aiming To Solve The DS Upload Issue in DNSSEC

DS UploadHow can we automate the communication between a DNS operator and a registrar when a DNSSEC key has changed?

I saw this issue very starkly myself the other week when I received 4 email messages from one of the DNS hosting operators I use telling me that new Key Signing Keys (KSKs) had been generated for four of my domains.  Now, on one level this was good, in that they were automagically rolling the KSKs over without me having to do anything.  However…  they had no way to tell the registrars for those domains that a new DNSKEY record (and therefore a DS record) had been created. In other words:

The global chain of trust was now broken for those four domains.

Any DNS resolver performing DNSSEC validation would now find a broken chain of trust and would send back a SERVFAIL.  People behind a DNSSEC-validating DNS server would not be able to reach my site.

Now, this happens for me because I use a different operator for my DNS servers than my registrar.  If you think of the different players involved in the DNSSEC process, very often a registrar is also acting as a DNS hosting operator.  In other words, when you register your domain with a registrar, they are also providing the DNS services for you.  In that case the DNS hosting side of the company can communicate to the registrar side of the company that there is a new key and all can work well.

However, in my case the company providing DNS services for me is different from my registrar.  I am paying a company for DNS hosting – but I could instead be hosting my own authoritative DNS servers.  This might be common if I were an enterprise / business that operated my own data centers, for instance.

The key point here is that a registrar needs to pass a Delegation Signer (DS) record  (or in some cases a DNSKEY record) up to the registry for the top-level domain (ex., .org, .com, .whatever).  This needs to happen in order to have the “global chain of trust” work and to be sure that the DNSSEC signatures are not being falsified.

Within the DNSOP working group in the IETF we’ve been debating a number of proposals about how to fix this for quite some time.  One of those proposals has now been issued as an Informational RFC 7344:

http://tools.ietf.org/html/rfc7344

Formally titled “Automating DNSSEC Delegation Trust Maintenance“, the RFC specifies the creation of two new DNS record types that you would use to signal to a parent zone (for example, a top-level domain registry) that you have a new DNSSEC record that the parent zone needs to retrieve.  The two records are:

  • CDS
  • CDNSKEY

Typically you would probably use one or the other depending upon what your TLD registry requires, but both are specified within the RFC 7344.

The RFC goes into much greater detail, but in a nutshell it would work something like this:

  1. As the DNS operator of EXAMPLE.ORG, I would generate a new DNSKEY record (for the KSK).
  2. I would also generate a DS record and publish that as a CDS record.
  3. The parent zone, .ORG in this example, would notice that a new CDS record has been published.
  4. The .ORG registry would retrieve my CDS record and then publish it as a DS record for my zone.
  5. Once the DS record has been published I could then stop publishing the CDS record until the next time I made a change.

The global chain of trust would now be intact.

The key challenge of this approach is step #3 – how does the parent zone notice that a new CDS record has been published?

This is a critical point and one that was debated at some length.  The primary thinking is that parent zones that want to use this type of approach would create some kind of “parental agent” that would poll zones periodically to see if there are new CDS records out there.   RFC 7344 gets into this in section 6.1 and suggests that there could be both polling and pushing mechanisms developed.  Such software is not yet out there, but now that the RFC is out it can certainly be developed.

In any event, this RFC 7344 is now out there providing one potential solution to this “DS upload” problem.  What do you think?  Is this something you can see implementing?  Would you like to see your registries, registrars and DNS hosting operators supporting this approach?  Do you have another idea?

P.S. Want to get started with DNSSEC?  Please visit our “Start Here” page to find appropriate resources…

Aug 15

The DNSSEC Coordination “Breakfast” At IETF90

As has been our practice for the last several IETF meetings, a group of us involved with DNSSEC got together at about 7:30am on Friday, July 25, 2014, at IETF 90 in Toronto to talk about… well… whatever we wanted… but often involving DNSSEC! As usual it was an enjoyable time catching up and learning more about each other… and talking about new ideas and new ways we could do things.

DNSSEC breakfast

This breakfast included: Shumon Huque, Paul Ebersman, Mike Baer, Dan York (me), Russ Mundy, Frederico Neves and Wes Hardaker.

If you’d like to join into DNSSEC-related activities such as this, please feel free to join the public “dnssec-coord” mailing list where we coordinate plans like this to get together.

And if you’d like to learn more about DNSSEC, please check out our Start Here page to learn more about how to get started!

Aug 14

Watch Live Today – DNSSEC Root Key Ceremony #18

IANA logoIf you are interested in understanding a bit more about how the overall DNSSEC infrastructure operates, you can watch the “Root DNSSEC KSK Ceremony 18″ live today, August 14, 2014, from a data center in El Segundo, California, USA, starting at 12:15pm Pacific time, which is 19:15 UTC.  All the information and the link to the live stream can be found at:

https://www.iana.org/dnssec/ceremonies/18

The key ceremonies are part of the activities performed by the Internet Corporation for Assigned Names and Numbers (ICANN) under its contract to operate the Internet Assigned Numbers Authority (IANA). As explained on the overview page:

Ceremonies are usually conducted four times a year to perform operations using the Root Key Signing Key, and involving Trusted Community Representatives. In a typical ceremony, the KSK is used to sign a set of operational ZSKs that will be used for a three month period to sign the DNS root zone. Other operations that may occur during ceremonies include installing new cryptographic officers, replacing hardware, or generating or replacing a KSK.

This ceremony today is to use the “master” root Key Signing Key (KSK) to generate a set of Zone Signing Keys (ZSKs) that will then be used until the next key ceremony.

There is a complete script that outlines the overall process that is used by ICANN to perform this operation today.  In the interest of transparency there is also a live video stream that will show the entire process and that will be archived for later viewing.

Additionally, during today’s key ceremony there will be a replacement of one of the Cryptographic Officers (COs) who each hold a part of the overall master Root Key.  Ed Lewis is ending his term as a CO and is being replaced by Olafur Gudmundsson.  There is also a complete script outlining the steps of the replacement process.

The “root key” is at the top of the “global chain of trust” that is used to ensure the correct validation of DNSSEC signatures (for more info see “The Two Sides of DNSSEC“) and so it is critical that the security and integrity of this root key be maintained.  Ceremonies such as the one today are a part of that effort.  If you are interested in learning more, today is a bit of a peek behind the curtain about how all of this happens…

P.S. If you want to learn more about how to get started with DNSSEC, please visit our “Start Here” page to find resources focused on your type of role or organization.

Aug 07

Awesome News About HTTPS As A Ranking Signal, Google! Now Can We Please Get IPv6 And DNSSEC, Too?

Google logoThe big news hitting the online marketing world today is that Google has indicated that the use of HTTPS in your web site will potentially help your site rank better in Google’s search results. In other words, the use of a TLS (formerly “SSL”) certificate to encrypt the connection to your website will be one of the signals Google uses to rank results.  To be precise, here is the key part of the post:

For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

Because you almost never get SEO advice directly from Google this was big news today.  And even though the post says that fewer than 1% of search engine queries will be helped today by enabling HTTPS, I’ve already seen a ton of associated articles from SEO consultants and others saying that you need to go enable TLS for your site today.  (Well, okay, to be honest the ones I’ve seen are all saying to go enable “SSL” but maybe some day we can get everyone to use “TLS”! On that note, kudos to Google for NOT using “SSL” in their article!)

I’m sure that many web hosting providers are similarly getting inquiries from customers today about how TLS can be enabled on their websites.

Naturally we’re pleased to see this news out of Google because the goal of our TLS for Applications area here on Deploy360 is to help people get TLS happening across their sites and services.  So to the degree that Google can help drive that deployment of TLS – and wind up getting the whole ecosystem of SEO consultants and marketing/PR people to help drive that deployment – we all win with a more secure Internet!

Of course, our thinking immediately jumps to the next step – what if Google were to say that having a site available over IPv6 would count as a ranking signal?  Several people on Twitter suggested exactly that today. Here’s one:

Can you imagine how many website owners might suddenly be asking their ISPs and hosting providers how to get IPv6?  (Tip to website owners/operators: check our our IPv6 resources targeted to you!)

Or… what if the fact that a web site’s domain was signed with DNSSEC counted as a ranking signal?

Can you imagine how many website owners might suddenly be trying to get their domains signed?  (Again, we’ve got you covered with some steps you can take.)

How about it, Google?  Please?   :-)

P.S. If you do want to get your site or network moved to IPv6 or DNSSEC, please check out our “Start Here” page to find resources focused on your type of organization or role.

 

 

Aug 05

InfoWorld: Why You Need To Deploy DNSSEC Now

InfoWorld logoToday long-time DNS expert Cricket Liu came out with a good post on InfoWorld, “Why you need to deploy DNSSec now ” where he talks through

  • why you need DNSSEC
  • how it works, including a walk-through of the actual RRSIG record in DNS
  • human factors that delayed implementation
  • motivation for deploying DNSSEC (or lack thereof)
  • factors to consider for your infrastructure such as overhead

He had one intriguing point about a potential organization that could influence DNSSEC deployment:

There is one organization, however, that is in a surprisingly strong position to influence the uptake of DNSSec: the PCI Security Standards Council, responsible for the development of the PCI Data Security Standard and other standards governing the payment card industry. Longstanding rumors say the organization is considering requiring companies whose websites accept payment cards to use DNSSec to sign their zones in order to achieve PCI DSS compliance. Given how pervasive acceptance of credit cards is on major websites, such a requirement would have vast reach.

That rumor is interesting to hear and certainly something we’ll be exploring through various connections to learn more about what might be possible.

I was surprised, though, that Cricket did not mention what I see as one of the strongest motivations to deploy DNSSEC right now – the ability to then use the DANE protocol to provide an additional layer of trust to TLS and SSL certificates. As Andrew recently wrote, DANE has a great ability to increase the overall security of TLS/SSL certificates by ensuring that users are receiving the correct TLS certificates that you want them to be using.  We’re already seeing a great uptake in DANE / DNSSEC usage within the XMPP/Jabber community as well as within various email services as a way of authenticating mail servers and helping fight spam.

I also felt the article dealt a bit longer than needed on some of the past history of DNSSEC and some of the earlier issues that slowed deployment, rather than focusing on the fact that those obstacles have been overcome and the tools and solutions are MUCH easier now.

Overall, though, this is a good article and it’s good to have it out there on a widely-read site such as InfoWorld.

If you would like to get started with DNSSEC – because Cricket is right, the time to start is NOW! – please visit our “Start Here” page to find resources targeted for the type of role you have.  Or jump directly to our DNSSEC page and browse some of the links and information you find there.

See the discussion of this InfoWorld article on:

 

Aug 04

IPFire Adds DNSSEC Validation In New Release Via Crowdfunding

ipfire logoWe were pleased to see an announcement from the IPFire open source firewall distribution indicating that DNSSEC validation had been added to their most recent “IPFire 2.15 – Core Update 80″ yesterday.  More intriguing to me, perhaps, was that the DNSSEC validation was added to the software distribution via a crowdfunding initiative for their “wishlist”. While I realize this is not unique among software products, it was great to see that some number of IPFire users felt DNSSEC was important enough to donate to prioritize this task.  [Tip for IPFire: It would be nice to know how many users donated rather than just the total amount.]

I will admit I’d not heard of IPFire prior to seeing a tweet about the DNSSEC addition this morning, but in looking at their “About IPFire” page it seems to have the kind of services that I would want in a system like this. (I run a similar type of hardened Linux distribution on my own home server/gateway.)

This news about IPFire is important because getting DNSSEC validation to happen on the edge of local networks is a critical step in the plan for where DNSSEC validation needs to happen. Ideally, of course, we’d get the validation happening in the device operating systems and even applications, but getting the validation on the edge of the local network does minimize the attack surface significantly!

Kudos to the team at IPFire for doing this work – and for the IPFire users who crowdfunded it!

P.S. Do you know of another firewall software distribution that we should add to our list on the plan for DNSSEC validation?  Please do let us know as we’d definitely like to expand the list we have there.   And if you don’t know much about DNSSEC, check out our “Start Here” page to learn how to get started…

Jul 30

Call For Proposals: DNSSEC Workshop at ICANN 51 in L.A. on October 15, 2014

ICANN 51 logoDo you have an idea for a better way to work with DNSSEC?  Have you created a new tool or service for DNSSEC or DANE that you would like to present to the wider community?  Could you provide a “case study” of how you implemented DNSSEC within your organization?  Have you started using DANE to secure your email communication?

If you would be interested in speaking about any of those points – or any of the other topics we have listed below, WE WOULD LIKE TO HEAR FROM YOU!  We’re working on creating the program for the ICANN 51 DNSSEC Workshop that will be held in Los Angeles on October 15, 2014.  As you’ll note in the full call for participation included below, we are in particular seeking participants on three topics:

  • DANE / DNSSEC as a way to secure email
  • Potential impacts of Root Key Rollover
  • Experiences from new gTLD registries and administrators

If you have any ideas, or would like to ask questions about what is involved with the workshop, please email us at dnssec-losangeles@isoc.org.  Initially, we don’t need a full abstract – just a couple of sentences about what you would like to speak about is perfectly fine.

Thanks,
Dan

Call for Participation — ICANN DNSSEC Workshop 15 October 2014

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 51 meeting in Los Angeles, California, on 15 October 2014. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.

For reference, the most recent session was held at the ICANN meeting in London on 25 June 2014. The presentations and transcripts are available at: http://london50.icann.org/en/schedule/wed-dnssec.

We are seeking presentations on the following topics;

1. DNSSEC activities in the North America region

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the North America region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions:

  • What can DNSSEC do for you?
  • What doesn’t it do?
  • What are the internal tradeoffs to implementing DNSSEC?
  • What did you learn in your deployment of DNSSEC?

We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

2. DANE / DNSSEC as a way to secure email

The DNS-based Authentication of Named Entities (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. We are both pleased and intrigued by the growing usage of DANE and DNSSEC as a means of providing added security for email. Multiple email servers have added support for DANE records to secure TLS/SSL connections. Some email providers are marketing DNSSEC/DANE support. We would like to have a panel at ICANN 51 focusing on this particular usage of DANE. Are you a developer of an email server or client supporting DANE? Do you provide DANE / DNSSEC support in your email service? Can you provide a brief case study of what you have done to implement DANE / DNSSEC? Can you talk about any lessons you learned in the process?

3. Potential impacts of Root Key Rollover

Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys. We would like to be able to offer suggestions out of this panel to the wider technical community. If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

4. New gTLD registries and administrators implementing DNSSEC

With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC. As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier?

5. The operational realities of running DNSSEC

Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC?

  • What is the best practice around key rollovers?
  • How often do you review your disaster recovery procedures?
  • Is there operational familiarity within your customer support teams?
  • What operational statistics have we gathered about DNSSEC?
  • Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

6. DNSSEC automation

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:

  • What tools, systems and services are available to help automate DNSSEC key management?
  • Can you provide an analysis of current tools/services and identify gaps?
  • Where are the best opportunities for automation within DNSSEC signing and validation processes?
  • What are the costs and benefits of different approaches to automation?

7. When unexpected DNSSEC events occur

What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?

8. DANE and DNSSEC applications

There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:

  • What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
  • What tools and services are now available that can support DANE usage?
  • How soon could DANE and other DNSSEC applications become a deployable reality?
  • How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?

We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services. For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.

9. DNSSEC and DANE in the enterprise

Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and can address questions such as:

  • What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?
  • What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?
  • How should an enterprise best prepare its IT staff and network to implement DNSSEC?
  • What tools and systems are available to assist enterprises in the deployment of DNSSEC?
  • How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?

10. Guidance for Registrars in supporting DNSSEC

The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from January 1, 2014. We are seeking presentations discussing:

  • What are the specific technical requirements of the RAA and how can registrars meet those requirements?
  • What tools and systems are available for registrars that include DNSSEC support?
  • What information do registrars need to provide to resellers and ultimately customers?

We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.

11. Implementing DNSSEC validation at Internet Service Providers (ISPs)

Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as:

  • What does an ISP need to do to prepare its network for implementing DNSSEC validation?
  • How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation?
  • What measurements are available about the degree of DNSSEC validation currently deployed?
  • What tools are available to help an ISP deploy DNSSEC validation?
  • What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?

12. APIs between the Registrars and DNS hosting operators

One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Currently, the communication, such as the transfer of a DS record, often occurs by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information, or from people with ideas around how such APIs could be constructed.

13. Hardware Security Modules (HSMs) use cases and innovation

We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-losangeles@isoc.org by Friday, 13 August 2014

We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Jul 30

Call for Participation: DNSSEC Workshop at ICANN 51 on 15 Oct 2014

ICANN 51 logoThe call for participation is now out for the DNSSEC Workshop to be held on  October 15, 2014, at ICANN 51 in Los Angeles.

If you have any ideas, or would like to ask questions about what is involved with the workshop, please email us at dnssec-losangeles@isoc.org.  Initially, we don’t need a full abstract – just a couple of sentences about what you would like to speak about is perfectly fine.  We are asking that all proposals be sent to us by no later than Friday, August 13, 2014 (but sooner is better as we expect this program to be quite full and we may not be able to accommodate all proposals).

Call for Participation — ICANN DNSSEC Workshop 15 October 2014

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 51 meeting in Los Angeles, California, on 15 October 2014. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.

For reference, the most recent session was held at the ICANN meeting in London on 25 June 2014. The presentations and transcripts are available at: http://london50.icann.org/en/schedule/wed-dnssec.

We are seeking presentations on the following topics;

1. DNSSEC activities in the North America region

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the North America region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions:

  • What can DNSSEC do for you?
  • What doesn’t it do?
  • What are the internal tradeoffs to implementing DNSSEC?
  • What did you learn in your deployment of DNSSEC?

We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

2. DANE / DNSSEC as a way to secure email

The DNS-based Authentication of Named Entities (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. We are both pleased and intrigued by the growing usage of DANE and DNSSEC as a means of providing added security for email. Multiple email servers have added support for DANE records to secure TLS/SSL connections. Some email providers are marketing DNSSEC/DANE support. We would like to have a panel at ICANN 51 focusing on this particular usage of DANE. Are you a developer of an email server or client supporting DANE? Do you provide DANE / DNSSEC support in your email service? Can you provide a brief case study of what you have done to implement DANE / DNSSEC? Can you talk about any lessons you learned in the process?

3. Potential impacts of Root Key Rollover

Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys. We would like to be able to offer suggestions out of this panel to the wider technical community. If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

4. New gTLD registries and administrators implementing DNSSEC

With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC. As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier?

5. The operational realities of running DNSSEC

Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC?

  • What is the best practice around key rollovers?
  • How often do you review your disaster recovery procedures?
  • Is there operational familiarity within your customer support teams?
  • What operational statistics have we gathered about DNSSEC?
  • Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?

6. DNSSEC automation

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include:

  • What tools, systems and services are available to help automate DNSSEC key management?
  • Can you provide an analysis of current tools/services and identify gaps?
  • Where are the best opportunities for automation within DNSSEC signing and validation processes?
  • What are the costs and benefits of different approaches to automation?

7. When unexpected DNSSEC events occur

What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?

8. DANE and DNSSEC applications

There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as:

  • What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries?
  • What tools and services are now available that can support DANE usage?
  • How soon could DANE and other DNSSEC applications become a deployable reality?
  • How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet?

We would be particularly interested in any live demonstrations of DNSSEC / DANE applications and services. For example, a demonstration of the actual process of setting up a site with a certificate stored in a TLSA record that correctly validates would be welcome. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome.

9. DNSSEC and DANE in the enterprise

Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and can address questions such as:

  • What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so?
  • What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges?
  • How should an enterprise best prepare its IT staff and network to implement DNSSEC?
  • What tools and systems are available to assist enterprises in the deployment of DNSSEC?
  • How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates?

10. Guidance for Registrars in supporting DNSSEC

The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from January 1, 2014. We are seeking presentations discussing:

  • What are the specific technical requirements of the RAA and how can registrars meet those requirements?
  • What tools and systems are available for registrars that include DNSSEC support?
  • What information do registrars need to provide to resellers and ultimately customers?

We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so.

11. Implementing DNSSEC validation at Internet Service Providers (ISPs)

Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as:

  • What does an ISP need to do to prepare its network for implementing DNSSEC validation?
  • How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation?
  • What measurements are available about the degree of DNSSEC validation currently deployed?
  • What tools are available to help an ISP deploy DNSSEC validation?
  • What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?

12. APIs between the Registrars and DNS hosting operators

One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Currently, the communication, such as the transfer of a DS record, often occurs by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information, or from people with ideas around how such APIs could be constructed.

13. Hardware Security Modules (HSMs) use cases and innovation

We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-losangeles@isoc.org by **Friday, 13 August 2014**

We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Jul 25

Deploy360@IETF90, Day 5: HOMENET, SIDR, TRANS and GROW… and then we’re done!

IETF LogoYou might think the final day of IETF 90 might be a bit quieter for us… but in fact the morning session from 9:00-11:30 EDT has three sessions happening simultaneously that are related to the work we do (HOMENET, SIDR and TRANS) – and in my personal case I want to be in two separate places at the same time!  (Which I will be attempting to do via monitoring Jabber chat rooms.)   The day will actually start at 8:00am with an informal breakfast meeting of some of the folks subscribe to the DNSSEC coordination mailing list.  After that we’ll be heading into the morning session block where we’ll be choosing between the three conflicting sessions.

One of those three sessions is HOMENET, which Chris described in his Rough Guide post about IPv6:

(HOMENET) is chartered to address the challenges in the evolving networking technology within and among relatively small “residential home” networks. This work is not necessarily dependent on a specific version of IP but the thrust of all discussions within the WG is how the IPv6 protocol suite can better serve these often overlooked networks out at the consumer edge of the Internet. 

The HOMENET agenda is filled with IPv6-related drafts and discussion points… BUT… there is also a DNSSEC angle that I described in my own Rough Guide post:

the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE).  The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services.  The second draft proposes new DHCP optionsthat would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.

The challenge for me is that one floor down in the hotel the TRANS working group will also be talking about DNSSEC.  As I said in the Rough Guide post:

 the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.

Meanwhile, in a room nearby to TRANS, the Secure Inter-Domain Routing (SIDR) working group that focuses on securing BGP will be meeting.  As our colleague Andrei Robachevsky wrote in his Rough Guide post about routing resiliency, there is a great amount of work happening in this group this week.  Of particular interest may be a discussion around “RPKI Revisited” led by Geoff Huston about the Resource Public Key Infrastructure (RPKI). As Andrei writes:

Perhaps a bigger change that is being discussed is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries described by the draft “RPKI Validation Reconsidered”. The problem in a nutshell is that in the current model, specified by RFC 6487, a certificate is considered invalid if a proper validation path cannot be built for all resources specified by that certificate. But in operational reality such a situation can occur, for instance, with the resource transfer, when “shrinkage” of the parent certificate will immediately invalidate the whole branch beneath, unless all subordinate certificates are also re-issued. If such a situation happens high in the hierarchy, say at the RIR level, the impact can be pretty severe. The draft also describes alternative approaches, although the focus of the discussion now is on the problem.

After those three sessions in the first meeting block, the second meeting block really has for us only the Global Routing Operations (GROW) Working Group.  The GROW agenda covers a number of routing security topics, one of which, as Andrei writes, deals with the issue of route leaks:

One of the items, which originally emerged in the SIDR WG and has now also been discussed in the GROW WG, is so-called “route-leaks”. Simply speaking, this describes a violation of a “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer. This introduces the potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/.

After that, our team will be attending the regular meeting of the Internet Society Advisory Council and then will be starting the process of heading home!   As you can tell from our posts, it’s been a VERY busy – but successful – week!

If you’d like to join the HOMENET, SIDR or GROW sessions (or any of the others) remotely to hear the discussion you can follow the instructions on the IETF 90 Remote Participation page or use the “tools-style” agenda page that provides easy links to the audio stream, jabber chat room documents and more for each of the sessions.

The information about the relevant working groups today is:

HOMENET (Home Networking) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/wg/homenet/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)

TRANS (Public Notary Transparency) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)

SIDR (Secure Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/
(Friday, 25 July, 0900-1130 EDT, Territories Room)

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
(Friday, 25 July, 1150-1320 EDT, Ontario Room)

For more background on what is happening at IETF 90, please see our “Rough Guide to IETF 90″ posts on the ITM blog:

If you are here at IETF 90 in Toronto, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.