Category: Privacy

Heading to Belgrade This Week for WordCamp Europe 2018 (WCEU)

Wceu 2018

If any of you will be at WordCamp Europe 2018 this week in Belgrade, Serbia, please do say hello. I'll be there starting this afternoon and am greatly looking forward to learning from many of the people involved deeply in the WordPress community.

In particular I'm looking forward to the Developing for Privacy and Data Protection session. Based on the work done in the community to help website operators comply with the European Union's General Data Protection Regulation (GDPR), this workshop will look at what comes next. I'm personally very interested to see where this will go.

I'll also be going to some accessibility workshops and checking in on topics such as caching, security and mobility that are always of interest. I also have some meetings with partners and others.

Anyway, if you're there at WCEU 2018, feel free to drop me a note.

Podcast: Talking Data Privacy and GDPR with Todd Tolbert

Let’s raise the bar on data privacy and make the Internet safer.”  With the imminent arrival of the EU’s General Data Protection Regulation (GDPR), this was one of the points raised by Todd Tolbert, our Chief Administrative Officer, in an episode of the Non-Profit Tech Podcast published yesterday. Hosted by fusionSpan’s Justin Burniske, the 35-minute episode covered a wide range of topics, including:

  • the difference between data privacy and data protection
  • Todd’s thinking about the value the GDPR brings in terms of thinking about data
  • mistakes organizations make with regard to handling their data
  • resources for organizations to do more
  • how you can’t be liable for data that you don’t have in the first place
  • asking the question… do you really need to keep those 700 email addresses that no longer work?

And, of course, Todd being who he is, there were some Texan things mixed in to the conversation as well. I very much enjoyed the episode and found it a useful contribution to the ongoing privacy discussions that tomorrow’s GDPR deadline has generated.

Some of the resources Todd shared included:

I would also encourage you to view our articles and resources related to privacy.

Since I can’t seem to find any way to embed the player here, you’ll need to go visit the podcast page to listen – or download it in your favorite podcast app.

FYI, as Todd as written previously, he’s been leading our efforts on GDPR compliance, and also serves as our Data Privacy Office (DPO).

The post Podcast: Talking Data Privacy and GDPR with Todd Tolbert appeared first on Internet Society.

Rough Guide to IETF 98: DNS Privacy and Security, including DNSSEC

It is a remarkably quiet week for DNS security and privacy topics at the IETF 98 meeting in Chicago next week. Both the DANE and DPRIVE working groups are moving along very well with their work on their mailing lists and so chose not to meet in Chicago. Similarly, with DNSSEC deployment steadily increasing (as we outlined in the 2016 State of DNSSEC Deployment report in December), the work to be discussed in DNS Operations (DNSOP) is more about exploring ideas to make DNSSEC even more secure.

Here is a quick view of what is happening in Chicago.

IETF 98 Hackathon

Over the weekend (25-26 March) we’ll have a good-sized “DNS team” in the IETF 98 Hackathon working on various projects around DNSSEC, DANE, DNS Privacy, using DNS over TLS and much more. This time the work will include a team looking at how some DNS toolkits can work with the impending Root KSK Rollover in October 2017. More specific information is in the IETF 98 Hackathon wiki. Anyone is welcome to join us for part or all of that event.

DNS Operations (DNSOP)

The DNS Operations (DNSOP) Working Group meets on Monday afternoon from 13:00-15:00 CDT. The DNSOP agenda includes the following items related to DNSSEC:

Some of the other discussions, such as DNS over TCP, also have potential impacts on DNS security and privacy.

DNS Service Discovery (DNSSD)

On Tuesday, the  Extensions for Scalable DNS Service Discovery (DNSSD) Working Group meets from 16:40-18:40 CDT. DNSSD is not one of the groups we regularly follow as its focus is around how DNS can be used to discover services available on a network (for example, a printer or file server). However, in Chicago the DNSSD agenda specifically has a discussion around “Privacy Extensions” (see draft-ietf-dnssd-privacy).

DNSSEC Coordination informal breakfast meeting

Finally, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

Right before the DNSSD Working Group on Tuesday, the Using TLS in Applications (UTA) WG will meet from 14:50 – 16:20 and will be covering several ideas for “Strict Transport Security” (STS) for email. While not directly tied to DNSSEC or DANE, they do use DNS for these security mechanisms. And then in the final session on Friday, from 11:50-13:20, the IPSECME WG will have a discussion about “split DNS” and how that impacts VPNS (see draft-ietf-ipsecme-split-dns).

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 98:

