Category: TLS for Applications

Jul 22

Deploy360@IETF90, Day 2: DNSOP, DANE, UTA, V6OPS, IDR, OPSEC and ISOC@IETF

IETF LogoToday seems to be “DNS Day” here at IETF 90 in Toronto with the two major DNS-related working groups we follow here at Deploy360, DNSOP and DANE, both meeting on the same day.  We’ve also got V6OPS meeting again (as they did yesterday), have several IPv6-security drafts in OPSEC and have routing discussions happening in IDR.  Oh, and we’ll be splitting ourselves 3 ways in the first time slot (and wishing we had clones!). Plus, we’ll have the “ISOC@IETF” briefing panel at lunch time looking at security and privacy issues. It’s going to be a busy day!

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

DNSOP, DANE and UTA

As I mentioned in my Rough Guide post about DNSSEC/DANE at IETF 90, there is a great amount happening in both DNSOP and DANE.  Here is the relevant excerpt from that post:

DNS Operations (DNSOP)

Tuesday morning from 9:00-11:30 EDT the DNSOP Working Group kicks off with a full agenda that includes a great amount of DNSSEC activity. Matthijs Mekking will bepresenting a draft about DNSSEC key and signing policies. Daniel Migault will betackling the topic of what the requirements are for DNSSEC validation so that DNS resolvers can always have validation enabled.

Of particular interest to folks looking to get DNSSEC deployed (as I am) will be the “DNSSEC Roadblock Avoidance” draft that explores what are the problems with DNSSEC validation in many common network environments – and how do we mitigate those problems.

As the agenda indicates, there will be a range of other topics covered in DNSOP, too. The biggest and most controversial discussion may be around how we optimize the distribution of root zone data, with Warren Kumari and Paul Hoffman offering one view of distributing the root zone and Paul Vixie and Xiaodong Lee offering another view of how to scale the root of DNS. Given that DNSSEC plays an important role in both scenarios we’ll be paying close attention to what I expect will be quite a passionate discussion!

Beyond those topics you can probably expect to see some of the many other documents under DNSOP (scroll down the page to see the full list) raised for consideration – unless, of course, the root optimization discussion consumes most of the time, as could easily happen.

DNS-based Authentication of Named Entities (DANE)

Later on Tuesday afternoon, the working group looking after the DANE protocol will be actively discussing how various other protocols can use DANE / DNSSEC to provide a higher level of security for TLS (SSL) certificates. We should see discussion aroundthe “DANE and OpenPGP” draft as well as the “DANE and SMIME” draft. One of the DANE WG co-chairs, Olafur Gudmundsson, told me that the “SMTP security via opportunistic DANE TLS” draft and the “Using DANE with SRV Records” draft will both be going to Working Group Last Call and so that may or may not trigger some comments.

What may generate more discussion, though, is interest in changing the “DANE Operational Guidance” draft into a “DANEbis” document, i.e. looking at it as a replacement/update for RFC6698 that defines DANE. This should be an interesting discussion!

On a similar track, Paul Wouters will be speaking about standardizing how “Raw Public Keys” for TLS can be authenticated using DANE. As I understand it, Paul wants to extend the TLSA record used in DANE to support more than just PKIX-formatted certificates, allowing DANE to be used for applications that do not require PKIX certs.

I am also intrigued to learn more about ideas from Haixin Duan to use DANE to better secure the usage of HTTPS connections in content distribution networks (CDNs). Haixin Duan and some colleagues have written a paper that goes into more detail (search for “DANE” to jump to the relevant section).

If there is time Olafur tells me that the chairs also intend to kick off a discussion of “reverse DANE”, i.e. DANE records for clients, that might lead to some interesting applications and areas of work.

Unfortunately at the same time as DNSOP from 09:00-11:30,  the Using TLS in Applications (UTA) working group will be meeting. While the UTA agenda  doesn’t directly mention DNSSEC, we definitely pay attention to UTA given that the drafts all focus on securing TLS and that DANE could potentially play a role here. We also have an interest for our “TLS For Applications” section of Deploy360.

