Category: DNSSEC

Mar 06

Deploy360@IETF89, Day 4: dane, sunset4, v6ops, 6tisch, idr, dbound, eppext, sipcore and dnsop

IETF LogoThe fourth day for our Deploy360 team at the 89th IETF meeting could perhaps best be described as “utter madness” as there are multiple working groups meeting on ALL of the topics we cover here:  IPv6, DNSSEC, securing BGP and even our new TLS for Applications area. In particular, several of the major DNS groups are holding their only meetings today.

Details and links are farther down below (along with remote participation info), but as we mentioned in our pre-IETF89 posts about IPv6, DNSSEC and Securing BPG,  today will bring:

  • The meeting of the DANE Working Group (read more about the DANE protocol).
  • The work in SUNSET4 on phasing out IPv4 and the second meeting of v6OPS focused on operational guidance for IPv6.
  • The 6TiSCH work on IPv6 in resource-constrained “Internet of Things” kinds of networks.
  • The IDR working group has many work items relating to BGP.
  • There is a new DBOUND BOF session that is looking into boundaries in the DNS related to domain names and how those could apply to security policies.
  • In EPPEXT there is an extension proposed for how to securely pass DNSSEC keying material between operators and registries.

Beyond all of those, there are two other Thursday meetings that have come to our attention:

  • In the 1300-1500 block when we already have 3 other sessions of interest, the SIPCORE Working Group is planning a 45 minute discussion on “Happy Eyeballs for SIP” looking at what needs to be done to make SIP work over IPv6. (Where SIP is the dominant open standard used in voice-over-IP.)
  • At the end of the day, a brand new timeslot was opened up from 1840-2040 where the DNSOP Working Group is going to get a head-start on their Friday morning agenda and very specifically focus on the outcome of yesterday’s DNSE BOF around what can be done to protect the confidentiality of DNS queries.  The main point of this evening timeslot is so that TLS can be discussed with some of the people from the UTA Working Group joining in to the discussion (since UTA and DNSOP are scheduled at the same time on Friday morning).

All in all its going to be an extremely busy day for all of us!  We’re looking forward to it, though, as great things are definitely happening!

Thursday, March 6, 2014

dane (DNS-based Authentication of Named Entities) WG
0900-1130 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/

sunset4 (Sunsetting IPv4) WG
0900-1130 UTC, Palace C
Agenda: https://datatracker.ietf.org/meeting/89/agenda/sunset4/(combined with the Multiple Interface (mif) WG meeting)
Documents: https://datatracker.ietf.org/wg/sunset4/
Charter: http://tools.ietf.org/wg/sunset4/charters

v6ops (IPv6 Operations) WG
1300-1500 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/

6tisch (IPv6 over TSCH mode of 802.16e4)
Thursday, March 6, 2014, 1300-1500 UTC, Buckingham Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/ 

idr (Inter-Domain Routing Working Group)
1300-1500 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/idr
Documents: https://datatracker.ietf.org/wg/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

sipcore (Session Initiation Protocol Core)
1300-1500 UTC, Palace C
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/sipcore
Documents: https://datatracker.ietf.org/wg/sipcore/
Charter: https://datatracker.ietf.org/wg/sipcore/charter/

dbound (Domain Boundaries) BOF
1520-1650 UTC, Blenheim Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dbound/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

eppext (Extensible Provisioning Protocol Extensions) WG
1700-1830 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/eppext/
Documents: https://datatracker.ietf.org/wg/eppext/
Charter: http://tools.ietf.org/wg/eppext/charters/

dnsop (DNS Operations) WG
1840-2040 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charter/

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Mar 04

Deploy360@IETF89, Day 2: homenet, sidr, grow, dnse, 6man

IETF LogoDay 2 for the Deploy360 team here at the 89th IETF meeting is a big day for routing and for IPv6. Two of the main routing groups, SIDR and GROW, meet today, and our colleague Andrei Robachevsky recently wrote about the important work happening in both groups to make the Internet’s routing infrastructure more secure.

