Category: Developers

Join the DNS Security team at the IETF 96 Hackathon this weekend…

IETF 96 Hackathon

If you will be in Berlin, Germany, this weekend and are interested in putting your coding or documentation skills to good use in helping make DNS more secure, please plan to join a group of about 20 of us at the IETF 96 Hackathon who will be working on DNS-related projects. The Hackathon is at the InterContinental Hotel from 9:00am – 9:00pm on Saturday, July 16, and from 9:00am – 6:00pm on Sunday, July 17. (You don’t have to be there the whole time – some people come and go.)

NOTE: you do NOT have to be attending IETF 96 to participate in the Hackathon. It is separate – and free – but you do need to register to attend. We welcome other developers in the Berlin area who want to join us during the weekend.

Details can be found on the IETF 96 Hackathon wiki page.

We have a group of 20+ people who will be working on a variety of DNS, DNSSEC, DPRIVE and DANE projects. There are some projects that could use some additional help (including non-coding help such as documentation and user testing). You are also welcome to bring other projects to the Hackathon.

You can see the list of projects and ideas on the IETF wiki hackathon page – although you need to scroll down to find the DNS section.

The GetDNS crew has a number of projects underway, including TLS interfaces, a Universal Acceptance review and RFC5011 testing. Rick Lamb plans to make BIND work with smartcards without patches. I plan to work on the code behind the weekly DNSSEC deployment maps. I’m sure others will bring some projects, too, by the time it begins.

A good group of “DNS people”  have now done this for the past several IETF meetings. It’s been a great experience and moved a number of DNS-related projects forward.  We would definitely welcome anyone else who wants to join us, even if just for part of the time.  Bring your coding and documentation skills and help make DNS better!

P.S. And of course you can also join in with the many other excellent projects happening at the Hackathon, too, including some great work on TLS implementations.  We here at Deploy360 just happen to be focused on DNS…

Links To DNS / DNSSEC / DANE / DPRIVE Projects From IETF 93 Hackathon

With IETF 94 starting this weekend in Yokohama, Japan, I realized that I had not posted the results of the great work that the “DNS team” did at the IETF 93 Hackathon back in July in Prague.  Here’s a slideshow that outlines the results:

Slide 2 really shows the different aspects of “DNS security” that the team worked on:

Summary of DNS work at IETF 93 hackathon

Perhaps the more important fact was that we had actual code released publicly. Here were the releases:

And yes, this last one was a little experiment in playing with JSON and python that I did.

To our amazement, our DNS team (which grew from the time we first started talking about it) received the “Best in Show” award based on the judges’ view of what we did.  Here was a photo of some of the team and some of the judges (when the winners were announced some team members had already gone to other meetings):

DNS team at IETF 93 hackathon

There will be another “DNS team” at the IETF 94 Hackathon this weekend and while I won’t be there myself, I do hope they have a great time!

P.S. If you want to get started with DNSSEC and DANE yourself, please visit our Start Here page!

IETF 93 Hackathon July 18-19: DNSSEC, DANE, DPRIVE and DNS Security

IETF HackathonHow can we improve the tools and services that use DNSSEC or DANE?  How can we make DNS more secure and private? (And, why spend a beautiful weekend exploring Prague when we could be inside a hotel conference room working on code???) For a number of us, we’re going to be spending this coming weekend, July 18-19, looking to answer those questions through writing code and changing/updating software as part of the IETF 93 Hackathon.  More info is at:

As IETF Chair Jari Arkko wrote about on the IETF blog, these hackathons are a way to bring “running code” back into the IETF meetings – and also just a great way to advance the deployment and usage of IETF protocols.  They are also just a fantastic way to strengthen the relationships between members of the IETF community.

I’ll be there as one of the “champions” of DNSSEC / DANE / DPRIVE (DNS confidentiality/privacy) along with Allison Mankin, Benno Overeinder, Sara Dickinson and Daniel Kahn Gillmor.  A number of others from within the DNS community have also signed up to join in to the effort – and we’re hoping to attract some of the other participants as well.