DNSOP (DNS Operations) WG 
Monday, 27 March 2017, 13:00-15:00 CDT (UTC-5), Zurich D

DNSSD (Extensions for Scalable DNS Service Discovery) WG 
Tuesday, 28 March 2017, 16:40 – 18:40 CDT (UTC-5), Zurich B

Follow Us

There’s a lot going on in Chicago, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blogTwitterFacebookGoogle+, via RSS, or see

The post Rough Guide to IETF 98: DNS Privacy and Security, including DNSSEC appeared first on Internet Society.

The Danger of Giving Up Social Media Passwords – So Many Other Services Are Connected

What’s the harm in giving up my Twitter password?“, you might say, “all someone can do is see my direct messages and post a tweet from me, right?

Think again. The reality today is that social media services are used for far more than just posting updates or photos of cats. They also act as “identity providers” allowing us to easily login to other sites and services. 

We’ve all seen the “Login with Twitter” or “Continue with Facebook” buttons on various sites. Or for Google or LinkedIn. These offer a tremendous convenience. You can rapidly sign into sites without having to remember yet-another-password.


… if you give your passwords to your social media accounts to someone, they could potentially[1]:

  • Impersonate you on social media accounts and post updates in your name.
  • Sign in to the comment sections of various news media sites and leave comments using your name.
  • Connect in to photo sites and see our photos, and modify or delete the photos, or post new ones in your name.
  • Sign in to e-commerce sites, view your orders and purchase items.
  • Login to video sites and see what videos you have watched, or post new ones to your account.
  • Login to your Medium account, view and change any articles you have written, add new comments as you.
  • Sign in to Goodreads, view all your books, see all the lists of what you want to read, view all your reviews and post reviews in your name.
  • Login to your Spotify account and learn all about what kind of music you like to listen to.

And that’s only a small number of examples.

We live in an era of highly-connected systems. And there are so many systems and services! The convenience of using our social media accounts to login is easy to understand.

But… if you give someone your password to a social media account, or are required to give your social media passwords to someone, you are giving them access to so much more than just that social media service.

What can you do?

1. Don’t give out your social media passwords!

2. Understand where your social media IDs are being used. In both Twitter and Facebook you can go into your “Settings” and choose “Apps” to see where you have granted access. You can revoke access there for sites and services you no longer use.

3. Think about whether you want to continue using your social media IDs in so many places. Does the convenience outweigh the issue of having so many services linked to one identity?

4. Enable 2-Factor Authentication on sites that offer this, which requires a second step beyond just your password to login. These are very easy to use, often using a phone or a small and inexpensive “dongle” that fits on your keyring.[2] Do note that this may not help if you are required by authorities to provide your social media passwords as they may require you provide the device used for two-factor authentication.

5. Use a password manager instead of using your social media ID to login to other sites,  which enables you to generate and use very strong passwords and access them all with one master password. There are many excellent free and paid options available for both computers and mobile devices, with a variety of features.

6. Spread the word. Help others understand how critically important our social media passwords are.

P.S. For more ideas, please see

[1] Depending upon how you have configured the service to work.

[2] The FIDO Alliance is a leader in this area, and a list of enabled sites and certified products is available on their site

The post The Danger of Giving Up Social Media Passwords – So Many Other Services Are Connected appeared first on Internet Society.

ISOC@OECD, Day 2: Kathy Brown’s speech about trust, Hiroshi Esaki speaking about innovation

Today is the first day of the “Ministerial Conference” section of the OECD Ministerial Meeting on the Digital Economy.  Yesterday was for the very successful “Stakeholder Forums” and my colleague Nicolas Seidler wrote about the ITAC Forum that discussed Internet policies, IPv6, IoT, open standards and Collaborative Security.  I also encourage you to read our OECD Ministerial Background Paper to understand why this meeting is so important for Internet Governance.

11:40 am – OECD Stakeholders Armchair Discussion

Our big event today will be the “OECD Stakeholders’ Armchair Discussion”  where our President and CEO Kathy Brown will speak as a member of the Internet Technical Advisory Committee (ITAC) about what was discussed in the ITAC Forum yesterday and also about the view from within the technical community about the need to increase trust in the Internet.

The overall session she is in starts at 11:40 am local time (UTC-5, similar to US Central time) although we are told the armchair discussion should start closer to 12:20 pm.  Each of the four stakeholder advisory committees will provide a statement, and Kathy will be speaking on behalf of ITAC.

