April 2014 archive
Apr 30
TDYR #149 – Getting Vaccinations For Upcoming Tavel To Djibouti
Apr 30
Summary Report Now Posted of W3C/IAB “Strengthening The Internet (STRINT)” Workshop (Featured Blog)
Apr 30
Join The VUC Podcast Live On Friday, May 2, To Talk TLS/SSL And The Need For “More Crypto”
Why do we need “more crypto” everywhere? How can we get more people using TLS (SSL) in applications and services? If you are interested in this topic and want to discuss it with others, please do join the “VoIP Users Conference (VUC)” conference call this Friday, May 2, 2014, at 12 noon US Eastern time. The main guests will be Olle Johansson and Kristian Kielhofner and I will also be joining in to participate (as will typically a good number of people). Olle just recently participated in the “MeraCrypto” day-long session sponsored in part by the Internet Society Chapter in Sweden and has also been maintaining a set of slides about why we need “MoreCrypto”.
With the recent Heartbleed vulnerability in the news (here was my view on it) there is obviously a great amount of interest in the topic of getting more TLS / SSL out there. I’ll be on the call in part because we launched our “TLS for Applications” area out of our belief that we need more crypto out there being used. It should be good conversation and I’m very much looking forward to it!
To join the call, you can either connect in to the Google+ Hangout at 12:00 noon US Eastern – or alternatively call in via the SIP, Skype or regular old phone numbers listed on the top of the VUC page for the episode. There is also an IRC backchannel where text chat occurs during the episodes.
If you can’t listen live, the show will be recorded and you can listen to it later. If you can join live, please do… it should be great conversation on a very important topic!
Apr 29
New DNSSEC Deployment Maps for April 28, 2014, Now Available
I’ve made a couple of updates recently to our DNSSEC Deployment Maps section of the site.
First, I updated the page to display the most recent deployment maps from yesterday, April 28, 2014. The big change from previous maps is that Australia now appears in blue as the folks there have signed the .AU top-level domain on their production servers, but the DS is not yet in the root of DNS (that is scheduled for August 2014 right now).
Second, I changed the settings on the archive of the ‘dnssec-maps’ mailing list to be publicly accessible. This means that anyone can simply go to the archive to obtain the most recent set of DNSSEC deployment maps and also the comma-separated value (CSV) files that track all the domains, including generic TLDs and the “newgTLDs”. The deployment maps are generated automatically every Monday morning so with the list archive publicly available you can always get to the most recent version of the maps.
Ultimately I’d like to figure out how to have the maps automatically update on a page on our site by way of some type of WordPress plugin or other mechanism, but for the moment I’m still manually updating the images on the DNSSEC deployment maps page whenever there have been major changes or after a longer period of time has passed.
If you’d like to receive these maps automatically every Monday, you can simply subscribe to the ‘dnssec-maps’ mailing list and you’ll receive an email with the maps and CSV files each week. If you have ideas for enhancements, we’re also tracking those over on Github – feel free to raise “issues” with any ideas or feedback you have.
Apr 28
TDYR #0148 – What Do You Do On Your First Work Day After Vacation?
Apr 28
FIR #753 – 4/28/14 – For Immediate Release
Apr 24
TDYR #147 – It Is Hard To Podcast When You Cannot Speak
Apr 23
Wired: It’s Time To Encrypt The Entire Internet
Is 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?
Apr 22
CloudFlare Enabling IPv6 For All Customers
Buried in a post last month about Martin Levy joining CloudFlare was this gem:
CloudFlare is enabling IPv6 by default for ALL of their customers!
If you are not aware of CloudFlare, the are a “content delivery network” (or “content distribution network”… either way it is “CDN”) that takes your website and makes it available through their large network. A CDN can help you accelerate the speed at which users access your content. They also can help with performance issues, protection from DDoS attacks and many other website concerns.
CDNs also, as I documented in a video a while back, can be an easy path to making your web content available over IPv6. In my own personal case, I have a couple of sites on a hosting provider that has only IPv4. Given that I don’t have the time to move them to a hosting provider that provides IPv6, I’ve set both sites up to go through a CDN that automagically makes them available over IPv6. We maintain a list of CDN providers we are aware of who support IPv6.
But back to CloudFlare… a few years ago they implemented a setting for “Automatic IPv6″. All you had to do was toggle that from “Off” to “On” and… ta da… your content would be available over IPv6. Now, as Martin Levy writes on CloudFlare’s blog:
Many customers have flipped the switch to enable IPv6. That’s good; but it’s time to make the default setting “IPv6 on.” In this day and age this is a very safe thing to do. Over the next few weeks CloudFlare is going to make the default for new customer be “IPv6 on.” No need to flip that switch to be enabled for the whole Internet (that’s IPv4 and IPv6).
In the upcoming weeks CloudFlare will enable IPv6 for existing customers in a staggered release. CloudFlare takes the delivery of each and every bit very serious and you can be assured that every person at the company is involved in making this operation is successful. Yes there will be the option to turn off IPv6; but we strongly believe that at this point there’s little need for that option to be exercised.
So IPv6 will be on by default for all new customers – and all old customers will be migrated to having that setting enabled.
The results are already being seen in some of the available IPv6 statistics sites. Eric Vyncke noticed the uptick in his chart of the % of top web sites available over IPv6 and in a posting to the IPv6 group on Facebook attributed that growth to CloudFlare:
Regardless of whether CloudFlare drove that specific growth, the fact is that have a CDN provider enable IPv6 by default for all customers is a great step forward! Now we just need all the other CDNs to do the same thing and we’ll go a long way toward having a significant amount of the Web’s content available over IPv6.
How about you? Have you enabled you web content to be available over IPv6 yet? If not, how can we help you? Please do check out our IPv6 resources and let us know what other help you need.
Apr 21
Call For Participation – ICANN 50 DNSSEC Workshop on 25 June In London
Are you planning to attend the ICANN 50 meeting in London in June? If so, would you like to share your experience with deploying DNSSEC? As noted below, we are seeking proposals for presentations to be given during the DNSSEC Workshop that will happen on Wednesday, June 25, 2014, during the ICANN week.
The full list of topic areas for which we are seeking proposals is included below. If you have an idea for a presentation, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-london at shinkuro.com as soon as possible – but no later than by Friday, 09 May 2014. You can send an idea now if you would like… even if you have an idea you are not sure about, you are welcome to send it in and ask if it is appropriate. These are great sessions and the agenda tends to fill up pretty quickly, so if you want to be included please do send in a proposal as soon as possible!
Thanks,
Dan
Call for Participation — ICANN DNSSEC Workshop 25 June 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 meeting in London on 25 June 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 Singapore on 26 March 2014. The presentations and transcripts are available at: http://singapore49.icann.org/en/schedule/wed-dnssec.
We are seeking presentations on the following topics:
1. DNSSEC Activities in the European region:
For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the European 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. 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?
4. 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?
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. 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?
7. 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.
8. 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.)?
9. 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.
10. Panel Discussion/Demonstrations on Hardware Security Modules (HSMs):
HSMs are a key element in DNSSEC deployment, particularly in maintaining the security of the Zone Signing Key (ZSK). We are interested in demonstrations of HSMs as well as presentations on HSM challenges and benefits.
11. 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.
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-london at shinkuro.com by Friday, 09 May 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