IPv6

Beyond DNS, today the IPv6 Operations (V6OPS) working group is back with an agenda once again looking at the operational aspects of running IPv6.  The first document on running multiple IPv6 prefixes was actually addressed in yesterday’s session so there may be more time available for other discussions.  I’m personally intrigued by the discussion about power consumption due to IPv6 multicast on WiFi devices.  I’ve not been directly following that draft so I’m intrigued to learn more.

Outside of V6OPS, IPv6 will also feature prominently on today’s OPSEC agenda with two drafts from Fernando Gont being presented that talk about how firewalls interact with IPv6. First he’ll be discussing how many firewalls drop IPv6 extension headers (EH) and his thoughts about that.  Second, he’s got a draft on “Requirements for IPv6 Enterprise Firewalls” that looks quite interesting.

(As an aside, having lived in Canada from 2000-2005, I’m very pleased that there is at least one draft (Fernando’s) being presented here in Toronto that includes “eh” in it, given that this is a very common Canadian verbal expression, as in “It’s going to be a great day, eh?” :-) )

Routing and Securing BGP

Today is also the day one of the major routing working groups we track will be meeting, unfortunately in that same 9:00-11:30 am block as DNSOP and UTA.  The Inter-Domain Routing (IDR) working group has an extremely packed agenda full of all sorts of drafts related to securing BGP and improving the security of our routing infrastructure.  As our colleague Andrei Robachevsky wrote in his Rough Guide post, IDR “continues to work on better handling of malformed BGP attributes that may cause serious outages, and even cascading effects for other networks.  Because of the timing conflict, I won’t personally be in IDR, but you can expect to find Andrei there.

ISOC@IETF90 Briefing: Internet Security and Privacy: Ten Years Later

In the midst of all the working groups today we’ll spend our lunch time from 11:45-12:45 at the traditional “ISOC@IETF Briefing Panel” that happens every Tuesday of an IETF meeting.  The theme this time is “Internet Security and Privacy: Ten years later” and the abstract begins:

Many fundamental Internet protocols and architectural elements were designed for relatively closed and controlled networks and later used in a fairly trusted environment. Then came explosive Internet growth that changed its very nature – the Internet became a global, open communication medium to which anyone could connect and contribute.

At the same time, the Internet model was also changing. Concentration and centralization of certain functions at various Internet architecture layers created new types of vulnerabilities and, consequently, facilitated new threats such as pervasive monitoring. These vulnerabilities manifest themselves in different ways – for instance, in lack of diversity in implementations of critical security protocols, like TLS.

The number and nature of connected devices is also changing dramatically – sensors, controllers, appliances, etc., all communicating without human intervention.

The Internet continues to change and this evolution will continue. How will security and privacy challenges be addressed ten years from now? What are the missing building blocks that need to be developed? Will current approaches allow us to catch up or is a change of paradigm required?

There are a great set of panelists and this should be a great discussion.  It will be live streamed over YouTube and anyone is welcome to watch.  (Unless they are trying to view the stream from Germany, where apparently they can’t.)

And after all that is done we’ll probably be going to the IETF Social event tonight to talk to more people about how we might be able to help them… before eventually getting to bed to get ready for Day 3…

The information about the relevant working groups today is:

DNSOP (DNS Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ballroom)

UTA (Using TLS in Applications) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/
(Tuesday, July 22, 2014, 0900-1130 EDT, Ontario)

IDR (Inter-Domain Routing Working Group) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
(Tuesday, 22 July, 0900-1130 EDT, Tudor 7/8 Room)

OPSEC (Operational Security) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/opsec/
Charter: https://datatracker.ietf.org/wg/opsec/charter/
(Tuesday, 22 July, 1300-1400 EDT, Territories Room)