On the wiki page listing the technologies, we wrote this for some of the ideas:


  • Contribute to access of end-systems to new developments in DNS
  • Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc.
  • Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc.
  • Measurement: New tools or sites for measuring DNSSEC or DANE deployment


We’ve had some other ideas, too… we’ll see what we come up with!  (And you’re welcome to send me your ideas for tools you’d like to see!)  I’m personally interested in expanding some of the metrics… and I’m also interested in anything that expands the usage or support of the ECDSA algorithm (I’m thinking more about … what interfaces could be extended to add ECDSA support?)

I’ll post a report back here on the site once the hackathon is over.  If you are going to be at the Hackathon at IETF 93, please do consider joining with us!

P.S. And if you want to get started with DNSSEC and DANE, please see our Start Here page!

Apple Will Require IPv6 Support For All iOS 9 Apps

Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement, starting with iOS 9.”  With those words, Sebastien Marineau, Apple’s VP of Core OS, gave a huge boost to IPv6 developer support in Apple’s WWDC Platform State Of The Union (SOTU) address yesterday.

You can watch the Platform SOTU presentation yourself (although you may need the Safari browser to do so). The IPv6 segment begins at 34:16 and Marineau’s statement about the AppStore requirement can be heard at 37:16.

Here, though, is the quick summary.

Why IPv6?

Sebastien Marineau began by talking about IPv6 and why it is important:

Apple IPv6 support

more on IPv6 support

In particular he noted that carriers in several regions of the world are now deploying IPv6-only networks and emphasized the importance of making your application work well for everyone, everywhere.  He reinforced how critical it is to support IPv6:

“If your application doesn’t work properly with IPv6, it will simply not function on those networks, those carriers and for those customers.”

He also explained how Apple has supported IPv6 for over ten years now since early versions of Mac OS X and from iOS 4 onward.

3 Steps For Developers

He went on to explain three steps all developers can take to make sure their applications work over IPv6 networks:

3 steps to make an app work with IPv6

Those steps are:

  • Use the networking frameworks (for example, “NSURLSession”)
  • Avoid use of IPv4-specific APIs
  • Avoid hard-coded IP addresses

Essentially, if app developers are using the higher level APIs and frameworks and aren’t hacking around at the IP layer, their apps should probably “just work” on top of either IPv4 or IPv6.

Testing Your App Over IPv6

However, Martineau addressed the question of “how do you test your app over IPv6?“, particularly when many app developers may not have access to a native IPv6 Internet connection.  He indicated that in an upcoming release of Mac OS X there will be a new feature to help with this:

IPv6-only personal hotspot

What I understood Martineau to say was that you will be able to set up a “personal WiFi hotspot” on your Mac and check an “IPv6-only” box.  Your iPhone/iPad with your app could then connect to that specific WiFi network to work in an IPv6-only mode.  The Mac would then provide the gateway to the legacy IPv4 Internet so that the app on the IPv6-only network could connect out to services on IPv4 servers.

THIS IS HUGE! One of the struggles many application developers have had is to easily create an “IPv6-only” network in which to test systems.  Even those of us who are IPv6 advocates/enthusiasts have struggled with making this work well.  It typically involves bringing up a second access point (which you are effectively doing with this new configuration) and then turning off all IPv4 services on that access point, which some access points make difficult to do.

Whenever this feature rolls out in Mac OS X, it will greatly help all of us who are working on apps and systems and want to test them in an IPv6-only environment.

An Important Step

Now, to be clear, most iOS app developers probably won’t have to do all that much to support IPv6.  If they are already using the higher level APIs and networking frameworks they should be all set.  The exact mechanisms of IP address handling are not a concern of theirs.  However, some app developers will have to make some changes, particularly if they are directly using IPv4 addresses as any kind of identifier or in logging.

