Category: Security

Apr 27

Watch Live on Friday, 29 April – Kathy Brown At G7 ICT Multi-Stakeholder Conference

On Friday, April 29, you can watch leaders of the technical community, business and civil society address the G7 ICT Ministers at:

The Multi-Stakeholders Conference begins at 9:00 am Japan Standard Time (UTC+9), which is:

  • midnight UTC
  • 2:00 am Central European Time
  • 8:00 pm, Thursday, April 28, Eastern Daylight Time

Internet Society President and CEO Kathy Brown will speak as part of a panel starting at 10:45 am JST. The panel topic is “Sharing common thoughts about Internet governance and cybersecurity“. The other panelists are senior executives from Hitachi, NTT and BT Security. Kathy has published her thoughts about what she will say in the session.

The full agenda for the Multi-Stakeholder Conference is available on the G7 event site.

In preparation for the session, we encourage you to read:

During the event you can also follow our tweets on @ISOCPolicy .

The post Watch Live on Friday, 29 April – Kathy Brown At G7 ICT Multi-Stakeholder Conference appeared first on Internet Society.

Mar 27

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
Agenda: https://datatracker.ietf.org/meeting/95/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/
Charter: http://tools.ietf.org/wg/uta/charters/

TRANS (Public Notary Transparency) WG
Monday, 4 April 2016, 1550-1720 ART, Room Quebracho A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: http://tools.ietf.org/wg/trans/charters/

DNSSD (Extensions for Scalable Service Discovery) WG
Monday, 4 April 2016, 1550-1720 ART, Room Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

CURDLE (CURves, Deprecating and a Little more Encryption) WG
Tuesday, 5 April 2016, 1620-1720 ART, Room Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/curdle/
Documents: https://datatracker.ietf.org/wg/curdle/
Charter: http://tools.ietf.org/wg/curdle/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 6 April 2016, 1000-1230 ART, Room Atlantico C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

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
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

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 https://www.internetsociety.org/tag/ietf95/.

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

Jan 31

Audio Recording: My SIPNOC 2014 Talk – "Is It Time For TLS For SIP?"

Is it time to use Transport Layer Security (TLS... essentially what we used to call "SSL") to add a layer of trust and security to Voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)?

Way back in June 2014, I gave a talk on this topic at the SIP Network Operators Conference (SIPNOC) in Herndon, Virginia. I recorded the audio of the session... but then lost track of the recording. I recently found it and, since much of it is (sadly) still relevant, I decided to release the recording as one of my The Dan York Report audio podcast episodes:

The slides that go with the presentation are available on SlideShare:

You'll see in the slide deck that I also provide some tutorials around DANE and DNSSEC along the way.

Coincidentally, I learned on Facebook over the weekend that my friend Olle Johansson was speaking on this exact topic at the FOSDEM 2016 conference in Brussels this weekend. His slides about SIP & TLS are also available on SlideShare, and he has more recent information - and also the conclusion that we need to use "SIP Outbound" for any of this to work:

Olle's last slide about what we need to do hits on the key points - and I agree with his conclusions.

Let's look at how we can get more TLS used within SIP to bring about a more secure and trusted VoIP infrastructure!

Jul 14

This Week: Watch Internet Society President & CEO Kathy Brown Speak About Collaborative Governance And Security

How do Collaborative Governance and Collaborative Security bring about a stronger and more trusted Internet that enables more opportunity for people around the world?  What do these approaches mean for the future of Internet governance? What actions can people take as part of our collective responsibility for the future of the open Internet?

Today and tomorrow you will have two opportunities to hear Internet Society President and CEO Kathy Brown speak about these points and more on live video streams.

First, today, Wednesday, July 15, 2015, starting at 12:15pm US Eastern (UTC-4), Kathy will be speaking at an event by the Hudson Institute in Washington, DC, titled: “Collaborative Governance and Security: A Stronger Internet for the Future“. The Hudson Institute staff indicate the live video stream will be available at:

http://www.hudson.org/events/1264-collaborative-governance-and-security-a-stronger-internet-for-the-future72015

They also seem to live-tweet many of their sessions using @HudsonEvents on Twitter.

Tomorrow, Thursday, July 16th, Kathy will be at the Internet Governance Forum USA (IGF-USA) giving keynote remarks during the session between 1:00 – 1:50 pm US Eastern. My colleague Paul Brigner wrote about the IGF-USA yesterday outlining what is going on and indicating that the live video streams will be at:

http://www.isoc-dc.org/isoc-dc-tv/