16:45 – Stimulating Digital Innovation across the Economy

After Kathy’s session there will be a 1.5 hour lunch break and then the parallel track sessions begin.  The OECD Ministerial Agenda outlines the sessions, including:

  • Economic and Social Benefits of Internet Openness
  • Consumer Trust and Market Growth
  •  Stimulating Digital Innovation across the Economy
  • Managing Digital Security and Privacy Risk for Economic and Social Prosperity

While all of the sessions are of interest, our attention will be on the session about “Stimulating Digital Innovation” at 16:45 as ISOC Board of Trustees member Hiroshi Esaki will be one of the speakers on the panel.

We understand that the sessions should be live streamed, but we are uncertain of the exact URL.  We would advise you to visit the OECD live stream page to see what streams are available.

You can also follow our @InternetSociety Twitter account where we will be providing updates using the #OECDdigitalMX hashtag.

Watch this blog, too, as we will be posting several more articles throughout the day!

The post ISOC@OECD, Day 2: Kathy Brown’s speech about trust, Hiroshi Esaki speaking about innovation appeared first on Internet Society.

DNS-OARC 24 Streaming Live March 31 / April 1 from Buenos Aires


Today and tomorrow you have a great opportunity to listen to some of the newest research into the Domain Name System (DNS) operations and security through the live video stream of the 24th meeting of the DNS Operations Analysis and Research Center (DNS-OARC). You can watch live at:

and view the past recordings on the DNS-OARC YouTube channel.  The DNS-OARC 24 agenda covers a wide range of topics related to the overall operations of DNS.  Some of the sessions that Deploy360 readers may find of interest include:

  • Thursday, March 31
    • How we are developing a next generation DNS API for applications
    • State of the “DNS privacy” project: running code
    • QNAME minimisation in Unbound (DNS privacy)
  • Friday, April 1
    • Knot DNS Resolver
    • Threshold-Cryptography Distributed HSM
    • Review and analysis of attack traffic against A-root and J-root on November 30 and December 1, 2015
    • ECDSA – Reviewed
    • Rolling the Root Key
    • Algorithm roll-over experiences
    • Panel: DNSSEC algorithm flexibility

The last four sessions that I highlighted in bold all fit into the larger work of moving to use newer elliptic curve cryptographic algorithms within DNSSEC that I wrote about recently.  As I mentioned in that article, I’ll be moderating this final panel tomorrow afternoon.

I would encourage people to tune in and watch the sessions.  Do visit the DNS-OARC 24 timetable to find out the times when different sessions will be happening. All times are in Argentina time (ART) which is UTC-3.

And if you want to get started with DNSSEC yourself, please visit our Start here page to begin.

Image credit: a photo of the DNS-OARC 24 room I took this morning.


Rough Guide to IETF 95: DNSSEC, DPRIVE, DANE and DNS Security

The most passionate discussions involving “DNS security” at IETF 95 in Buenos Aires may possibly take place not in the “traditional” DNS-related Working Groups, but rather over in the Using TLS in Applications (UTA) Working Group on Monday, April 4, 2016, at 14:00 ART where what looks like a vigorous discussion is shaping up about how to protect and secure email communication. Yes, email! On the UTA agenda there is not one but three different proposals for securing email – and all three include some discussion of DNSSEC and DANE (particularly after the publication of RFC 7672 in October about securing email with the DANE protocol). Based on the lengthy threads on the UTA mailing list, I expect a strong amount of discussion.

A second strong thread of activity will be around efforts to increase the security of DNSSEC through the use of elliptic curve cryptography. This will be discussed in both the DNSOP working group and also a new focused working group called CURDLE. It’s also the topic of a recent Internet-Draft I published with a number of others about the steps needed to implement elliptic curve cryptography.

The DPRIVE Working Group will also be meeting to continue its work on securing the connection between DNS clients and recursive resolvers. The DNSSD and TRANS groups will also be meeting and a new Birds-of-a-Feather (BOF) session on ARCING will also meet. The DANE Working Group will not be meeting in BA, but as mentioned above, there will be a good discussion related to DANE as part of the broader UTA discussions on Monday.

Beyond UTA, here are how some of the other groups are looking at IETF95…

DNS Operations (DNSOP)