More importantly, the requirement for AppStore submission will require app developers to test their applications with IPv6 networks, and that alone will suddenly cause the millions of iOS app developers out there to have to learn at least something about IPv6 (if nothing else, the fact that it exists).

Most significantly, though, this step by Apple means that all the iOS apps that run on iOS 9 will work well over the IPv6-only networks that are starting to be deployed.  Even in dual-stack (IPv6/IPv4) networks, this should mean that iOS 9 apps will work better in those environments when, for instance, IPv6 may be faster. (More needs to be understood here about the specifics of the IPv6 support.)

And… this also will help take away the argument used by some network operators who are still not moving ahead with IPv6 that “why should we deploy IPv6 when apps don’t support it?”

Apple’s answer is that, as of iOS 9, all iPhone/iPad apps will support IPv6!

Kudos to Apple for taking these steps, creating this new AppStore submission requirement, and also providing what sounds like a new and easy way to create IPv6-only networks!

We’re looking forward to iOS users being able to use ALL their favorite applications on an IPv6-only network!

P.S. If you want to get started with IPv6, please visit our Start Here page to find resources tailored for your role or type of organization.  The time to make the move to IPv6 is TODAY!

Also, hat tip to Adam Iredale on Twitter, who first brought this new requirement to my attention, and to Borja Reinares who provided some more information.

TLS-O-MATIC Now Available To Test TLS In Applications

TLS-O-MATIC logoDo you want to test how well your application supports TLS over HTTP?  If so, you can now head over to:

and run your application through a whole series of self-tests.

As he explains in a blog post announcing TLS-O-MATIC, Olle Johansson launched the site as a public service with 15 tests for the HTTPS protocol.

I’ve known Olle for many years through his work seeking to add security to various voice-over-IP (VoIP) services and protocols – and in recent years he has been focused around the idea of getting more encryption deployed.  He typically uses the “#MoreCrypto” hashtag on Twitter and other services – and we wrote about his #MoreCrypto 2.0 slide deck he released back in December 2014.

Some of the tests included in TLS-O-MATIC are:

  • Bad hostname
  • One cert, multiple names
  • Wildcard certificate
  • Not yet valid certificate
  • Expired certificate
  • Unknown CA
  • Client certificate
  • Weak certificate
  • Intermediate certificate
  • Chain of trust
  • A huge certificate
  • A strong key
  • Wrong usage bits
  • Server Name Indication
  • International DNS

We applaud Olle for making this test site available and hope it will be helpful to application developers to test if their applications fully support TLS.  If you are an application developer, please do visit the site and give Olle any feedback you may have as you use it.

Sites like this can help make encryption available everywhere and bring about a stronger and more secure Internet!

DNSSEC-name-and-shame Spotlights Top Web Sites Without DNSSEC

DNSSEC Name and ShameWhich of the Top Alexa-ranked sites support DNSSEC? How can you quickly find out if a web site supports DNSSEC?  Last week we learned of a fun new site that came out of a recent hackathon at TheNextWeb 2014 conference in Amsterdam that aims to answer these questions.  Called “DNSSEC name and shame!” the site can be found at the simple URL of:

At the top you can just enter any domain name and the site will check whether that domain is signed with DNSSEC.  But what is perhaps more interesting is to go a bit further down the page and look at the list of the Alexa Top 25 sites and the list of the event sponsors and “known good” examples.  You can click on any link and it will tell you the result.

I won’t spoil the surprise of what you’ll find when you click those links… but suffice it to say that many of the sites need to read our information for content providers / website owners about how to sign their domains with DNSSEC!  :-)

This DNSSEC-name-and-shame site is a cool example of the type of site / service that can be easily created using some of the new APIs available for DNS and DNSSEC.  Several of the other hackathon projects were definitely cool and we’ll be spotlighting some of them in the weeks ahead.

Congrats to the developers of the site, Joel Purra and Tom Cuddy, too, for winning PayPal’s TNW Hack Battle prize.  Great to see PayPal recognizing this work… and of course has been signed with DNSSEC for quite some time now.