The full agenda can be found on the IGF-USA site, as well as information about how to attend in person.

Both of Kathy’s presentations today and tomorrow will be recorded so that you can view them later.

We hope you do get a chance to watch either (or both) of Kathy’s sessions and learn more about what we are doing with collaborative governance and collaborative security.

If you would like to learn more right now you can visit these links:

 

The post This Week: Watch Internet Society President & CEO Kathy Brown Speak About Collaborative Governance And Security appeared first on Internet Society.

Jul 06

Join InterCommunity 2015 on July 7/8 to talk about Internet security!

InterCommunity 2015 logoThis week you have a unique opportunity to offer your opinion on how we can make the Internet more secure!  On July 7 and 8 our global Internet Society membership meeting, InterCommunity 2015, will bring together thousands of people all around the world to address critical questions around the future of the Internet – how it is governed, how it is secured and how we bring the rest of the world online.  YOU CAN JOIN IN DIRECTLY by going to this site to register:

https://www.internetsociety.org/intercommunity2015/

You can join in from your computer or mobile device in your home, at your office or wherever you can get connectivity.

This is a global meeting happening ON the Internet – and FOR the Internet!

In some cities across the world we will have “regional nodes” where people will be gathering together in a location to join into conversations with each other – and then to join into the global conversation.  You are welcome to gather in one of those locations… or to join in from wherever you are.  There are opportunities to connect in and have your voice heard from wherever you can connect.

As you can see on the InterCommunity agenda, the meeting will be running twice to bring in everyone around the world and will have different people and different segments.  The goal is to bring all our members together, to exchange views and to come together to use our collective strength to address these critical issues and bring about a stronger and more secure Internet.

Please READ THIS POST from Internet Society President and CEO Kathy Brown for more information!

I’ll actually be in Ottawa, Ontario, Canada, at the regional node there where I’ll be leading part of the global conversation about collaborative security and how we can all work together to make the Internet more secure.  If you are there in Ottawa, I look forward to meeting you face-to-face.  If you are online, I look forward to interacting with you.  The topics we cover here on Deploy360 are all about making the Internet more secure and accessible… all key themes here in InterCommunity 2015!

Please join with us!  It’s gonna be great!

P.S. What?  You aren’t a member of the Internet Society?  No worries… it’s free to join and become a member!

Dec 29

ERNW Compares Penetration Testing Tools IPv6 Support

ERNW December NewsletterWhich network security penetration testing tools support IPv6?  What caveats should you know about the ones that do support IPv6?

Recently the team as security firm ERNW published their December 2014 newsletter with the headline “Penetration Testing Tools that (do not) Support IPv6” where they took a lengthy tour through a wide range of security tools to assess their IPv6 readiness.  As they say in their introduction, their goals were to:

  • Find out which of our favorite penetration testing tools can be used natively using IPv6 as an underlying layer-3 protocol.
  • Find alternative solutions for the rest

They specifically only tested open source or free versions of commercial tools and did not test IPv6-specific tools.  They were seeking to understand which of the commonly available current (IPv4) test tools also worked well with IPv6.

The bulk of the document (pages 9-51) consists of walk-throughs of exploration of each of the various tools in different categories.  They examine the tool, provide screenshots in many cases and then state a conclusion about how well or not the tool supports IPv6.

What I personally found most useful was section 15, the Appendix, starting on page 56 that provided a table view with a list of all the tools tested and a quick summary of how well (or not) the tool supported IPv6.

If you are interested in security testing and specifically for IPv6 networks, this document is definitely worth a read!

And if you are new to IPv6 and want to learn more, please visit our Start Here page to find resources targeted at your role or type of organization.

 

Dec 19

SS7 Security On Techmeme? A Reminder About Interconnected Systems…

techmeme-ss7SS7 security issues reported on Techmeme?  I did a double-take yesterday and, as Jay Cuthrell noted on Twitter, wondered if this was a “ThrowbackThursday” taken to the extreme.  But no, there was indeed a report in the Washington Post about German security researchers discovering that aspects of SS7 signaling that could be used to listen to phone conversations and/or read text messages on mobile networks.  As the article notes:

The flaws discovered by the German researchers are actually functions built into SS7 for other purposes – such as keeping calls connected as users speed down highways, switching from cell tower to cell tower – that hackers can repurpose for surveillance because of the lax security on the network.

The researchers noted that one of the attackers could get around existing encryption mechanisms used on mobile networks:

For calls or texts transmitted using strong encryption, such as is commonly used for advanced 3G connections, hackers could request through SS7 that each caller’s carrier release a temporary encryption key to unlock the communication after it has been recorded.

SS7, or Signalling System 7, is of course the dominant set of telephony signaling protocols used in the legacy Public Switched Telephone Network (PSTN) made up of today’s wired and wireless (mobile) telephone networks.  As such, we don’t write about SS7 hardly at all here on the VOIPSA blog as it is not related to VoIP.

However, there were three important thoughts to me coming out of this article:

1. VoIP can be more secure than the PSTN. The report mentions the encryption of the underlying 3G transport infrastructure being subverted.  However, with VoIP apps that are “Over-The-Top” (OTT) riding on the mobile data network, the encryption can happen from within the app on one mobile device all the way to the app on the other mobile device – or at least back to a central set of servers.  Now, there can be other security vulnerabilities with such a system, but the transport layer could at least be secured.

2. Telecommunication systems are only as secure as their weakest link – and are interconnected.  The bigger concern is of course that most of our telecom systems are all interconnected… and you can have the most secure VoIP system in the world, but if you wind up connecting to the PSTN – and specifically in this case to mobile PSTN networks – then you are open to exactly these kind of attacks.  Obviously if you are communicating only within an OTT “walled garden” where you only talk to others using the same OTT app you can be secure, but the moment you go out to the PSTN you are open to all the issues there.

3. Fixed lines are no safer if you talk to mobile users. The article ends with a German senator saying “When I really need a confidential conversation, I use a fixed-line phone“.  I don’t know about that.  For one thing, if the person you are calling is a mobile phone user, you are again open to these kind of attacks.  Secondly the Snowden revelations of the past year have certainly shown us that large agencies have the ability to listen in to communications on the networks of the PSTN.  If I absolutely want a confidential conversation, I’m personally going to use one of the VoIP applications that has end-to-end encryption. I’m NOT going to trust a fixed line any more than I would trust a mobile phone.

And I guess the final thought is of course that the legacy PSTN is full of security issues – they just aren’t necessarily as open to all to see because of the more closed nature of the traditional telephone networks.

A good reminder, though, that telephony security has always been a problem – and we need to ensure that both our VoIP and traditional networks have adequate security.

Meanwhile, it was rather fun to see SS7 mentioned on Techmeme… not something you’d expect to see!

Dec 08

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.

But…

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.

 

Oct 31

Slides: Reboot the Open Realtime Revolution – #MoreCrypto (Fall 2014)

Olle Johansson is back with another set of excellent slides about VoIP security and the need to have “MoreCrypto” everywhere. It’s a great set of slides that talks about where we have come from and where we need to go.  Definitely check it out on SlideShare at: Reboot the Open Realtime Revolution – #MoreCrypto (Fall 2014) or in the embedded version below:

Oct 24

DNSSEC Is A Building Block, Not A Magic Bullet

Olaf KolkmanSpeaking at Broadband World Forum (BBWF) in Amsterdam this week, our CITO Olaf Kolkman was quoted as saying a key point we’ve been emphasizing throughout our work:

“There is no magic solution to any cyber security or internet security type of threat. But there are a number of building blocks that are promising.”

They include domain name system security extensions (DNSSEC), which help to secure certain kinds of information on networks.

“But they’re building blocks, they’re not magic bullets,” he said.

Exactly!

When we speak about DNSSEC or TLS  or BGP security, we are often immediately met by detractors with “But it doesn’t do ______” which, in their minds, immediately disqualifies the technology from further usage.  Often this is said, even though DNSSEC/TLS/BGP was never intended to do whatever it is they want.  They just expect the technology to magically do it all!

For example, with DNSSEC, some people immediately say “but it doesn’t protect against the confidentiality of your DNS queries!”  Well, no, it was never intended for that.  DNSSEC is entirely about protecting the integrity of your DNS queries, i.e. ensuring that the information you receive from DNS is the identical information that the operator of the domain put into DNS.  That’s it.  Confidentiality of DNS queries is something completely different! (And is now being discussed by the new DPRIVE working group inside the IETF.)

And by being a smaller building block, DNSSEC can be built upon to bring about powerful new innovations such as the DANE protocol, where we can add an additional layer of trust to TLS / SSL certificates and interactions.

What has made the Internet work so well on a technical level and evolve into the amazing communications medium that it has become is the fact that it is built from small building blocks that are then loosely coupled together in ways that make sense.

Building blocks, not magic bullets!

P.S. And if you want to get started with security building blocks like DNSSEC, please visit our Start Here page!