V6OPS (IPv6 Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/
(Tuesday, July 22, 2014, 1420-1620 EDT, Ontario)

DANE (DNS-based Authentication of Named Entities) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/dane/
Documents: https://datatracker.ietf.org/wg/dane/
Charter: http://datatracker.ietf.org/wg/dane/charter/
(Tuesday, July 22, 2014, 1640-1840 EDT, Canadian)

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

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

Jul 11

CloudFlare Releases Open Source CFSSL, a TLS/SSL Toolkit

CloudFlare logoYesterday the folks over at CloudFlare introduced their “CFSSL” toolkit for working with TLS (SSL) certificates. Their blog post explains what CFSSL is all about, and they have also made the code available along with further documentation on Github: https://github.com/cloudflare/cfssl

This is interesting to me for a couple of reasons.  First, their blog post has some excellent diagrams outlining the challenges with ensuring that a TLS certificate is able to be validated by a web browser.  The author Nick Sullivan points out that different browsers trust different numbers of Certificate Authorities (CAs) – and that older browsers may not trust newer CA certificates.  He outlines the need to create “certificate bundles” that include multiple TLS chains.  The key point of all of this is to make it so that your TLS certificate is accessible to the widest range of browsers and systems.

As a tutorial alone, the post is a good read.

It also highlights the complexity (some might say “brokenness”!) of the current CA system and why many folks are looking for mechanisms to add more trust into the system (the DANE protocol being one of those potential mechanisms).

The post also explains their CFSSL tool which is available for anyone to use.  While it is not exactly a TLS library, like some of the other tools we’ve highlighted in our TLS for Applications area, the source code is available and some developers may find it of use.  I found it interesting that the tool could also be used to create your own CA and generate your own certificates.  This might be useful for people looking to do additional testing or to run their own CA for their own purposes.

Regardless of what you may do with the toolkit, kudos to CloudFlare for making it available under a permissive open source license and for providing the documentation they do.  I hope it will help some folks out there make the Internet more secure!

Jun 09

Speaking At SIPNOC 2014 On June 10 About TLS For SIP/VoIP/UC

SIPNOC 2014 logoWhat advantages does Transport Layer Security (TLS, what we used to call “SSL”) bring to voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)? What is the state of TLS usage within SIP and VoIP? Why isn’t it being used more?

Tomorrow, June 10, 2014, I’ll be speaking at the SIP Network Operators Conference (SIPNOC) 2014 event down in Herndon, Virginia, on the topic of “Is It Time For TLS For SIP?“. I’ll be discussing why we need more TLS usage in SIP-based communication, including what we think of as “VoIP” and also “Unified Communications (UC)”. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

As you can tell, my focus will be around the “TLS for Applications” topic area we have here on Deploy360, as well as some discussion around DANE and what it can bring in terms of increased security.

I’ve spoken at SIPNOC events for the past two years (and before that) but my topic has always included IPv6.  This time I won’t be doing that… but to my delight one of the talks before mine tomorrow will be Carl Klatsky from Comcast providing a case study of their work their voice services to IPv6.  Here is his abstract:

Comcast Voice IPv6 Deployment Lessons Learned. Presented by Carl Klatsky, Comcast.

This presentation will review the successes, challenges, and lessons learned in deploying IPv6 support into Comcast’s IMS based SIP voice network, in support of an upcoming IPv6 technical trial. The presentation will review the overall target architecture covering both access and network side elements, and share the lessons learned with the SIP community.

I’m very much looking forward to hearing what Carl has to say!

There are many other great sessions on the SIPNOC 2014 agenda.  Unfortunately I can only be at the event tomorrow and will be missing out on the great content on Wednesday and Thursday.  You can, of course, expect to find me in any of the security-related sessions on Tuesday!

If any of you reading this are at SIPNOC 2014 tomorrow please do feel free to say hello!

P.S. And before anyone asks in the comments, no, there is not a live stream (or recordings) of the SIPNOC sessions.  They try to keep it an informal atmosphere where information can be shared with the conference sessions without that information being immediately public.

 

May 02

Reminder – Live Call In Two Hours About TLS / SSL And The Need For More Crypto Everywhere