Do check the site out… test out domains that you work with… and if they are not signed, why not start today on getting them signed and making the Internet more secure?

P.S. We also enjoyed that Anne-Marie Eklund Löwinder of .SE lent her shaking-fist image to the site.  She’s one of the early pioneers in the world of DNSSEC and it’s fun to see her here!

Wired: It’s Time To Encrypt The Entire Internet

Wired MagazineIs it time to “dump the plain text Internet” and encrypt everything everywhere? That’s the main thrust of an article by Klint Finley in Wired last week: “It’s Time to Encrypt the Entire Internet“. As he writes:

The Heartbleed bug crushed our faith in the secure web, but a world without the encryption software that Heartbleed exploited would be even worse. In fact, it’s time for the web to take a good hard look at a new idea: encryption everywhere.

Most major websites use either the SSL or TLS protocol to protect your password or credit card information as it travels between your browser and their servers. Whenever you see that a site is using HTTPS, as opposed to HTTP, you know that SSL/TLS is being used. But only a few sites — like Facebook and Gmail — actually use HTTPS to protect all of their traffic as opposed to just passwords and payment details.

He goes on to discuss viewpoints from Google’s Matt Cutts and and a number of other security professionals. As he notes at the end, there are costs, both in terms of financial costs for TLS/SSL certificates and also in terms of performance, but the greater security benefits are ones that we all need.

We definitely agree with the need to encrypt connections across the Internet. That’s why we’ve opened up the “TLS For Applications” area here on Deploy360 and why we are seeking to find or write a number of documents to help developers more quickly integrate TLS into their apps.

What do you think? Should connections across the Internet be encrypted?

What Can App Developers Learn From Heartbleed?

Heartbleed bugWhat lessons can application developers take from the Heartbleed bug?  How can we use this experience to make the Internet more secure?  Unless you have been offline in a cave for the past few days, odds are that you’ve seen the many stories about the Heartbleed bug (and many more stories today) and, hopefully, have taken some action to update any sites you have that use the OpenSSL library.  If you haven’t, then stop reading this post and go update your systems! (You can test if your sites are vulnerable using one of the Heartbleed test tools.) While you are at it, it would be a good time to change your passwords at services that were affected (after they have fixed their servers). There is an enormous list of the Alexa top 10000 out there, but sites like Mashable have summarized the major sites affected.  (And periodically changing your password is just a general “best practice”, so even if the site was not affected, why not spend a few minutes to make the changes?)

Client Applications Need Updating, Too

For application developers, though, it is also important to update any client applications you may have that use the OpenSSL libraries to implement TLS/SSL connections.  While most of the attention has been focused on how attackers can gain access to information stored on servers, it is also true that a malicious site could harvest random blocks of memory from clients visiting that site.  There is even demonstration code that lets you test this with your clients.  Now, granted, for this attack to work an attacker would need to set up a malicious site and get you to visit the site through, for instance, a phishing email or link shared through social media.  The attacker could then send malformed heartbeat messages to your vulnerable client in an attempt to read random blocks of memory… which then may or may not have any useful information in them.

Again, the path for an attacker to actually exploit this would be a bit complex, but you definitely should test any client applications you have that rely on any OpenSSL libraries.

With all that said, since we have started this “TLS For Applications” topic here are on Deploy360, what are some of the important lessons we can take away from this experience?  Here are a few I see coming out of this – I’d love to hear the lessons you take from all of this in the comments.

Security Testing Is Critical

It turns out that this was an incredibly trivial coding error. As Sean Cassidy points out in his excellent Diagnosis of the OpenSSL Heartbleed Bug, the issue boils down to this:

What if the requester didn’t actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.

There was no checking on the input and this allowed reading from other parts of the computer’s memory.  As Cassidy later writes about the fix:

This does two things: the first check stops zero-length heartbeats. The second check checks to make sure that the actual record length is sufficiently long. That’s it.