The DNS Operations (DNSOP) Working Group meets twice: first for an hour on Wednesday (in the timeslot previously scheduled for DANE) and then again for two hours on Friday. Two pieces of DNSSEC work in the new business area of the DNSOP agenda: a draft from Warren Kumari about speeding up negative answers from NSEC records at the root of DNS; and then a draft from Paul Wouters and Ondrej Sury about requirements and usage guidance for DNSSEC cryptographic algorithms. This second draft is interesting because the intent is to phase out usage of older cryptographic algorithms. Beyond that, DNSOP typically winds up with discussions that affect the overall performance and operations of DNS that make for an interesting time.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE Working Group will be meeting on Wednesday morning to continue the discussions about DNS over TLS and DNS over DTLS. All of this DPRIVE work is focused on securing the connection between DNS clients and the recursive resolvers that people use (such as those typically at an Internet Service Provider (ISP) or on the edge of a network) to add a layer of confidentiality. We see this as an important part of the overall encryption work being done by the IETF to protect against the pervasive monitoring that we’ve seen on the Internet. Mechanisms such as what DPRIVE is developing will raise the overall amount of trust in Internet-based communication.

CURves, Deprecating and a Little more Encryption (CURDLE)

The CURDLE Working Group potentially wins the award for biggest stretch of a name to fit an acronym… but on a serious level the group is focused on an extremely important area of work – increasing the cryptographic security of a number of common protocols, including DNSSEC. On the CURDLE agenda are two drafts from Ondrej Sury and Robert Edmonds that specify new algorithms for DNSSEC.

DNS Service Discovery (DNSSD)

We haven’t covered the DNS Service Discovery (DNSSD) Working Group too often in the past, but at IETF 95 the DNSSD agenda has two interesting drafts up for discussion: one is related to the overall threat model and the other about privacy extensions. This WG is looking at how you “discover” services on a network using DNS when that “network” is bigger than just your own local network. For instance, how do you discover a printer that might be at, say, your parents’ house? And of course, how do you do all that securely? DNSSEC is not directly part of these discussions, but they are part of the broader “DNS security” area of our interest.

Other Working Groups

The TRANS WG focused on “certificate transparency” (CT), a mechanism for tracking changes in TLS certificates, is meeting on Monday and has a draft out about the attack model and threats on CT. This isn’t exactly related to DNS, but we’ll pay attention because it is looking at the same “securing TLS for the Web” area that is applicable to DANE. We’ll also of course be monitoring the TLS WG (because of the connection to DANE), the Security Area open meeting and other similar sessions. There is also a BOF called “Alternative Resolution Contexts for Internet Naming (ARCING)” that doesn’t directly affect “DNS security”, per se, but is looking at the larger issue of “alternate” systems of name resolution on the Internet. For example, the naming resolution that happens within the Tor onion routing system. More info can be found on the BOF page and also in the ARCING mailing list archive.

It will be a busy week – but the outcomes of all these sessions should go far to make the DNS – and the overall Internet – more secure!

Please see the main Rough Guide to IETF 95 page to learn about more of what we are paying attention to in Buenos Aires.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 95:

UTA (Using TLS in Applications) WG
Monday, 4 April 2016, 1400-1530 ART, Room Antlico C

TRANS (Public Notary Transparency) WG
Monday, 4 April 2016, 1550-1720 ART, Room Quebracho A

DNSSD (Extensions for Scalable Service Discovery) WG
Monday, 4 April 2016, 1550-1720 ART, Room Buen Ayre B

CURDLE (CURves, Deprecating and a Little more Encryption) WG
Tuesday, 5 April 2016, 1620-1720 ART, Room Buen Ayre B

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 6 April 2016, 1000-1230 ART, Room Atlantico C

DNSOP (DNS Operations) WG
Wednesday, 6 April 2016, 1620-1720 ART, Room Atlantico B
Friday, 8 April 2016, 1000-1200 ART, Room Buen Ayre C

Follow Us

There’s a lot going on in Buenos Aires, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

The post Rough Guide to IETF 95: DNSSEC, DPRIVE, DANE and DNS Security appeared first on Internet Society.

IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking

IPv6 BadgeRecently we’ve seen several articles, such as one out today, that assert that IPv6 addresses will make it easier for security services and law enforcement to track you. Surprisingly, these articles seem to miss that when IPv6 is implemented today on mobile devices or other computers, it is almost always implemented using what are called “privacy extensions” that generate new IPv6 addresses on a regular basis.

To put it simply – almost every mobile device or computer using IPv6 in 2014 changes its IPv6 address on a daily basis (usually) to prevent exactly this kind of surveillance.

