July 31, 2015 archive

Jul 31

Firechat Enables Private Off-The-Internet (P2P) Messaging Using Mobile Phones

Firechat mesh network

There was a fascinating article posted on Medium this week by the CTO of messaging app Firechat:

In the text he outlines how they do decentralized "off-the-grid" private messaging using an ad hoc mesh network established between users of the Firechat app. It sounds like the app instances join together into some kind of peer-to-peer (P2P) network and then do normal "store-and-forward" messaging.

Of note, the apps do NOT need an Internet connection, or even a cellular network connection - instead they can use the Bluetooth and WiFi radios in the mobile phones to create a private mesh network and connect to other users of the Firechat app.

Naturally, having spent some time exploring P2P networks back when I was playing around with P2P SIP and distributed hash tables (DHTs) and other technologies, I immediately jump into the techie questions:

  • How are they routing messages from one user to another?
  • How is the "directory" of users in P2P mesh maintained?
  • What addresses are they using for the communication? Is this still happening over IP addresses? Or are they using some other kind of addressing?
  • How do users join and leave the mesh network?
  • How do user get authorized to join the private mesh? (Or is it just open to all?)
  • How secure is the communication between the parties?
  • Is the message encrypted or private in any way? Or is it just plain text?
  • How well do smartphone batteries hold up if multiple radios are being used? What is the power impact of joining into a mesh network like this?

None of that is covered in this article, of course... this piece is more about the theory of how this can work given a particular density of users. It introduces the phrase "percolation threshold" and provides some background and research into how these kind of networks can be created.

I've always been fascinated by P2P networks like this sounds to be. The beauty of the Internet... the "Internet Way", so to speak... has been to support distributed and decentralized architectures.

If you think about mail or web servers, they are (or at least were) massively distributed. Anyone could set up a mail or web server - and millions upon millions of them bloomed. While we've certainly seen a great amount of centralization due to market dominance (ex. Gmail), the architecture still is distributed / decentralized.

Except... of course, the directory is still centralized. Mail and web servers rely on the central directory of DNS to resolve domain names into IP addresses so that connections can occur. Most other applications rely on DNS for this as well.

Hence my curiousity about how Firechat is handling the directory and routing issues.

I'm also intrigued by how the article hints at integrating Internet-connected users into the P2P mesh. So you really have a hybrid network that is part P2P and part connected out to cloud-based servers.

(And all of this brings me back to those early days of Skype 8-10 years ago when so many of us were captivated by the P2P mechanisms they created... most all of which is now gone in the post-Microsoft-acquisition as Skype has moved from P2P to server/cloud-based - with one big reason being given that mobile devices apparently had speed and battery life issues participating in true P2P networks.)

A key challenge Firechat faces, of course, is the "directory dilemma" of building up the quantity of users where P2P mesh networks like this can happen. This is the same dilemma facing basically all over-the-top (OTT) messaging apps. "Percolation theory" requires a certain user density for a mesh like this to work.

That will be their struggle.

And in some urban areas I can see this working quite well. Perhaps not so much out in the woods of New Hampshire where I live!

But I wish them well with this. I love to see new explorations of potential new architectures for communication. And I can certainly see instances when ad hoc, distributed/decentralized P2P meshes like these could be quite useful.

And I'm definitely looking forward to some more technical articles that dive down into some of these questions.... I do hope they'll write more soon!

Photo credit: Stanislav Shalunov's article about Firechat

Jul 31

Firewalls Now Looking At Intercepting SSH Traffic Via A MITM Attack

conexion manual ssh

Can you trust Secure Shell (SSH) when you are behind certain firewalls? That’s the question raised by a post from a friend of mine:

Lies, Damn Lies, and Inspecting SSH Traffic Securely

It seems that because ssh can be used for tunneling services and application traffic several firewall vendors are now implementing “SSH inspection” services that essentially perform a Man-in-The-Middle (MITM) attack on your ssh connection.

When you go to ssh into a server, the firewall pretends it is that server and creates a ssh tunnel with you. The firewall then creates the actual ssh connection to the server and passes your packets from the first tunnel into the second tunnel – while being able to log or inspect the packets in between the two tunnels.

Now, of course with ssh you go through an initial handshake when you first connect to a server that results in the server’s public key being added to your list of known hosts.

If you connect to a server for the first time BEFORE being behind one of these firewalls doing SSH inspection, you would already have the correct public key of the server in your known hosts file. What would happen when the firewall tried to do a MITM is that you would be asked to approve the public key of the server again. (Because you are actually now approving the public key of the firewall.)

You would have to realize that this was wrong and stop your connection!

If you proceeded ahead with the connection and approving the public key, you would now have the firewall as a MITM.

If you connect to a server for the first time AFTER being behind one of these firewalls, well… I’m not sure what you can do. You’re going to see a public key to approve, but it would be from the firewall! You’d have to somehow learn the correct public key of the target server to be able to match it to the fingerprint you are being shown.

I don’t know how well that will work.

The good news for me personally is that I’m not behind these kind of firewalls in my regular networks – although I don’t honestly know what my Internet service providers are using. They could be doing these kind of things.

I don’t consider this a good thing that firewalls are now doing this. We need to trust the security of services like SSH. This decreases overall trust.

Photo credit: El Taller del Bit on Flickr

Jul 31

Call for Participation – DNSSEC Workshop at ICANN 54 in Dublin, Ireland (Featured Blog)

Would you like to present an idea you have related to DNSSEC or DANE to a gathering of people within the DNSSEC community? Do you have an idea for a new tool or service? Have you recently implemented DNSSEC or DANE and want to share your story? The deadline is Monday, August 17, so please send your proposal soon! We are open to proposals on a wide range of topics... More...

Jul 31

Call for Participation – DNSSEC Workshop at ICANN 54 in Dublin, Ireland (Featured Blog)

More...

Jul 31

Call for Participation – DNSSEC Workshop at ICANN 54 in Dublin, Ireland

ICANN 54 DublinThe 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 54 meeting on 21 October in Dublin, Ireland. 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 Buenos Aires, Argentina on 24 June 2015. The presentations and transcripts are available at: https://buenosaires53.icann.org/en/schedule/wed-dnssec.

At ICANN 54 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include:

  • Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email.
  • Tools for automating the generation of DNSSEC/DANE records.
  • Services for monitoring or managing DNSSEC signing or validation.
  • Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG.
  • Innovative uses of APIs to do something new and different using DNSSEC/DANE.
  • S/MIME and Microsoft Outlook integration with active directory.

Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet.

We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include:

1. DNSSEC activities in Europe

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Europe 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: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn’t it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

2. Potential impacts of Root Key Rollover

Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys. We would like to be able to offer suggestions out of this panel to the wider technical community. If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

3. 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:

  • Can you describe your experiences with negative Trust Anchors and operational realities?
  • 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.)?

4. 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?

5. DANE and DNSSEC application automation

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also 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 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 are the best opportunities for automation within DNSSEC signing and validation processes?
  • What are the costs and benefits of different approaches to automation?
  • 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 use 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 application automation 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. 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?

7. DNSSEC and DANE in the enterprise

Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes 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?

8. Hardware Security Modules (HSMs) use cases and innovation

We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.

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-dublin@isoc.org by **Monday, 17 August 2015**

We hope that you can join us.

On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Julie Hedlund, ICANN
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Jul 31

Call for Participation – DNSSEC Workshop at ICANN 54 in Dublin, Ireland

ICANN 54 logoWould you like to present an idea you have related to DNSSEC or DANE to a gathering of people within the DNSSEC community?  Do you have an idea for a new tool or service? Have you recently implemented DNSSEC or DANE and want to share your story?

If so – and if you will be attending ICANN 54 in Dublin on October 21 – please send a brief 1-2 sentence proposal to:

dnssec-dublin@isoc.org

The deadline is Monday, August 17, so please send your proposal soon!

We are open to proposals on a wide range of topics – the full Call for Participation is included below with suggestions to help, but we are also open to proposals on pretty much any topic related to DNSSEC / DANE / DNS security.

Call For Participation

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 54 meeting on 21 October in Dublin, Ireland.  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 Buenos Aires, Argentina on 24 June 2015. The presentations and transcripts are available at: https://buenosaires53.icann.org/en/schedule/wed-dnssec.

At ICANN 54 we are particularly interested in live demonstrations of uses of DNSSEC or DANE.  Examples might include:

  • Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email.
  • Tools for automating the generation of DNSSEC/DANE records.
  • Services for monitoring or managing DNSSEC signing or validation.
  • Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG.
  • Innovative uses of APIs to do something new and different using DNSSEC/DANE.
  • S/MIME and Microsoft Outlook integration with active directory.

Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet.

We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE.  Examples of the types of topics we are seeking include:

1.  DNSSEC activities in Europe

For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Europe 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:  Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn’t it do?  What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC?  We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers.

2.  Potential impacts of Root Key Rollover

Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys.  We would like to be able to offer suggestions out of this panel to the wider technical community.  If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you.

3.  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:

  • Can you describe your experiences with negative Trust Anchors and operational realities?
  • 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.)?

4. 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?

5.  DANE and DNSSEC application automation

For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also 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 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 are the best opportunities for automation within DNSSEC signing and validation processes?
  • What are the costs and benefits of different approaches to automation?
  • 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 use 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 application automation 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.  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?

7.  DNSSEC and DANE in the enterprise

Enterprises can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes 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?

8. Hardware Security Modules (HSMs) use cases and innovation

We are interested in demonstrations of HSMs, presentations of HSM-related innovations and real world use cases of HSMs and key management.

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-dublin@isoc.org by **Monday, 17 August 2015**

We hope that you can join us.

On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Cath Goulding, Nominet UK
Julie Hedlund, ICANN
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Luciano Minuchin, NIC.AR
Russ Mundy, Parsons
Ondřej Surý, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society