Two of the important IPv6 groups we are monitoring are meeting today: HOMENET and 6MAN.  Homenet is focused on “home networks” and the role IPv6 plays there.  They are doing some very cool work within the group and a couple of our members are there.  In the afternoon, the 6man group will be looking at changes to the IPv6 protocol. As our colleague Phil Roberts recently wrote, a big focus here will be around efficient neighbor discovery.

Today will also have a “Birds of a Feather” (BOF) meeting for the “DNSE” group.  This is not a formal working group but rather a meeting to talk about some potential areas of work within other groups within the IETF.  As I wrote about in a recent post:

Another feature of today will be the “Internet Society @ IETF89 Briefing Panel” today from 11:45-12:45 UTC where the topic is “Evolution of end-to-end: why the Internet is not like any other network“.  It should be quite an interesting discussion that will also be live streamed out via Google+ / YouTube.

If you are here at IETF 89, please do say hello!  And if you are remote, you can follow along using the information at the bottom of the page and also follow us on Twitter at @deploy360 and also @isoctech.

Tuesday, March 4, 2014

homenet (Home Networking) WG
0900-1130 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/doc/charter-ietf-homenet/ 

sidr (Secure Inter-Domain Routing)
0900-1130 UTC, Balmoral Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/sidr/
Documents: https://datatracker.ietf.org/wg/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

grow (Global Routing Operations)
1300-1400 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/grow/
Documents: https://datatracker.ietf.org/wg/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

dnse (Encryption of DNS request for confidentiality) BOF
1420-1550 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnse/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

6man (IPv6 Maintenance) WG
1610-1840 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6man/ 

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Mar 01

Weekend Project: Add DKIM / DNSSEC Verifier To Thunderbird

dnssec-dkimHere’s an interesting weekend project if you use Mozilla Thunderbird as your email client – add the DKIM Verifier add-on to ensure the validity of signatures on email messages.  The connection to DNSSEC is that the public keys for DKIM are stored in DNS and so DNSSEC ensures that you are getting the correct DKIM keys.

This past week Pier Carlo Chiodi published a great tutorial, “Verifying DKIM signatures on Thunderbird with DNSSEC” that walks through the steps of adding the DKIM Verifier add-on to Thunderbird to verify the signature on the message and validate it all via DNSSEC.

As he notes in his text, this tutorials does the DKIM/DNSSEC validation in the client (Thunderbird) while other solutions might do the validation within the email server itself.

Thanks to Pier Carlo Chiodi for writing this tutorial. This is great to see… now we just need similar tutorials for other email clients!

Note: the image in this article is from Pier Carlo Chiodi’s blog post.

Feb 27

8 Sessions About DNSSEC / DANE / DNS At IETF 89 Next Week

IETF LogoWow! IETF 89 next week in London is going to be an extremely busy week for those of us interested in DNSSEC, DANE  and DNS security in general. As I explained in a post today, “Rough Guide to IETF 89: DNSSEC, DANE and DNS Security“, there are 5 new working groups and BOFs related to DNS and DNSSEC in addition to the three already existing working groups.

I go into a great bit of detail in the Rough Guide blog post, but here are the quick summaries of what is happening this week:

  • The DANE Working Group is focused on how to use the DANE protocol to add more security to TLS/SSL connections. The DANE WG agenda at IETF 89 is about using DANE with email and IM, operational guidance and much more.
  • The DNS Operations (DNSOP) Working Group has a very full agenda with the biggest DNSSEC-related piece being the drafts around how to deal with the critical issue of the uploading of DS records from DNS operators to registries.  Some other great DNSSEC work being discussed there, too.
  • The brand new Using TLS in Applications (UTA) Working Group that has as a primary goal to deliver a set of documents that are “go to” security guides aimed at helping developers add TLS support into their applications.  We’re interested in the potential DNSSEC/DANE connection there.
  • The new Public Notary Transparency (trans) Working Group on Wednesday that is looking at how to update the experimental RFC 6962, “Certificate Transparency”, to reflect recent implementation and deployment experience.  Our particular interest is that part of the charter is to ensure that this mechanism can work in the presence of DANE records in addition to regular web certificate-based system.
  • The new EPP Extensions (eppext) working group that is focused is looking at draft-ietf-eppext-keyrelay that defines a mechanism that can be used to securely transfer a DNSSEC-signed domain from one operator to another.
  • The “Encryption of DNS requests for confidentiality” (DNSE) BOF is exploring how to protect the confidentiality of DNS requests from sniffing.   The DNSE BOF will use draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality as starting points for discussion.
  • The Domain Boundaries (dbound) BOF is looking at how domain names are used in setting security policies.  Our interest is in understanding how this may fit into the other DNS security components of the work we are doing such as DNSSEC and DANE.
  • The Extensions for Scalable DNS Service Discovery (dnssd) Working Group is continuing their discussions about how DNS-SD (RFC6763) and mDNS (RFC6762) can be used beyond the local network. Our interest is in how this all gets done securely.