To step back a bit – if you read any of the documents explaining the basics of IPv6, they inevitably mention that the “auto-configured” IPv6 address for a device is created using the network address and the MAC address assigned to the device’s network interface. This gives a theoretically globally unique address for your computer, mobile phone, or device.

If this were the only IPv6 address your device had, it would be something that could be easily tracked.


The engineers who created IPv6 were very concerned that IPv6 could be used in this way and so way back in 2007 they published RFC 4941 defining “privacy extensions for IPv6″ autoconfiguration. This standard defines a mechanism where a device generates a random host address and uses that instead of the device’s MAC address.

The device also changes that IPv6 address on a regular interval. The interval can be set to anything, but typically is configured on most operating systems to be one day. In mobile networks, the IPv6 address may change based on the link to which you are connecting, so as you move around you will be generating and using new IPv6 addresses all the time throughout the day.

As we wrote about in a resource page about IPv6 privacy extensions, the following operating systems use IPv6 privacy extensions BY DEFAULT:

  • All versions of Windows after Windows XP
  • All versions of Mac OS X from 10.7 onward
  • All versions of iOS since iOS 4.3
  • All versions of Android since 4.0 (ICS)
  • Some versions of Linux (and for others it can be easily configured)

So if you are using a Windows or Mac OS X computer, or any of the major mobile devices, you are already using IPv6 privacy addresses.

I know from my own network analysis in my home office network that all my devices are constantly changing their IPv6 addresses. (In fact, these IPv6 privacy addresses can cause problems for some applications that expect IP addresses to be stable – which brought about RFC 7217 this year suggesting a way to create a random address when your device is on a given network but then have that change when you move to another network.)

In the end, the ability of security services to track you on IPv4 versus IPv6 is pretty much about the same. With IPv4, you generally have a public IPv4 address that is assigned to the edge of your network, perhaps your home router or the router at the edge of your corporate network. You then use NAT to assign private IPv4 addresses to all devices on the inside of your IPv4 network. On the public Internet, all that an observer can see and track is your public IPv4 address – there is no further information about the device on the inside of the network beyond a port number.

With IPv6, you typically have a public IPv6 network address assigned to the edge of your network and then the devices internally configure themselves using IPv6 privacy extensions. On the public Internet, an observer can see and track your public IPv6 address, but that will be changing each and every day, making any kind of long-term tracking rather difficult or resource-consuming.

We definitely want to see more articles about IPv6 security appearing out in the mainstream media as these are extremely important conversations to have – but when talking about IPv6 addresses and surveillance, let’s please try to focus on how IPv6 is actually being implemented rather than how it could theoretically be done.

NOTE: For a lengthier technical discussion on this topic, please view this Internet Draft: draft-ietf-6man-ipv6-address-generation-privacy

For more information on how to get started with IPv6, please visit our Start Here page to find resources focused on your role or type of organization.

P.S. From a privacy perspective, I am personally far more worried about the application-layer tracking that occurs through “cookies” (including the new “super cookies” deployed by some mobile network providers) and other mechanisms. For these tracking mechanisms, the underlying IP address is completely irrelevant.


New IETF Mailing List To Discuss Privacy and Confidentiality of DNS

IETF LogoHow can we better protect the privacy and confidentiality of DNS queries? While DNSSEC protects the integrity of answers coming back from DNS (i.e. ensuring they aren’t modified in transit), what can be done to protect the confidentiality and privacy of information retrieved from DNS?  Particularly against the kind of pervasive monitoring and large-scale network sniffing we’ve become aware of?

We mentioned previously that at IETF 89 this month in London there was the “Encryption of DNS requests for confidentiality” (DNSE) BOF looking at these topics.  There was vigorous discussion during that BOF and then at the DNSOP working group meeting.  That large amount of interest has now sparked the creation of a new mailing list for all those interested in participating.  This “dns-privacy” list is public and open to anyone to subscribe:

List address:
To subscribe:

As you can see from the mailing list archive, there is already some discussion underway.  If you want some background the Internet drafts draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality may be useful.

While this doesn’t specifically related to the DNSSEC topic we cover here on Deploy360, it is part of the same overall space of “making DNS more secure” and so I thought it would be useful to point people to this new list.

Working together as an industry and community, we can make DNS more secure!  Please do join in and help out.

My Report into For Immediate Release (FIR) Podcast #646

In this week's For Immediate Release episode #646, my report covered:

If you are a FIR subscriber, you should have the show now in iTunes or whatever you use to get the feed. If you aren't a subscriber, you can simply listen to the episode online now.

If you found this post interesting or useful, please consider either: