Category: DANE

Dec 20

Call For Participation – Submit Your Idea For The ICANN 49 DNSSEC Workshop In Singapore

ICANN 49 LogoDo you have an idea for a great presentation you’d like to give around DNSSEC?  Perhaps a demonstration of a new tool or service?  Or new DNSSEC statistics or measurements?  Or a new application that works with the DANE protocol?

If you’re going to go the ICANN 49 meeting in Singapore in March 2014, there will be another DNSSEC Workshop happening on Wednesday, March 2014 and the program committee is actively looking for proposals for presentations.  We’d particularly be interested in including some demonstrations this time now that DNSSEC and DANE are getting more widely deployed.

The full Call for Participation is included below.  If you have an idea, please email a couple of sentences about your idea to dnssec-singapore@shinkuro.com.

Call for Participation — ICANN DNSSEC Workshop 26 March 2014

DON’T READ THIS MESSAGE!  We know it’s the holiday season and many of you will ignore this message completely, so we’ll be sure to send another message in early January – but  for those of you who might have some time over the holidays to think about ideas for a presentation related to DNSSEC, please read on…

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 meeting in Singapore on 26 March 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 Buenos Aires, Argentina on 20 November 2013. The presentations and transcripts are available at: http://buenosaires48.icann.org/en/schedule/wed-dnssec.

We are seeking presentations on the following topics:

1.  DNSSEC Activities in the Asia Pacific region:

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the Asia Pacific 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?

2. 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?

3.  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.)?

4.  DNSSEC and DANE In The Enterprise

Similar to ISPs, enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the enterprises’s own domains. We are seeking presentations from enterprises who have implemented DNSSEC on either or both validation and signing 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?

5.  DANE and DNSSEC Applications