Today’s XKCD comic shows this all in an even simpler explanation.

This is the kind of trivial mistake that probably every developer has made at some point of his or her life.  I am sure that if I were to go back through many lines of code in my past I’d find cases where I didn’t do the appropriate input or boundary testing.  It highlights the importance of doing security testing – and of setting up security unit tests that are just done as part of the ongoing testing of the application. It also highlights the need for ongoing security audits, and for reviewers of code submissions to also be testing for security weaknesses.  But again, this is a common type of error that probably every developer has made.  You need testing to catch things like this.

In this instance it just happens that the mistake was in a piece of software that has now become critical for much of the Internet!  Which leads to a second lesson…

Having A Rapid Upgrade Path/Plan Is Important

As people learned about this bug earlier this week there has been a massive push to upgrade software all across the Internet. Which raises the question: how easy is it for your users to upgrade their software in a high priority situation such as this?

In many cases, it may be quite easy for users to install an update either from some kind of updated package or a download from an online application store.  In other cases, it may be extremely difficult to get updates out there.  In the midst of all this I read somewhere that many “home routers” may be vulnerable to this bug.  Given that these are often something people buy at their local electronics store, plug in, and pretty much forget… the odds of them getting updated any time soon are pretty slim.

Do you have a mechanism whereby people can rapidly deploy critical security fixes?

UPDATE: A ZDNet post notes that both Cisco and Juniper have issued update statements for some of their networking products. I expect other major vendors to follow soon.

Marketing Is Important To Getting Fixes Deployed

Finally, Patrick McKenzie had a great post out titled “What Heartbleed Can Teach The OSS Community About Marketing” that nicely hits on key elements of why we’re seeing so much attention to this – and why we are seeing fixes deployed.  He mentions the value of:

  1. Using a memorable name (“Heartbleed” vs “CVE-2014-0160″)
  2. Clear writing
  3. A dedicated web presence with an easy URL to share
  4. A visual identity that can be widely re-used

His article is well worth reading for more details.  His conclusion includes this paragraph that hit home for me (my emphasis added):

Given the importance of this, we owe the world as responsible professionals to not just produce the engineering artifacts which will correct the problem, but to advocate for their immediate adoption successfully.  If we get an A for Good Effort but do not actually achieve adoption because we stick to our usual “Put up an obtuse notice on a server in the middle of nowhere” game plan, the adversaries win.  The engineering reality of their compromises cannot be thwarted by effort or the feeling of self-righteousness we get by not getting our hands dirty with marketing, it can only be thwarted by successfully patched systems.


We need to make it easy for people to deploy our technologies – and our updates to those technologies.  (Sound like a familiar theme?)

What other lessons have you taken from this Heartbleed bug?  What else should application developers be thinking about to make TLS/SSL usage more secure?

Please do leave a comment here or on social media sites where this article is posted.  (And if you’re interested in helping us get more documentation out to help app developers with TLS/SSL, how about checking out our content roadmap for the TLS area?  What other items should we include?  Do you know of existing documents we should consider pointing to?  Interested in writing some documents?  Please do let us know.)

P.S. There’s now a post out about the process the Codenomicon team went through in disclosing the bug that is worth reading.

Weekend Project: Check Out The New “getdns” API

getdnsapiAre you an application developer who makes queries to DNS somewhere inside your application?

If so… or if you aren’t, but are just looking for a reason to play around with some code… there’s a new “getdns” API out that is designed to make it easier to interact with DNS.  From the website:

getdns is a modern asynchronous DNS API. It implements DNS entry points from a design developed and vetted by application developers, in an API specification edited by Paul Hoffman. With the development of this API, we intend to offer application developers a modernized and flexible way to access DNS security (DNSSEC) and other powerful new DNS features; a particular hope is to inspire application developers towards innovative security solutions in their applications.

You can read more about it at:

And the code is available on Github at:

There are also bindings for python and node.js in the works. This new “getdns” API has been developed by a team of developers from NLnet Labs, Verisign Labs and No Mountain Software and is based off of the getdns API specification documented by Paul Hoffman.

Members of the team gave a presentation at IETF 89 whose slides you can view about this new API and what you can do with it.  While  I haven’t played with it myself yet, I’m pleased to see that one major point is that it provides developers with easy usage of DNSSEC.  All in all it’s very cool to see a new API out there and we do encourage people to check it out and see what you think of it.  I’d note that because the code is maintained at Github, you can file issues there if you have questions or bugs.  There is also an email list for developers and users who want to get more involved with the project.

Congrats to the developer team for releasing this new API and we hope that it enables  app developers to more easily interact with DNS and DNSSEC!

Introducing A New Deploy360 Topic: TLS for Applications

TLSHow can we help make it easier for developers to learn how to add TLS (SSL) support to their applications?   If you’ve been following our work here at Deploy360 for a while, you know that part of our attention is focused on accelerating the deployment of DNSSEC and of technologies that help in securing BPG and Internet routing.

With DNSSEC, a great bit of our focus has been on the enormous potential of the DANE protocol to help make Internet connections using Transport Layer Security (TLS) more secure.  You already use TLS probably every day with your web browser… although you may know it more by its older name of “Secure Sockets Layer (SSL)”.  Any time you go to a website with a “https” at the beginning of a URL, or if you see a “lock” icon in many browsers, you are using TLS.   Any app developer using TLS is a great candidate to be using DANE.

But how do we get more developers using TLS to encrypt their connections and secure the data sent over those connections?

Around the time we were thinking about this, a new working group was launched within the IETF called “Using TLS in Applications (UTA)”.  This working group is chartered to create a set of “best practices” guides to help application developers know how to implement TLS in the best way possible to defend against attacks such as those outlined in draft-sheffer-uta-tls-attacks.  You can find out more about the UTA Working Group, including how to join the public mailing list, at these links:

It seemed to us that these documents being created within the UTA group were ones that should be shared widely.  I put some ideas forward on the UTA mailing list and received positive responses – and so we’re launching this new section of Deploy360 to help get that information out.  As the UTA working group publishes documents we’ll try to do what we can to help more developers and network operators learn about those documents.

To that end, I’ll also note that the UTA working group will be meeting this coming Friday, March 7, from 0900-1130 UTC at the IETF 89 meeting in London.  I wrote about this in my article yesterday about the DNS-related activities happening at IETF 89.  You can join the session remotely to listen in, so if this is of interest to you please do join.

Now, our “TLS for Applications” section here on Deploy360 will not be ONLY about the documents coming out of the UTA working group. We’ll also be finding the best documents and tutorials related to TLS that we can find out there on the Internet.  We’ve put up a content roadmap identifying the types of documents we intend to add to the site.

We’d love to hear your feedback about this new section of Deploy360. Do you see this as something that will be helpful to you?

How You Can Help

We need your help!  In order to provide the best possible resources to help application developers expand their use of TLS, we need to hear from you!  We need your feedback to help us know how we can best help you.  A few specific requests:

1. Read through our pages and content roadmap - Please take a look at our “TLS for Applications” page to understand what we are trying to do, and also please take a look at our content roadmap for BGP.  Are the current resources listed helpful?  Is the way we have structured the information helpful?  Will the resources we list on our roadmap help you make your routers more secure?

2. Send us suggestions – If you know of a tutorial, video, case study, site or other resource we should consider adding to the site, please let us know. We have a list of many resources that we are considering, but we are always looking for more.

3. Volunteer – If you are very interested in this topic and would like to actively help us on an ongoing basis, please fill out our volunteer form and we’ll get you connected to what we are doing.

4. Help us spread the word – As we publish resources and blog posts relating to adding TLS to applications, please help us spread those links through social networks so that more people can learn about the topic.

Thank you!  Working together we can make the Internet more secure!