VUC logoReminder – in two hours you can join a live discussion we mentioned earlier this week about the need for more TLS / SSL everywhere and what we can do as a technical community to make that happen.  As I noted earlier the main guests will be Olle Johansson and Kristian Kielhofner with others joining in as well.  Host Randy Resnick usually creates an enjoyable and informative session where much can be learned.

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.  The session will be recorded if you cannot attend live.

For us, we’re interested in discussions like this one today because we want to build out our TLS for Applications area to have the best resources possible to help developers add TLS into their applications and in so doing make the Internet stronger and more secure for us all. (And on that note, if you would be interested in helping us create the info on our content roadmap for TLS – or know where we can find existing documents that fulfill those items – please contact us!)

Apr 30

Join The VUC Podcast Live On Friday, May 2, To Talk TLS/SSL And The Need For “More Crypto”

VUC logoWhy 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 23

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?

Apr 11

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.

Exactly!

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.

Mar 21

Google Is Now Always Using TLS/SSL for Gmail Connections

Gmail logoWe were pleased today to read that Google is now changing their Gmail service to always use TLS-encrypted connections. As they note in their announcement blog post:

Starting today, Gmail will always use an encrypted HTTPS connection when you check or send email. Gmail has supported HTTPS since the day it launched, and in 2010 we made HTTPS the default. Today’s change means that no one can listen in on your messages as they go back and forth between you and Gmail’s servers—no matter if you’re using public WiFi or logging in from your computer, phone or tablet. 

The key point is the one I emphasized in bold in the text: attackers cannot listen in on your messages as they go between your mail client (which could be your web browser) and Gmail’s servers.   Obviously the messages could still be potentially viewed either on your client device or on Gmail’s servers… but this step is removing the ability for the messages to be viewed “on the wire”.

This is a great example of the kind of action we’d like to see to make communication over the Internet more secure- and why we launched our new “TLS for Applications” section of this site.  We want to encourage more application providers and developers to make the steps that Google has done here.

Kudos to the Google/Gmail team for taking this step!

Mar 12

On The 25th Anniversary Of The Web, Let Us Keep It Open And Make It More Secure

Web 25th AnniversaryCan we even begin to count the ways the “Web” has affected all of our lives? Today is the 25th Anniversary of the proposal that led to the creation of the World Wide Web. Over at Webat25.org, Tim Berners-Lee, the W3C and the World Wide Web Foundation are celebrating this milestone with greetings from people all around the world, including Internet Society President and CEO Kathy Brown, who recorded a video greeting, as well as IETF Chair Jari Arkko and IAB Chair Russ Housely.  The WebAt25 effort is also promoting an active campaign on Twitter using the #web25 hashtag and is encouraging people everywhere to get more involved with efforts to ensure the Web remains an open platform for creativity, innovation and collaboration.

As our Leslie Daigle wrote in an excellent Internet Technology Matters post today, the Web is a prime example of how “permission-less innovation” enables the creation of new services that run on the Internet and also of both the global nature of the Internet and the value of open standards.

For us here at the Deploy360 Programme, our use of the Web is the critical cornerstone of our efforts to accelerate the deployment of key Internet technologies… even as most of the protocols (IPv6, DNSSEC, BGP) we promote are actually part of the underlying Internet infrastructure that makes services like the Web possible. Without the Web, we would not be able to bring you all the resources and news we bring you here, nor would we be able to share it with you through web-based social media. It is critical for our work.

On this day, we  join with the W3C, World Wide Web Foundation and so many others in celebrating this 25th anniversary and the amazing success of the Web. As we do so, though, we know that for the Web and other Internet services to prosper they need to not only continue to be as open as they have been in the past, but they also need to be more secure to protect the privacy and security of information. That is why we’ve worked so hard getting DNSSEC deployed more widely,  recently opened our new “TLS for Applications” topic area, and why we’re looking for your help to build more content to help application developers, website designers and many more people understand how to make the Web and other services more secure.

Thank you, Tim Berners-Lee, for the proposal 25 years ago that led to the creation of the World Wide Web, and for everything you’ve done to keep the Web open to all. We look forward to joining with people around the world to continue to keep the Web – and the Internet – open for all!

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.