We will finish out the week with a breakfast meeting Friday morning with people involved in the DNSSEC Coordination effort (and anyone can join the mailing list) where we’ll have some conversation and food before heading off to the DNSOP and/or UTA working groups.

It’s going to be a crazy-busy week… but I’m looking forward to seeing all that we can get done!

Relevant Working Groups and BoFs

dnssd (Extensions for Scalable DNS Service Discovery) WG
Monday, March 3, 2014, 1300-1500 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: https://datatracker.ietf.org/wg/dnssd/charter/

dnse (Encryption of DNS request for confidentiality) BOF
Tuesday, March 4, 2014, 1420-1550 UTC, Viscount Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnse/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

trans (Public Notary Transparency) WG
Wednesday, March 5, 2014, 1520-1620 UTC, Blenheim Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/

dane (DNS-based Authentication of Named Entities) WG
Thursday, March 6, 2014, 0900-1130 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/

dbound (Domain Boundaries) BOF
Thursday, March 6, 2014, 1520-1650 UTC, Blenheim Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dbound/
List of BOFs: http://trac.tools.ietf.org/bof/trac/

eppext (Extensible Provisioning Protocol Extensions) WG
Thursday, March 6, 2014, 1700-1830 UTC, Park Suite
Agenda: https://datatracker.ietf.org/meeting/89/agenda/eppext/
Documents: https://datatracker.ietf.org/wg/eppext/
Charter: http://tools.ietf.org/wg/eppext/charter/

dnsop (DNS Operations) WG
Friday, March 7, 2014, 0900-1130 UTC, Sovereign Room
Agenda: https://datatracker.ietf.org/meeting/89/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charter/

uta (Using TLS in Applications) WG
Friday, March 7, 2014, 0900-1130 UTC, Richmond/Chelsea/Tower Rooms
Agenda: https://datatracker.ietf.org/meeting/89/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charter/

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

Feb 25

SSAC Issues New Report On DDoS Attacks Against DNS

SSAC logoWhat can be done to prevent Distributed Denial of Service (DDoS) attacks against the DNS infrastructure? What can individuals or organizations who operate DNS servers do to their own systems to help reduce the threat of DDoS attacks?   ICANN’s Security and Stability Advisory Committee (SSAC) took on this issue recently and released a new report this week: “SAC065: SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure“.  It is available as a free PDF download in English.

While the report is not about DNSSEC, per se, it is about the overall issue of “DNS security” and outlines steps that can be taken to reduce the potential of DNS-based DDoS attacks.  This is critical if we are to get DNSSEC more widely deployed because there are some DNS server operators who have pushed back about DNSSEC citing concerns about the larger size of DNSSEC packets could help amplify DDoS attacks.

The recommendations for the industry include the following (with the report providing more detail on each):

Recommendation 2: All types of network operators should take immediate steps to prevent network address spoofing.

Recommendation 3: Recursive DNS server operators should take immediate steps to secure open recursive DNS servers.

Recommendation 4: Authoritative DNS server operators should investigate deploying authoritative response rate limiting.

Recommendation 5: DNS operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of latest developments.

Recommendation 6: Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replacing the installed base of non-upgradeable devices with upgradeable devices.

We agree with those recommendations and definitely encourage people to read the SSAC report and implement as many recommendations as possible.

Working together we can make the Internet more secure!

Feb 22

Weekend Project: Join the XMPP “Security Test Day” today to test DNSSEC / DANE

XMPP logoIf you have a bit of time today, February 22, 2014, and want to help an effort aimed at making the Internet more secure, the XMPP Standards Foundation (XSF) is holding their second “Security Test Day” today.  The goal is to encrypt all traffic between servers and clients on the public network of XMPP servers. (Note that some of you may be more familiar with XMPP as its original name of “Jabber”.) This is all laid out in their manifesto for ubiquitous encryption on the XMPP network.

The connection to the work we are doing here at the Deploy360 Programme is that many of the XMPP servers have DNSSEC-signed domains and many are implementing DANE to secure the usage of TLS/SSL certificates in both server-to-server and client-to-server communication.  The XSF provides guidance on securing DNS via DNSSEC for XMPP servers and the IM Observatory provides two lists of interest:

It is outstanding to see the number of servers that have implemented both DNSSEC and DANE!  

Anyway, if you have an XMPP server, or want to set one up, today is a test day when the XMPP community is working on encrypting all their communication.  Visit their “Second Security Test Day” post to understand more about how you can participate.

This is great work that will definitely help make part of the Internet more secure. If you have time to help today, it would be great!

Feb 21

NIST Offers New Tool To Verify TLSA Records For DANE / DNSSEC

Are you experimenting with using the DANE protocol to provide an additional layer of security to your TLS/SSL certificates via DNSSEC?  Would you like to easily test that your TLSA record needed for DANE works correctly?

If so, the folks at the US National Institute of Standards and Technology (NIST) now have a new tool for testing TLSA records and DANE support.  All you do is go to:

https://www.had-pilot.com/dane/danelaw.html

and in the simplest form just enter in the URL of the site you want to test.  Here is an example of what happened when I entered https://www.freebsd.org/ (click image to see larger version):

dane-tls-testing-nist-tool

 

The site basically tests that you have your TLSA record correctly configured and that it matches the TLS/SSL certificate you are using with your web server.

Now, if you don’t have a site with a TLSA record but want to see how the tool works, the NIST tool helpfully lets you choose from one of the DANE test sites we list here on Deploy360.  You can also connect to the NIST “DANE Reference site” to explore different usage types.

In an email message to several public mailing lists, tool author Stephen Nightingale at NIST indicated that his latest version of this tool was now offering the choice of testing from clients based either on TLSlite or GnuTLS. He goes on to note:

Mine was one of the ‘DANE-in-the-App’ sites that Viktor Dukhovni reviewed, and he kindly gave an extensive critique. Many of his points have been addressed. A few things still to clear up:

  • I’m not checking for certificate revocation. That is on the list to fix.
  • For 0xx and 1xx uses, it is hard to identify a single canonical CA list. I have overlapping, but different Root Cert sets from Mozilla, Fedora and Linux Mint. So when searching for an authority to build a verification chain I cycle through all of these until succeeding or exhaustion of the possibilities. Some of the DANE 360 listed sets (including some from members of this group) fail to authenticate because the root certs are not in my authorities. A golden, canonical CA list would be nice to find. But I guess that its non-universal availability is one of the problems of the CA system that DANE is aiming squarely at.

The differences between TLSlite and GnuTLS clients highlight the fact that there are unresolved interoperability issues among TLS implementations. It seems reasonable that TLS interoperability testing be instituted as pre-requisite to DANE testing. The development of a TLS Interoperability test suite is therefore on our ‘to-do’ list. I look forward to seeing the newly upgraded OpenSSL client with added DANE. It is quite possible that as an interim step before its appearance I will add this DANE-in-the-App implementation to pyOpenSSL and/or Twisted.

Thanks to Stephen and the team at NIST for making this tool public and we hope that it will help those of you working with DANE to test out your implementations.

Feb 20

Update on DNSSEC Deployment Maps: Github repo for tracking issues, newgTLDs, more…

2014-01-23-2014-01-23The positive reaction to our publishing of DNSSEC deployment maps has been great to hear and I wanted to provide a quick update.