The DNS-based Authentication of Named Entitites (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. 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 used 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.

6.  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?

7.  Preparing for Root Key Rollover

For this topic we are seeking input on issues relating to root key rollover.  In particular, we are seeking comments from vendors, ISPs, and the community that will be affected by distribution of new root keys.

8.  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 in the various pieces that make up DNSSEC signing and validation are the best opportunities for automation?
* What are the costs and benefits of different approaches to automation?

9.  Guidance for Registrars in Supporting DNSSEC:

The 2013 Registrar Accreditation Agreement (RAA) for Registrars and Resellers requires the support of DNSSEC beginning on 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.

10.  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.  Right now the communication, such as the transfer of a DS record, occurs primarily 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.

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-singapore@shinkuro.com by **Friday, 31 January 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
Lance Wolak, .ORG, The Public Interest Registry
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Dec 06

Want To Quickly Create A TLSA Record For DANE / DNSSEC?

Generate-TLSA-Record-3Would you like to use the DANE protocol to secure your SSL/TLS certificate via DNSSEC?  If so, the first step is to generate and publish a “TLSA record” in DNS – and that record generation can be a stumbling block for some people.  While there are command-line tools such as just the basic “openssl” or Paul Wouter’s “hash-slinger“, Shumon Huque recently released a web interface that lets you easily create a TLSA record.  As Shumon writes about on his blog, the tool is at:

https://www.huque.com/bin/gen_tlsa

All you need to do is to set the type of TLSA record you want to create, paste in the X.509 certificate, and enter the appropriate port number, protocol and domain name.  Shumon’s script then generates the appropriate TLSA record that you can paste into your DNS zone file.

Last year, Shumon wrote a post on “DNSSEC and Certificates” where he walked through how to do this using openssl on the command line – this latest post now builds on that to make it even easier.

It’s excellent that Shumon has made this tool available and we look forward to seeing many more TLSA records out there!  (If you have a SSL/TLS cert for your website, how about adding a TLSA record today?)

Dec 02

Afnic Publishes Issue Paper: “Securing Internet Communications End-to-end Using DANE Protocol”

Afnic paper on DANELast week, the great folks over at Afnic released an outstanding issue paper about how the DANE protocol and DNSSEC can bring a higher level of trust and security to Internet-based communications.  The issue paper, “Securing End-to-end Internet communications using DANE protocol“, is available in PDF (direct link) and walks through how DANE can be used to increase the security used in TLS/SSL certificates (PKIX).  The document describes the problems associated with the current world of certificates and then explains how DANE can make the situation more secure.

Readers of this Deploy360 site will know that we’ve produced similar types of documents ourselves, but not in an “issue paper” form that can be distributed.  The Afnic folks have done a great job with this and I like the graphics they are using.

As they note on the final page, DANE is for much more than web browsing – and in fact the major implementations we’re seeing right now are in other services like email and XMPP (Jabber). The browser vendors have so far not seen enough requests (we are told) to look at including DANE in their browsers.

Hopefully this document from Afnic will help people further understand the very real value DANE can bring in ensuring that you are using the correct TLS/SSL certificate when you are connecting to a web site.

Kudos to the Afnic team for creating this document – and I encourage everyone to share this document widely! (Thanks!)

Nov 01

4 Sessions About DNSSEC, DNS And DANE At IETF 88 Next Week

IETF LogoNext week IETF 88 in Vancouver will be a bit quieter on the DNSSEC and DANE front.  As I wrote in a post today on our “Internet Technology Matters (ITM)” blog, “Rough Guide to IETF 88: DNSSEC, DANE and DNS“, the only major working group related to DNSSEC that will be meeting will be the DNSOP WG on Tuesday, November 5th.  However, in that meeting there will be the very big topic of how we automate the transfer of updated DS / DNSKEY records from a child zone up to a parent zone within DNS.  There are  a couple of different proposals that will be discussed, including:

It should be an excellent discussion.  As I wrote in the ITM post, there are several other interesting drafts as well being discussed in DNSOP – all focused around improving the operations of DNSSEC.  It should be a great session at IETF!

The DANE Working Group is not meeting but as I mentioned in the other article I expect that DNSSEC / DANE will come up in some of the many conversations that will be going on next week related to how we harden the Internet against large-scale surveillance and pervasive monitoring.  The Technical Plenary on Wednesday, November 6, should be an excellent event well worth listening to.   The “Perpass” BOF session will dive into more details. I don’t know if DNSSEC / DANE will be discussed there… but it certainly could be.

The DNS-SD Working Group discussion could also be quite interesting because as you extend DNS service discovery beyond a simple local network into a multi-network environment, you need to have some way to securely communicate that information.  We’ll see what is begin talked about in that regard.

Anyway, here are four of the sessions where DNSSEC / DANE / DNS will be discussed – you can expect to find me in all of them:

NOTE: If you are not going to be in Vancouver next week, there are multiple ways that you can participate remotely in these working groups, including audio streams and Jabber chat rooms.

Oct 31

Knot DNS

Knot DNSKnot DNS is an authoritative DNS name server that can be used to serve out zone records and includes support for DNSSEC and DANE.  One of the key design goals is to provide simple DNSSEC support for dynamic DNS.  Knot DNS is developed by the team at CZ.NIC and can be found at:

https://www.knot-dns.cz/

It is available pre-packaged for several versions of Linux and also as source code as a release or directly from a git repository.

Knot DNS is highly scalable and used by CZ.NIC for the operation of the .CZ TLD. It was developed with the target audience of network operators and DNS operators in mind but can be used by anyone needing to serve out DNS records.

For an overview of Knot DNS, you can view this short video interview with Jaromir Talir of CZ.NIC:

Prior to this interview, Jaromir had spoken on stage at ENOG 6 in Kiev, Ukrain, in more detail about Knot DNS. His ENOG 6 slides about Knot DNS are online and a video recording of his presentation is available:

Oct 01

Speaking at ENOG6 On Oct 2 About DNSSEC And DANE – Will Be Streamed Live

ENOG LogoWhat is the current status of DNSSEC deployment? What is going on with DANE? What are some of the remaining challenges?

Tomorrow, Wednesday, October 2, 2013, I’ll be speaking about these DNSSEC/DANE topics at the “Eurasia Network Operators Group (ENOG) 6” event happening in Kiev, Ukraine.

My particular presentation is in the plenary block beginning at:

  • 15:00 Eastern European Summer Time (EEST), which will be
  • 14:00 in most of Europe (CEST) and
  • 8:00am US Eastern.

I’m the second presentation in the block and so I’ll start whenever the previous presenter finishes… probably sometime around 15:30.  My talk will be probably around 30 minutes at the most.

The session will be streamed live as part of the ENOG webcast available at:

http://www.enog.org/live-stream/

(And no, I don’t think the actual livestream is available over IPv6, as we did yesterday, but the ENOG website is available over IPv6.)

If you’d like a preview, my slides are available from the ENOG6 Presentations page, in both PDF and PPT.

I’m looking forward to giving the presentation… it’s a good group of people here at ENOG.  They also do NOT typically hold back in terms of asking questions from the microphones which makes for good sessions and dialogue.

And if you are at ENOG6, please do say hello… I’ll be around all day tomorrow (and am here tonight).

Sep 12

FreeBSD 10 To Include OpenSSH With DNSSEC Support (for SSHFP records)

freebsd-logoVery cool news out of the FreeBSD team yesterday… the upcoming FreeBSD 10 will include support in OpenSSH for DNSSEC. The key point is this:

This means that OpenSSH will silently trust DNSSEC-signed SSHFP records.

What this means is this: when you go to ssh into an unknown system (i.e. one that is not in your “known_hosts” file), OpenSSH will do a query for a SSHFP record and use DNSSEC validation to ensure that the SSHFP record is indeed the one that the domain operator wants you to use.

This process of using a SSHFP record was defined in RFC 4255 back in 2006.  If you are familiar with how ssh (a.k.a. “secure shell“) works, when you connect to an unknown system for the first time you are presented with the “fingerprint” of the public key of the server to which you are connecting.  In theory you could verify this fingerprint through some out-of-band mechanism (perhaps seeing it on a web page or having received it separately in an email).  In practice, the vast majority of people just hit enter/return or type “yes” or something like that.

In the RFC 4255 mechanism, the operator of the server would publish a SSHFP record in DNS that would have the fingerprint of the SSH public key.  This is the same key fingerprint that would normally be presented to a user.  By using DNSSEC to sign the DNS zone that includes the SSHFP record, the server operator can provide a method for a DNSSEC-validating SSH client to verify that the SSH fingerprint is in fact the one that should be used to connect to the server.

This creates a higher level of trust and security in SSH connections.

It’s great to see this added to FreeBSD 10, which, according to the FreeBSD Release Engineering page, should be available sometime in November 2013.

For those curious, the SSHFP record is similar to what was defined six years later in RFC 6698 for the DANE protocol, which is really no surprise as they share a common author, Jakob Schlyter.  DANE’s TLSA record is a bit more complex and, for instance, allows for the inclusion of a complete SSL/TLS certificate rather than just a fingerprint.  In both cases, though, the idea is the same – use a DNS record to provide a means to verify a public key, and use DNSSEC to provide integrity protection so you know that you can trust the DNS record.

Great to see this being rolled out in an enabled state. Kudos to the FreeBSD team for doing this!

Jul 31

Slides: Introduction To The DANE Protocol

At the DNSSEC Workshop earlier this month at ICANN 47 in South Africa, I gave an introductory tutorial about the DANE protocol and how it can be used to secure Internet communication such as that through a web browser. I explained how DANE works, outlined some use cases and provided a series of links for people to learn more. The slides are now online:

I did record a video of the presentation and hope to get that uploaded in the next couple of (busy!) weeks.

More information about DANE can of course be found on our page about the DANE protocol.

Jul 25

“Rough Guide To IETF 87″ Now Available – IPv6, DNSSEC, Routing and much, much more…

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF), taking place this time in Berlin, Germany, and it will be an incredibly busy week as something like 1,200-1,500 engineers gather in a hotel meeting space to debate and discuss various topics and create the open standards that power the Internet.  There are many different working groups meeting during the week and the IETF 87 agenda can seem a bit overwhelming.  To help with that, as we’ve done in the past, the Internet Society has published our “Rough Guide to IETF 87″ available at:

http://www.internetsociety.org/rough-guide-ietf87

This document reflects our (Internet Society) interests and what we see as the important topics related to the technology priorities we have an an organization.  The working groups and events listed are ones where we have Internet Society staff participating or where the topic being covered is one of our priorities.

For instance, within our team here at Deploy360, we’ll be there in Berlin at the working groups related to:

  • IPv6
  • DNSSEC
  • Routing resiliency and security

Most of which, but not all, are captured in the Rough Guide.  As we noted in an earlier post about DNSSEC activities, there are two groups focused on DNSSEC and DANE that are of great interest to us.  There are a wide number of IPv6-related groups in which we’ll be participating and several groups related to routing resiliency and security.

If you are reading this page here on our Deploy360 site, hopefully the Rough Guide will help you understand where we will be spending our time.

There are, of course, a great many other working groups meeting next week at IETF 87 that are doing outstanding work in Internet infrastructure, applications, routing, security, real-time communications, network operations and so much more.  The full agenda for IETF 87 is an amazing list of all the great open standards work happening across the IETF!

NOTE: If you unable to attend IETF 87 in Berlin in person, there are numerous methods of remote participation that you will allow you to listen to what is going on and to provide comments.

Jul 23

2 DNSSEC / DANE Sessions Next Week At IETF 87 In Berlin

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF)  in Berlin, Germany, and there will be two working groups meeting that are related to DNSSEC on the agenda:

DNSOP

The DNSOP (DNS Operations) Working Group will meet on Thursday, August 1, from 1520-1650 (Berlin time) in the Bellevue room.  There are 3 major items on the DNSOP agenda, but the one of strong importance related to DNSSEC is the discussion about how to communicate that there has been a change in the Key Signing Key (KSK) from a child zone up to a parent zone.  In other words, when you create a new KSK for your child zone, can we get an automated way to communicate the existence of this new KSK to the parent zone so that a DS record can be created and the global chain of trust can be updated?

Somewhat ironically, I experienced this precise issue myself last week when, during the DNSSEC Workshop at ICANN 47, a KSK on one of my personal zones expired.  The company providing DNS hosting for that domain automatically generated a new KSK, but they have no way of alerting the parent zone (.ORG in this case) that a new DS record is ready for upload.  I had to login to the web interface for my registrar and copy/paste the DS record from the web interface of my DNS hosting provider.  Meanwhile, my domain was failing validation.

There are two different proposals for mechanisms to automate this process.  Warren Kumari, Olafur Gudmundsson and George Barwood submitted draft-kumari-ogud-dnsop-cds that proposed the creation of a new “CDS” record type in DNS.  Essentially, the parent zone will periodically poll the child zones and if a new CDS record is found the parent zone will update the DS record for the zone.  Separately, Wes Hardaker developed draft-hardaker-dnsop-csync providing a similar but broader mechanism for synchronizing child and parent zones. This draft involves the creation of a “CSYNC” record type in DNS which tells the parent zone which records in the child zone need to be updated in the parent zone.  Wes originally wrote the draft to look at how to synchronize NS records and their associated A and AAAA records (what we often call “glue” records) between child and parent zones but then added support for DS and DNSKEY records to stimulate further discussion.

At DNSOP there will be a joint presentation about the two drafts with an interest in looking at “where do we go from here”.  It should be an interesting discussion and if you are unable to attend in person you can listen to the remote audio stream at the specified time.

DANE

Right after DNSOP, the DANE Working Group will meet on Thursday, August 1, from 1700-1830 (Berlin time) in the Potsdam 1 room.  With RFC 6698 now specifying the DANE protocol the WG is focused more on how DANE will be used by various services.  The agenda has not yet been posted, but there has been active discussion on the DANE mailing list about drafts relating to using DANE with email (both SMTP and S/MIME) and with voice-over-IP (SIP) as well as with OpenPGP and OTR.  As someone who sees DANE as a powerful reason to deploy DNSSEC, I’m very much looking foward to the discussion in this group and to seeing where DANE is going.

If you are unable to attend IETF 87 in person, you will be able to listen remotely to the DANE working group at its specified time.