1. The DNSSEC deployment maps are published every Monday. The best way to receive the most current maps is to subscribe to the dnssec-maps mailing list.   I will be updating our DNSSEC Deployment Maps web page from time to time when there are major changes, but the most recent maps will always go out to the mailing list.  (I’d love to automate the posting to the web page – ideas about how to do so in WordPress are definitely welcome!)

2. There is a Github repository where you can file issues/suggestions. In preparation for making the source code publicly available, we’ve created a repository on Github at https://github.com/Deploy360/dnssec-maps/ We still need to do make some changes to the code to make it publicly available, but in the meantime the major feature of the Github repo is that we now have a convenient place to track “issues”, which could be bugs or feature ideas or more.  If you have a Github account (or want to create a free one), you are welcome to raise issues at:

https://github.com/Deploy360/dnssec-maps/issues

I don’t have a timeframe for when we’ll make the code available – it’s honestly a bit of a background task that I’m trying to fit in amongst everything else and with IETF 89 fast upon us it may not happen for a few weeks.  Meanwhile, though, the issue tracker is already being helpful.

3. All newgTLDs have been entered up to now. I finally caught up with the backlog of all the DNSSEC-signed “new generic top-level domains (newgTLDs)” that have been delegated by ICANN and now have a DS record in the root zone.  These newgTLDs don’t show up in the DNSSEC deployment maps but do show up in the CSV files that are emailed out every Monday.  Given that ICANN is delegating more newgTLDs on a weekly basis, it will be a constant effort to update our database, but at least now we’re caught up to the present time.

4. Visualizing the DNSSEC status of the generic TLDs is of interest. As I noted in a recent post here, I would like to think about how we could provide an image in the email that visualizes the DNSSEC status of all the generic TLDs, both the “newgTLDs” and all the ones that existed before.  Suggestions and ideas would be welcome, either to this post or to the “issue” on Github.

That’s the quick update… I am glad some folks are finding this service useful and welcome any comments and feedback.  Thanks!

Feb 18

How Can We Visualize Generic TLDs (and newGTLDs) In Our DNSSEC Deployment Maps?

Idea for visualizing generic TLDsWhat is the best way to visualize the DNSSEC deployment status of the “generic top-level-domains (gTLDs)” in our DNSSEC deployment maps that go out weekly?  Obviously since gTLDs (including the “newgTLDs”) are not tied to a country, there is no way to display them on an actual map as we do for all the ccTLDs.

Given that, how else could display the gTLDs in a way that is useful?   Right now, their DNSSEC deployment status is included in the CSV files that are sent out to subscribers of the dnssec-maps mailing list (to which anyone can subscribe).  But could we create an image of some type that showed the different deployment states?  Perhaps something like the image in this post (only with the actual Unicode characters)?

And what would be the best way to do that given that we’ll soon have hundreds and maybe even thousands of generic TLDs?

My primary interest is to have some image that we can use in presentations (or on a website) that visualizes the current state of DNSSEC deployment within the gTLDs.  We’re tracking the data in our database… we just need some way to make it more interesting then simply a list out of a CSV file.

I’d be curious to hear any feedback you all may have, either left as a response to this blog post, as a comment on the issue I opened up on Github, in social media where this is posted or as email back to us.

And then, of course, I need someone with sufficient python background working with image-generation libraries who can help make the visual image a reality…   but let’s perhaps figure what we want first, eh?

Feb 16

DNS-OARC Spring Workshop May 10-11, 2014 in Warsaw

dns-oarcThe 2014 Spring Workshop of the DNS Operations Analysis and Research Center (DNS-OARC) will take place May 10-11, 2014, in Warsaw, Poland, on the weekend right before RIPE68 in Warsaw.

The DNS-OARC events are great workshops that bring together many of the leading people within the DNS / DNSSEC community. For some background you can see the agenda and contributions from the Fall 2013 workshop in Phoenix, as well as the videos of the sessions.

The Call For Presentations for the 2014 Spring Workshop is now out with a submission deadline of March 1, 2014.  If you are going to be going to RIPE68, why not go the weekend earlier and participate in the DNS-OARC Spring Workshop?