CircleID

When the Backend Domain Name Registry Is Too Expensive

2018-06-27T09:03:00-08:00

What we call a "backend registry" is the mandatory technical platform to operate a domain name extension and all registries have one. It is the backend registry that allows accredited registrars to technically sell domain names for each top-level domain (TLD).

The question here is: what happens to a registry, who sells domain names to accredited registrars when his backend registry solution provider is too expensive?

Creating your backend registry solution

In 2008, I remember going to a .BRAND meeting with Stephane Van Gelder and a technical guy told us: "we don't need a backend registry, we have enough resources to do it ourselves". Well… one can try to do it so for the next round of the ICANN new gTLD program — and there are tools for this — but I would certainly not recommend it for three reasons:

It requires serious skills to develop a backend registry platform;
It requires to pass the ICANN tests;
It's awfully expensive.

How to lower the expenses

There are less than 10 solution providers that I would work with worldwide, and the reason why I would not create my own backend registry solution is simple: the more your new gTLD project costs you, the more you will be tempted to increase the price of your domain names. Accredited Registrars, the ones Registries sell their domain names to, will have to take a margin so they will increase the price too, and here is what happens next:

1) The final price at the Registrant level (the person who buys the domain name) will be higher than a ".com"; it may be a bad sign sent to new consumers: "Hey, why should I pay more for a domain name?" Remember that the average price known to consumers for a domain name is between $10 and $12;
2) It will make your registry more difficult to develop the volume of domain names if your target is the general public. For domain names to meet with adoption: "use" is needed but "volume" is needed too to increase its visibility on Internet.

Think twice about creating your own backend registry solution: it will drastically increase the price of your new gTLD project.

Note that 500 registries have less than 10,000 domain names registered but is this what a new registry wants when creating a new domain name extension? I stopped counting at 200 domain names registered (June 2018) to exclude .BRAND new gTLDs from this approximate calculation.

Less than $2 per domain

Backend registry service providers offer a different range of services but there is now stronger competition between them and offers should change for the next round of the ICANN new gTLD program. Prices should change too and there are three parameters that I will focus on when selecting a backend registry provider:

One price per domain name "only" should constitute the offer: a registry which wants to gain recognition cannot be blocked from lowering the price of his domain names because the annual financial commitment with his backend registry is too high: let's not forget that the more domain names a registry puts on the market, the more it benefits the backend registry.
No leaving fee: the knowledge to operate a registry relies a lot on the backend registry solution provider but it has now become easier and, for example, one might be tempted to change to a Chinese solution provider to access the profitable Chinese market with an MIIT license. Once you're blocked with an important leaving fee, it blocks you from spending this money to find a better solution: a Chinese backend registry solution provider will be very efficient combining complementary solutions for you: the backend registry solution plus the MIIT license for example.
A "minimum annual commitment"? I read this fee at a service provider (...) With the number of registries to have launched at the same time in 2012, how can a niche TLD survive when it sells less than 1,000 domains a year (also because its retail price is already too high)? Added to a leaving fee, it makes it almost impossible to develop. For some, it means going "bankrupt". ~~By the way: a backend registry asking for a minimum annual commitment does not care about the success of your project~~.

Note that such offers already exist: some providers have adapted to the market. It costs less than $1 for certain registries to create a domain name: "the lower the price is at the backend, the lower it will be for your clients".

If the backend registry is too expensive… it will impact the final price of your domain names at Registrars and it is unlikely that new consumers will want to pay more than $12 to buy them. Registration volumes seem to confirm this: when new gTLD registration volumes are low, it is also because the price of domain names is often too high, the reason is that.

Written by Jean Guillon, New generic Top-Level Domains' specialist

Follow CircleID on Twitter

More under: Domain Names, Registry Services, New TLDs

Will Cisco Make a Comeback in Cuba?

2018-06-26T19:20:00-08:00

Laura Quintana, Cisco Vice President of Corporate Affairs, launching Cisco networking training at the Universidad de Ciencias InformáticasIs the recently announced Cisco Networking Academy at the Universidad de Ciencias Informáticas a belated drop in the bucket or the first step in a significant opening?

Cisco dominated the infrastructure equipment market in Cuba and elsewhere during the early days of the Internet, but Huawei replaced them in Cuba — here is a timeline:

President Eisenhower severed diplomatic relations with Cuba and blocked nearly all trade with the US in 1960 (timeline).
President Kennedy's administration imposed a complete economic embargo in 1962.
In spite of that, the US National Science Foundation provided Cuba's first link to the global internet in 1996 using Cisco equipment that was probably acquired through other nations.
The 1996 Helms-Burton Act added penalties for foreign nations doing business with Cuba and said the embargo could not be lifted while the Castros were in power.
In 1997, Cisco began offering Cisco Networking Academy (CNA) training.
In 2000, Huawei entered the Cuban market and won a contract to build a fiber backbone.
In 2000 Huawei began replacing Cisco routers.
In 2015, Doug Madory discovered what may be the last Cisco router in Cuba.
In 2016, President Obama announced that Cisco would be offering their Cisco Networking Academy (CNA) training at the Universidad de Ciencias Informáticas (UCI).
The CNA program was inaugurated last week and is expected to train over 100 engineers per year.

What does this mean?

It might be a belated drop in the bucket. UCI has only 19 trained CNA instructors while the CNA curriculum is being taught by over 20,000 instructors at over 10,000 institutions.

On the other hand, this might be the first step in a significant opening. The Castros are no longer in power — might the US allow Cisco to sell equipment to Cuba and might the Cubans consider Cisco as a competitor to Huawei, SES, and other connectivity providers?

The Trump administration has cracked down on individual travel but has not curtailed the sales of communication equipment to Cuba. Trump would doubtless like to claim credit for any Cuban sales by Cisco and for Raúl Castro stepping down and he is indifferent to human rights violation, so my guess is that the US would allow Cisco to sell to Cuba.

Similarly, competition from Cisco would enhance Cuba's bargaining position with Huawei and, while much of their SNA material is generic, some is Cisco-specific, giving them an advantage. I don't know if Cisco is charging for their training or equipment, but they may be donating it as a marketing and international public-relations expense. (In the mainframe days, IBM gave significant discounts and subsidies to universities so students would be trained on their equipment. They even built the building to house the computers at the UCLA Western Data Processing Center where I was a student).

It's too soon to know if this is an important first step and it will be interesting to see how events unfold. A good start would be for the US to allow Cubans access to Cisco's online CNA courses and for UCI to expand their initial internal offering and to train CNA instructors at schools and organizations like the Unión de Informáticos, ETECSA, networks like Infomed, and the Joven Clubs.

President Obama announced the Cisco-UCI SNA plan over two years ago. Two years from now, we will know whether it is significant for either Cisco or Cuba.

Written by Larry Press, Professor of Information Systems at California State University

Follow CircleID on Twitter

More under: Broadband, Networks, Policy & Regulation

Internet Evolution: Another 10 Years Later

2018-06-25T15:15:00-08:00

Ten years ago, I wrote an article that looked back on the developments within the Internet over the period from 1998 to 2008. Well, another ten years have gone by, and it's a good opportunity to take a little time once more to muse over what's new, what's old and what's been forgotten in another decade of the Internet's evolution.

The evolutionary path of any technology can often take strange and unanticipated turns and twists. At some points, simplicity and minimalism can be replaced by complexity and ornamentation, while at other times a dramatic cut-through exposes the core concepts of the technology and removes layers of superfluous additions. The evolution of the Internet appears to be no exception and contains these same forms of unanticipated turns and twists. In thinking about the technology of the Internet over the last ten years, it appears that it's been a very mixed story about what's changed and what's stayed the same.

A lot of the Internet today looks much the same as the Internet of a decade ago. Much of the Internet's infrastructure has stubbornly resisted various efforts to engender change. We are still in the middle of the process to transition the Internet to IPv6, which was the case a decade ago. We are still trying to improve the resilience of the Internet to various attack vectors, which was the case a decade ago. We are still grappling with various efforts to provide defined quality of service in the network, which was the case a decade ago. It seems that the rapid pace of technical change in the 1990's and early 2000's has simply run out of momentum and it seems that the dominant activity on the Internet over the past decade was consolidation rather than continued technical evolution. Perhaps this increased resistance to change is because as the size of the network increases, its inertial mass also increases. We used to quote Metcalf's Law to each other, reciting the mantra that the value of a network increases in proportion to the square of the number of users. A related observation appears to be that a network's inherent resistance to change, or inertial mass, is also directly related to the square of the number of users as well. Perhaps as a general observation, all large loosely coupled distributed systems are strongly resistant to efforts to orchestrate a coordinated change. At best, these systems respond to various forms of market pressures, but as the Internet's overall system is so large and so diverse, these market pressures manifest themselves in different ways in different parts of this network. Individual actors operate under no centrally orchestrated set of instructions or constraints. Where change occurs, it is because some sufficiently large body of individual actors see opportunity in undertaking the change or perceive unacceptable risk in not changing. The result for the Internet appears to be that some changes are very challenging, while others look like natural and inevitable progressive steps.

But the other side of the story is one that is about as diametrically opposed as its possible to paint. Over the last decade, we've seen another profound revolution in the Internet as it embraced a combination of wireless-based infrastructure and a rich set of services at a speed which has been unprecedented. We've seen a revolution in content and content provision that has not only changed the Internet but as collateral damage, the Internet appears to be decimating the traditional newspaper and broadcast television sectors. Social media has all but replaced the social role of the telephone and the practice of letter writing. We've seen the rise of the resurgence of a novel twist to the old central mainframe service in the guise of the 'cloud' and the repurposing of Internet devices to support views of a common cloud-hosted content that in many ways mimic the function of display terminals of a bygone past. All of these are fundamental changes to the Internet and all of these have occurred in the last decade!

That's a significant breadth of material to cover, so I'll keep the story to the larger themes, and to structure this story, rather than offer a set of unordered observations about the various changes and developments over the past decade, I'll use a standard model of a protocol stack as the guiding template. I'll start with the underlying transmission media and then looking at IP, the transport layer, then applications and services, and closing with a look at the business of the Internet to highlight the last decade's developments.

Below the IP Layer

What's changed in network media?

Optical systems have undergone a sustained change in the past decade. A little over a decade ago production optical systems used simple on-off keying to encode the signal into the optical channel. The speed increases in this generation of optical systems relied on improvements in the silicon control systems and the laser driver chips. The introduction of wavelength division multiplexing in the late 1990's allowed the carriers to greatly increase the carrying capacity of their optical cable infrastructure. The last decade has seen the evolution of optical systems into areas of polarisation and phase modulation to effectively lift the number of bits of signal per baud. These days 100Gbps optical channels are commonly supportable, and we are looking at further refinements in signal detection to lift that beyond 200Gbps. We anticipate 400Gbps systems in the near future, using various combinations of a faster basic baud rate and higher levels of phase amplitude modulation, and dare to think that 1Tbps is now a distinct near-term optical service.

Radio systems have seen a similar evolution in overall capacity. Basic improvements in signal processing, analogous to the changes in optical systems, has allowed the use of phase modulation to lift the data rate of the radio bearer. The use of MIMO technology, coupled with the use of higher carrier frequencies has allowed the mobile data service to support carriage services of up to 100Mbps in today's 4G networks. The push to even higher frequencies promises speeds of up to 1Gbps for mobile systems in the near future with the deployment of 5G technology.

While optical speeds are increasing, ethernet packet framing still persists in transmission systems long after the original rationale for the packet format died along with that bright yellow coaxial cable! Oddly enough, the Ethernet-defined minimum and maximum packet sizes of 64 and 1500 octets still persist. The inevitable result of faster transmission speeds with constant packet sizes results in an upper bound of the number of packets per second increasing more 100-fold over the past decade, in line with the increase of deployed transmission speeds from 2.5Gbps to 400 Gbps. As a consequence, higher packet processing rates are being demanded from silicon-based switches. But one really important scaling factor has not changed for the past decade, namely the clock speed of processors and the cycle time of memory, which has not moved at all. The response so far has been in increasing reliance of parallelism in high-speed digital switching applications, and these days multi-core processors and highly parallel memory systems are used to achieve performance that would be impossible in a single threaded processing model.

In 2018 it appears that we are close to achieving 1Tbps optical systems and up to 20Gbps in radio systems. Just how far and how quickly these transmission models can be pushed into supporting ever higher channel speeds is an open question.

The IP Layer

The most notable aspect of the network that appears to stubbornly resist all forms of pressure over the last decade, including some harsh realities of acute scarcity, is the observation that we are still running what is essentially an IPv4 Internet.

Over this past decade we have exhausted our pools of remaining IPv4 addresses, and in most parts of the world, the IPv4 Internet is running on some form of empty. We had never suspected that the Internet would confront the exhaustion of one its most fundamental pillars, the basic function of uniquely addressing connected devices, and apparently shrug it off and continue on blithely. But, unexpectedly, that's exactly what's happened.

Today we estimate that some 3.4 billion people are regular users of the Internet, and there are some 20 billion devices connected to it. We have achieved this using some 3 billion unique IPv4 addresses. Nobody thought that we could achieve this astonishing feat, yet it has happened with almost no fanfare.

Back in the 1900's we had thought that the prospect of address exhaustion would propel the Internet to use IPv6. This was the successor IP protocol that comes with a four-fold increase in the bit width of IP addresses. By increasing the IP address pool to some esoterically large number of unique addresses (340 undecillion addresses, or 3.4 x 1038) we would never have to confront network address exhaustion again. But this was not going to be an easy transition. There is no backward compatibility in this protocol transition, so everything has to change. Every device, every router and even every application needs to change to support IPv6. Rather than perform comprehensive protocol surgery on the Internet and change every part of the infrastructure to support IPv6, we changed the basic architecture of the Internet instead. Oddly enough, it looks like this was the cheaper option!

Through the almost ubiquitous deployment of Network Address Translators (NATs) at the edges of the network, we've transformed the network from a peer-to-peer network into a client/server network. In today's client/server Internet clients can talk to servers, and servers can talk back to these connected clients, but that's it. Clients cannot talk directly to other clients, and servers need to wait for the client to initiate a conversation in order to talk to a client. Clients 'borrow' an endpoint address when they are talking to a server and release this address for use by other clients when they are idle. After all, endpoint addresses are only useful to clients in order to talk to servers. The result is that we've managed to cram some 20 billion devices into an Internet that only has deployed just 3 billion public address slots. We've achieved this through embracing what could be described as time-sharing of IP addresses.

All well and good, but what about IPv6? Do we still need it? If so, then are we going to complete this protracted transition? Ten years later the answer to these questions remains unclear. On the positive side, there is a lot more IPv6 around now than there was ten years ago. Service Providers are deploying much IPv6 today than was the case in 2008. When IPv6 is deployed within a Service Provider's network we see an immediate uptake from these IPv6-equipped devices. In 2018 it appears that one-fifth of the Internet's users (that itself is now estimated to number around one half of the planet's human population) are capable of using the Internet over IPv6, and most of this has happened in the past 10 years. However, on the negative side, the question must be asked: What's happening with IPv6 for the other four-fifths of the Internet? Some ISPs have been heard to make the case that they would prefer to spend their finite operating budgets on other areas that improve their customers' experience such as increasing network capacity, removing data caps, acquiring more on-net content. Such ISPs continue to see the deployment of IPv6 as a deferable measure.

It seems that today we are still seeing a mixed picture for IPv6. Some service providers simply see no way around their particular predicament of IPv4 address scarcity and these providers see IPv6 as a necessary decision to further expand their network. Other providers are willing to defer the question to some undefined point in the future.

Routing

While we are looking at what's largely unchanged over the past decade we need to mention the routing system. Despite dire predictions of the imminent scaling death of the Border Gateway Protocol (BGP) ten years ago, BGP has steadfastly continued to route the entire Internet. Yes, BGP is as insecure as ever, and yes, a continual stream of fat finger foul-ups and less common but more concerning malicious route hijacks continue to plague our routing system, but the routing technologies in use in 2008 are the same as we use in today's Internet.

The size of the IPv4 routing table has tripled in the past ten years, growing from 250,000 entries in 2008 to slightly more than 750,000 entries today. The IPv6 routing story is more dramatic, growing from 1,100 entries to 52,000 entries. Yet BGP just quietly continues to work efficiently and effectively. Who would've thought that a protocol that was originally designed to cope with a few thousand routes announced by a few hundred networks could still function effectively across a routing space approaching a million routing entries and a hundred thousand networks!

In the same vein, we have not made any major change to the operation of our interior routing protocols. Larger networks still use either OPSF or ISIS depending on their circumstances, while smaller networks may opt for some distance vector protocol like RIPv2 or even EIGRP. The work in the IETF on more recent routing protocols LISP and BABEL seem to lack any real traction with the Internet at large, and while they both have interesting properties in routing management, neither have a sufficient level of perceived benefit to overcome the considerable inertia of conventional network design and operation. Again, this looks like another instance where inertial mass is exerting its influence to resist change in the network.

Network Operations

Speaking of network operation, we are seeing some stirrings of change, but it appears to be a rather conservative area, and adoption of new network management tools and practices takes time.

The Internet converged on using the Simple Network Management Protocol (SNMP) a quarter of a century ago, and despite its security weaknesses, its inefficiency, its incredibly irritating use of ASN.1, and its use in sustaining some forms of DDOS attacks, it still enjoys widespread use. But SNMP is only a network monitoring protocol, not a network configuration protocol, as anyone who has attempted to use SNMP write operations can attest.

The more recent Netconf and YANG efforts are attempting to pull this area of configuration management into something a little more usable than expect scripts driving CLI interfaces on switches. At the same time, we are seeing orchestration tools such as Ansible, Chef, NAPALM and SALT enter the network operations space, permitting the orchestration of management tasks over thousands of individual components. These network operations management tools are welcome steps forward to improve the state of automated network management, but it's still far short of a desirable endpoint.

In the same time period as we appear to have advanced the state of automated control systems to achieve the driverless autonomous car, the task of fully automated network management appears to have fallen way short of the desired endpoint. Surely it must be feasible to feed an adaptive autonomous control system with the network's infrastructure and available resources, and allow the control system to monitor the network and modify the operating parameters of network components to continuously meet the network's service level objectives? Where's the driverless car for driving networks? Maybe the next ten years might get us there.

The Mobile Internet

Before we move up a layer in the Internet protocol model and look at the evolution of the end-to-end transport layer, we probably need to talk about the evolution of the devices that connect to the Internet.

For many years the Internet was the domain of the desktop personal computer, with laptop devices serving the needs of those with a desire for a more portable device. At the time the phone was still just a phone, and their early forays into the data world were unimpressive.

Apple's iPhone, released in 2007, was a revolutionary device. Boasting a vibrant color touch-sensitive screen, just four keys, a fully functional operating system, with WiFi and cellular radio interfaces, and a capable processor and memory, it's entry into the consumer market space was perhaps the major event of the decade. Apple's early lead was rapidly emulated by Windows and Nokia with their own offerings. Google's position was more as an active disruptor, using an open licensing framework for the Android platform and its associated application ecosystem to empower a collection of handset assemblers. Android is used by Samsung, LG, HTC, Huawei, Sony, and Google to name a few. These days almost 80% of the mobile platforms use Android, and some 17% use Apple's iOS.

For the human Internet, the mobile market is now the Internet-defining market in terms of revenue. There is little in terms of margin or opportunity in the wired network these days, and even the declining margins of these mobile data environments represent a vague glimmer of hope for the one dominant access provider industry.

Essentially, the public Internet is now a platform of apps on mobile devices.

End to End Transport Layer

It's time to move up a level in the protocol stack and look at end-to-end transport protocols and changes that have occurred in the past decade.

End-to-end transport was the revolutionary aspect of the Internet, and the TCP protocol was at the heart of this change. Many other transport protocols require the lower levels of the network protocol stack to present a reliable stream interface to the transport protocol. It was up to the network to create this reliability, performing data integrity checks and data flow control, and repairing data loss within the network as it occurred. TCP dispensed with all of that, and simply assumed an unreliable datagram transport service from the network and pushed to the transport protocol the responsibility for data integrity and flow control.

In the world of TCP not much appears to have changed in the past decade. We've seen some further small refinements in the details of TCP's controlled rate increase and rapid rate decrease, but nothing that shifts the basic behaviors of this protocol. TCP tends to use packet loss as the signal of congestion and oscillates its flow rate between some lower rate and this loss-triggering rate.

Or at least that was the case until quite recently. The situation is poised to change and change in a very fundamental way, with the debut of Google's offerings of BBR and QUIC.

The Bottleneck Bandwidth and Round-trip time control algorithm, or BBR, is a variant of the TCP flow control protocol that operates in a very different mode from other TCP protocols. BBR attempts to maintain a flow rate that sits exactly at the delay-bandwidth product of the end-to-end path between sender and receiver. In so doing, tries to avoid the accumulation of data buffering in the network (when the sending rate exceeds the path capacity), and also tries to avoid leaving idle time in the network (where the sending rate is less than the path capacity). The side effect is that BBR tries to avoid the collapse of network buffering when congestion-based loss occurs. BBR achieves significant efficiencies from both wired and wireless network transmission systems.

The second recent offering from Google also represents a significant shift in the way we use transport protocols. The QUIC protocol looks like a UDP protocol, and from the network's perspective, it is simply a UDP packet stream. But in this case, looks are deceiving. The inner payload of these UDP packets contains a more conventional TCP flow control structure and a TCP stream payload. However, QUIC encrypts its UDP payload so the entire inner TCP control is completely hidden from the network. The ossification of the Internet's transport is due in no small part to the intrusive role of network middleware that is used to discarding packets that it does not recognize. Approaches such as QUIC allow applications to break out of this regime and restore end-to-end flow management as an end-to-end function without any form of network middleware inspection or manipulation. I'd call this development as perhaps the most significant evolutionary step in transport protocols over the entire decade.

The Application Layer

Let's keep on moving up the protocol stack and look at the Internet from the perspective of the applications and services that operate across the network.

Privacy and Encryption

As we noted in looking at developments in end-to-end transport protocols, encryption of the QUIC payload is not just to keep network middleware from meddling with the TCP control state, although it does achieve that very successfully. The encryption applies to the entire payload, and it points to another major development in the past decade. We are now wary of the extent to which various forms of network-based mechanisms are used to eavesdrop on users and services. The documents released by Edward Snowden in 2013 portrayed a very active US Government surveillance program that used widespread traffic interception sources to construct profiles of user behavior and by inference profiles of individual users. In many ways, this effort to assemble such profiles is not much different to what advertising-funded services such as Google and Facebook have been (more or less) openly doing for years, but perhaps the essential difference is that of knowledge and implied consent. In the advertisers' case, this information is intended to increase the profile accuracy and hence increase the value of the user to the potential advertiser. The motivations of government agencies are more open to various forms of interpretation, and not all such interpretations are benign.

One technical response to the implications of this leaked material has been an overt push to embrace end-to-end encryption in all parts of the network. The corollary has been an effort to allow robust encryption to be generally accessible to all, and not just a luxury feature available only to those who can afford to pay a premium. The Let's Encrypt initiative has been incredibly successful in publishing X.509 domain name certificates that free of cost, and the result is that all network service operators, irrespective of their size or relative wealth, can afford to use encrypted sessions, in the form of TLS, for their web servers.

The push to hide user traffic from the network and network-based eavesdroppers extends far beyond QUIC and TLS session protocols. The Domain Name System is also a rich source of information about what users are doing, as well as being used in many places to enforce content restrictions. There have been recent moves to try and clean up the overly chatty nature of the DNS, using query name minimization to prevent unnecessary data leaks, and the development of both DNS over TLS and DNS over HTTPS to secure the network path between a stub resolver and its recursive server. This is very much a work in progress effort at present, and it will take some time to see if the results of this work will be widely adopted in the DNS environment.

We are now operating our applications in an environment of heightened paranoia. Applications do not necessarily trust the platform on which they are running, and we are seeing efforts from the applications to hide their activity from the underlying platform. Applications do not trust the network, and we are seeing increased use of end-to-end encryption to hide their activity from network eavesdroppers. The use of identity credentials within the encrypted session establishment also acts to limit the vulnerability of application clients to be misdirected to masquerading servers.

The Rise and Rise of Content

Moving further up the protocol stack to the environment of content and applications we have also seen some revolutionary changes over the past decade.

For a small period of time, the Internet's content and carriage activities existed in largely separate business domains, tied by mutual interdependence. The task of carriage was to carry users to content, which implied that carriage was essential to content. But at the same time, a client/server Internet bereft of servers is useless, so content is essential to carriage. In a world of re-emerging corporate behemoths, such mutual interdependence is unsettling, both to the actors directly involved and to the larger public interest.

The content industry is largely the more lucrative of these two and enjoys far less in the way of regulatory constraint. There is no concept of any universal service obligation or even any effective form of price control in the services they offer. Many content service providers use internal cross funding that allows them to offer free services to the public, as in free email, free content hosting, free storage, and similar, and fund these services through a second, more occluded, transaction that essentially sells the user's consumer profile to the highest bidding advertiser. All this happens outside of any significant regulatory constraint which has given the content services industry both considerable wealth and considerable commercial latitude.

It should be no surprise that this industry is now using its capability and capital to eliminate its former dependence on the carriage sector. We are now seeing the rapid rise of the content data network (CDN) model, where instead of an Internet carrying the user to a diverse set of content stores, the content stores are opening local content outlets right next to the user. As all forms of digital services move into CDN hostels, and as the CDN opens outlets that are positioned immediately adjacent to pools of economically valuable consumers, then where does that leave the traditional carriage role in the Internet? The outlook for the public carriage providers is not looking all that rosy given this increasing marginalization of carriage in the larger content economy.

Within these CDNs, we've also seen the rise of a new service model enter the Internet in the form of cloud services. Our computers are no longer self-contained systems with processing and compute resources but look more and more like a window that sees the data stored on a common server. Cloud services are very similar, where the local device is effectively a local cache of a larger backing store. In a world where users may have multiple devices, this model makes persuasive sense, as the view to the common backing store is constant irrespective of which device is being used to access the data. These cloud services also make data sharing and collaborative work far easier to support. Rather than creating a set of copies of the original document and then attempt to stitch back all the individual edits into a single common whole, the cloud model shares a document by simply altering the document's access permissions. There is only ever one copy of the document, and all edits and comments on the document are available to all.

The Evolution of Cyber Attacks

At the same time as we have seen announcements of ever-increasing network capacity within the Internet, we've seen a parallel set of announcements that note new records in the aggregate capacity of Denial of Service attacks. The current peak volume is an attack of some 1.7Tbps of malicious traffic.

Attacks are now commonplace. Many of them are brutally simple, relying on a tragically large pool of potential zombie devices that are readily subverted and co-opted to assist in attacks. The attacks are often simple forms of attack, such as UDP reflection attacks where a simple UDP query generates a large response. The source address of the query is forged to be the address of the intended attack victim, and not much more need be done. A small query stream can result in a massive attack. UDP protocols such as SNMP, NTP, the DNS and memcache have been used in the past and doubtless will be used again.

Why can't we fix this? We've been trying for decades, and we just can't seem to get ahead of the attacks. Advice to network operators to prevent the leakage of packets with forged source addresses, RFC 2827, was published in two decades ago in 1998. Yet massive UDP-based attacks with forged source addresses persist all the way through today. Aged computer systems with known vulnerabilities continued to be connected to the Internet and are readily transformed into attack bots.

The picture of attacks is also becoming more ominous. Previously attributed to 'hackers' it was quickly realized that a significant component of these hostile attacks had criminal motivations. The progression from criminal actors to state-based actors is also entirely predictable, and we are seeing an escalation of this cyber warfare arena with the investment in various forms of exploitation of vulnerabilities being seen as part of a set of desirable national capabilities.

It appears that a major problem here is that collectively we are unwilling to make any substantial investment in effective defense or deterrence. The systems that we use on the Internet are overly trusting to the point of irrational credulity. For example, the public key certification system used to secure web-based transactions is repeatedly demonstrated to be untrustworthy, yet that's all we trust. Personal data is continually breached and leaked, yet all we seem to want to do is increase the number and complexity of regulations rather than actually use better tools that would effectively protect users.

The larger picture of hostile attack is not getting any better. Indeed, it's getting very much worse. If any enterprise has a business need to maintain a service that is always available for use, then any form of in-house provisioning is just not enough to be able to withstand attack. These days only a handful of platforms are able to offer resilient services, and even then it's unclear whether they could withstand the most extreme of attacks. There is a constant background level of scanning and probing going on in the network, and any form of visible vulnerability is ruthlessly exploited. One could describe today's Internet as a toxic wasteland, punctuated with the occasional heavily defended citadel. Those who can afford to locate their services within these citadels enjoy some level of respite from this constant profile of hostile attack, while all others are forced to try and conceal themselves from the worst of this toxic environment, while at the same time aware that they will be completely overwhelmed by any large-scale attack.

It's a sobering thought that about one half of the world's population are now part of this digital environment. A more sobering thought is that many of today's control systems, such as power generation and distribution, water distribution, and road traffic control systems are exposed to the Internet. Perhaps even more of a worry is the increasing use of the Internet in automated systems that include various life support functions. The consequences of massive failure of these systems in the face of a sustained and damaging attack cannot be easily imagined.

The Internet of Billions of Tragically Stupid Things

What makes this scenario even more depressing is the portent of the so-called Internet of Things.

In those circles where Internet prognostications abound and policymakers flock to hear grand visions of the future, we often hear about the boundless future represented by this "Internet of Things. This phrase encompasses some decades of the computing industry's transition from computers as esoteric pieces of engineering affordable only by nations, to mainframes, desktops, laptops, handhelds, and now wrist computers. Where next? In the vision of the Internet of Things, we are going to expand the Internet beyond people and press on with using billions of these chattering devices in every aspect of our world.

What do we know about the "things" that are already connected to the Internet?

Some of them are not very good. In fact, some of them are just plain stupid. And this stupidity is toxic, in that their sometimes inadequate models of operation and security affect others in potentially malicious ways. Doubtless, if such devices were constantly inspected and managed we might see evidence of aberrant behavior and correct it. But these are unmanaged devices that are all but invisible. There is the controller for a web camera, the so-called "smart" thin in a smart television, or what controls anything from a washing machine to a goods locomotive. Nobody is looking after these devices.

When we think of an Internet of Things we think of a world of weather stations, webcams, "smart" cars, personal fitness monitors and similar. But what we tend to forget is that all of these devices are built upon layers of other people's software that is assembled into a product at the cheapest possible price point. It may be disconcerting to realize that the web camera you just installed has a security model that can be summarised with the phrase: "no security at all", and its actually offering a view of your house to the entire Internet. It may be slightly more disconcerting to realise that your electronic wallet is on a device that is using a massive compilation of open source software of largely unknown origin, with a security model that is not completely understood, but appears to be susceptible to be coerced into being a "yes, take all you want".

It would be nice to think that we've stopped making mistakes in code, and from now on our software in our things will be perfect. But that's hopelessly idealistic. It's just not going to happen. Software will not be perfect. It will continue to have vulnerabilities. It would be nice to think that this Internet of Things is shaping up as a market where quality matters and consumers will select a more expensive product even though its functional behavior is identical to a cheaper product that has not been robustly tested for basic security flaws. But that too is hopelessly naive.

The Internet of Things will continue to be a marketplace where the compromises between price and quality will continue to push us on to the side of cheap rather than secure. What's going to stop us from further polluting our environment with a huge and diverse collection of programmed unmanaged devices with inbuilt vulnerabilities that will be all too readily exploited? What can we do to make this world of these stupid cheap toxic things less stupid and less toxic? Workable answers to this question have not been found so far.

The Next Ten Years

The silicon industry is not going to shut down anytime soon. It will continue to produce chips with more gates, finer tracks and more stacked layers for some years to come. Our computers will become more capable in terms of the rage and complexity of the tasks that they will be able to undertake.

At the same time, we can expect more from our network. Higher capacity certainly, but also greater levels of customization of the network to our individual needs.

However, I find it extremely challenging to be optimistic about security and trust in the Internet. We have made little progress in this areas over the last ten years and there is little reason to think that the picture will change in the next ten years. If we can't fix it, then, sad as it sounds, perhaps we simply need to come to terms with an Internet jammed full of tragically stupid things.

However, beyond these broad-brush scenarios, it's hard to predict where the Internet will head. Technology does not follow a pre-determined path. It's driven by the vagaries of an enthusiastic consumer marketplace that is readily distracted by colorful bright shiny new objects and easily bored by what we quickly regard as commonplace.

What can we expect from the Internet in the next ten years that can outdo a pocket-sized computer that can converse with me in a natural language? That can offer more than immersive 3D video in outstanding quality? That can bring the entire corpus of humanity's written work into a searchable database that can answer any of our questions in mere fractions of a second?

Personally, I have no clue what to expect from the Internet. But whatever does manage to capture our collective attention I am pretty confident that it will be colorful, bright, shiny, and entirely unexpected!

Written by Geoff Huston, Author & Chief Scientist at APNIC

Follow CircleID on Twitter

More under: Access Providers, Broadband, Cybersecurity, DNS, DNS Security, Internet Protocol, IP Addressing, IPv6, Mobile Internet, Networks

It's About Whois Display And Access

2018-06-24T16:37:00-08:00

The need for an access model for non-public Whois data has been apparent since GDPR became a major issue before the community well over a year ago. Now is the time to address it seriously, and not with half measures. We urgently need a temporary model for access to non-public Whois data for legitimate uses, while the community undertakes longer-term policy development efforts.

The pronounced need isn't news to ICANN. The Governmental Advisory Committee (GAC), law enforcement, security experts, IP interests and a host of others sounded the alarm some time ago. And ICANN's CEO even acknowledged it, while stopping short of addressing it. Most recently, the Security and Stability Advisory Committee issued a strongly worded advisory underlining the security and stability harms now accruing thanks to a dark Whois. Alas, we find that the system already is fragmented.

"It's not that bad," some will say. "The parade of horribles hasn't arrived." That would be misdirected thinking. Requests for non-public data may be lower than anticipated because the temporary Whois model approved by ICANN's Board raised more questions that it answered, left avenues for access unclear and fragmented, and left out measures to hold registrars and registries accountable for providing access to non-public Whois for GDRP-allowed uses. Even so, early feedback on requests for non-public WHOIS indicates that many registrars are non-responsive. It's like we're back to the wild west.

It's a good thing that ICANN has now joined the community in acknowledging critical access needs by publishing a "Framework Elements for Unified Access Model for Continued Access to Full WHOIS Data — For Discussion," but it's only a half step. Rather than stick its toe in the access water with this model for a model (for discussion, not for action), ICANN should jump in and commit to solving this problem immediately, rather than focus on a few high-level themes with a suggestion that we all gather to talk about it.

Unfortunately for the victims of e-crime, abuse and infringement, and for the world's Internet users, this "model" is nowhere close to implementable. For example, it tries to impose a substantial amount of work and responsibility on governments and the GAC, which has already told ICANN that it will provide advice within a limited purview and is not responsible for administrative or operational activities. And it's not exactly timely. By its own specification and timetable, the model can't move ahead until at least mid-December 2018. Meanwhile, the harms continue to pile up.

So what we appear to have here is a rapidly deteriorating domain name system, with a vague model to address it that relies on bodies that don't want to run it, and the plan is to talk it over for something like the next six months.

There's a better option.

Over-applying GDPR requirements, the ICANN Board issued a Temporary Specification (Temp Spec) to deal with Whois display. Similarly, applying GDPR requirements for legitimate use should now drive ICANN's Board to take similar steps to put in place a stop-gap measure that immediately provides uniformity and predictability for access to non-public Whois. Just as ICANN sprang into action on the matter of displaying Whois, it's now in a position to do the same for access to Whois.

This isn't to suggest that ICANN shouldn't discuss and further develop with the community its newly released Unified Access Model. But, there's a problem to solve now and solutions have already been offered that should not be ignored. I'm referring to the community access model — now at 47 pages with great detail that answers many of the very questions ICANN asks in its Unified Access Model. Highlighted in this model are technical solutions that will probably be part of the community discussion around the Unified Access Model, and should most certainly be considered as a stop-gap solution to the current need for access to nonpublic Whois.

With available and implementable solutions today, ICANN should be driven by public interest rather than total risk aversion. It's time to move quickly to provide an immediate temporary solution to access while the community works on the Unified Access Model and EPDP.

Written by Fabricio Vayra, Partner at Perkins Coie LLP

Follow CircleID on Twitter

More under: Domain Names, ICANN, Internet Governance, Policy & Regulation, Privacy, Whois

Live On Monday, 25 June - DNSSEC Workshop at ICANN 62 in Panama

2018-06-24T16:17:00-08:00

With the DNSSEC Root Key Rollover coming up on October 11, how prepared are we as an industry? What kind of data can we collect in preparation? What is the cost-benefit (or not) of implementing DANE? What can we learn from an existing rollover of a cryptographic algorithm?

All those questions and more will be discussed at the DNSSEC Workshop at the ICANN 62 meeting in Panama City, Panama, on Monday, June 25, 2018. The session will begin at 9:00 and conclude at 12:15 EST (UTC-5). [Note: this is one hour different than current US Eastern Daylight Time - Panama does not change to daylight savings time - and so this will begin at 10:00 EDT (UTC-4).]

The agenda includes:

DNSSEC Workshop Introduction, Program, Deployment Around the World – Counts, Counts, Counts
Panel: DNSSEC Activities and Post Key Signing Key Rollover Preparation
DANE: Status, Cost Benefits, Impact from KSK Rollover
An Algorithm Rollover (case study from CZ.NIC)
Panel: KSK Rollover Data Collection and Analysis
DNSSEC – How Can I Help?
The Great DNSSEC/DNS Quiz

It should be an outstanding session! For those onsite, the workshop will be in Salon 4, the ccNSO room.

WATCH LIVE: https://participate.icann.org/pty62-salon4
More info and slides are available from these URLs (ICANN's online schedule system breaks it up into sections based on breaks and lunch):
• 9:00-10:15 (https://62.schedule.icann.org/meetings/699560)
• 10:30-12:15 (https://62.schedule.icann.org/meetings/699556)

Lunch will follow. Thank you to our lunch sponsors: Afilias, CIRA, and SIDN.

* * *

The DNSSEC Workshop will be followed by the "Tech Day" set of presentations from 13:30 – 18:30 EST. Many of those may also be of interest. They will also be streamed live at the same URL.

As this is ICANN's smaller "Policy Forum" schedule, there will not be either the "DNSSEC for Everybody” session nor the "DNSSEC Implementer's Gathering” as there is at the other two ICANN meetings each year. Also, as I am not able to travel to ICANN 62, I want to thank Jacques Latour for stepping in to help with the usual presenting and emceeing that I do.

Please do join us for a great set of sessions about how we can work together to make the DNS more secure and trusted!

Written by Dan York, Author and Speaker on Internet technologies - and on staff of Internet Society

Follow CircleID on Twitter

More under: DNS, DNS Security, ICANN

Access to Safe and Affordable Prescription Medications Online is a Human Right

2018-06-22T07:19:00-08:00

I recently served on a panel at the Toronto RightsCon 2018 conference (Making Safe Online Access to Affordable Medication Real: Addressing the UN Human Rights resolution for access to essential medicines), where I represented the perspective of Americans struggling to afford their daily medications and desperate to have safe, affordable Internet access to their prescriptions.

These Americans may not understand the inner workings of the Internet, but they do understand its mission of providing global access to information, products, and services. They know there are "bad actors" out there, as there are in any segment of our society. They also know how to find the legitimate pharmacies, and get the medications they need, at prices they can pay.

We can usually find fair prices for the things we need in a marketplace close to home, but prescription drugs in the U.S. are not fairly priced. The global marketplace available through the Internet can provide patients with fair prices for life-saving prescription medications.

However, there are people who use "rogue pharmacies" to scare patients, while at the same time maintaining the exorbitantly high cost of prescription medications. This is an ongoing, serious health crisis for many Americans who are desperate for relief and want the government to act.

The cost of prescription medications is higher in the U.S. than any other country in the world because there are no restrictions or limitations on how much companies can charge, so these "big pharma" global giants charge 'whatever the market will bear.'

These companies can increase the price of medications for any reason… or no reason whatsoever. Many people are then forced to choose between their medications and gas, food, or even their mortgage. Or, they skip doses, split pills, or forgo medications completely.

In fact, an estimated 35 million Americans fail to adhere to their prescribed drug regimens due to cost, according to a Commonwealth Fund study.[1] In another study by the Harvard School of Public Health and Kaiser Health Foundation, 50 percent of Americans said they couldn't afford medication and became sicker as a result of not taking medicine.[2]

Once again at RightsCon, it was well-noted that for years, millions of Americans facing this crisis have purchased their prescriptions from licensed, legitimate Canadian pharmacies that provide a lifeline to those in need of affordable and often life-saving daily medications. But once again, more misleading information along with impractical registration criteria seek to erode patients' trust in licensed, legitimate online pharmacies that have chosen not to register or are blocked from using a .Pharmacy domain name.

Clearly, only licensed, legitimate online pharmacies should be able to sell prescription medications upon receipt of a valid prescription and with adherence to proper safety protocols. However, neither the location of the licensed pharmacy, the domain it uses, nor the location of the patient should impact affordability or access.

After all, the Internet was created to expand freedoms, protect human rights and build a global community. Internet protocols and policies must reflect the realities of how people use the Internet today because the Internet is, in some cases, the only access patients have to affordable maintenance medications.

We believe the Internet community can and should protect access through policymaking that embraces safe, legitimate pharmacy websites regardless of their location and domain name. To do otherwise is to allow the Internet to be used as a tool for censorship.

As an advocacy organization that fights for everyday Americans, we believe that access to safe and affordable prescription medications should not be a privilege reserved for the wealthy among us. Instead, we believe it is a human right and, therefore, must be protected through cyber policymaking, effective Internet governance, and updated amendments to outmoded laws so that such policies truly meet the needs of patients.

This is a critical time for protecting our human rights at its intersection with digital technology. As a global Internet community, we must stand up to those who are using the Internet to restrict options that support and protect fair access to medicines.

All Americans deserve access to safe and affordable medications.

[1] Commonwealth Fund: http://www.commonwealthfund.org/~/media/files/publications/issue-brief/2015/jan/1800_collins_biennial_survey_brief.pdf

[2] Harvard School of Public Health and Kaiser Health Foundation: https://kaiserfamilyfoundation.files.wordpress.com/2013/01/7371.pdf

Written by Tracy Cooley, Executive Director, Campaign for Personal Prescription Importation

Follow CircleID on Twitter

More under: Domain Names, Internet Governance, Web

Domain Registrars Fined Over $2M for Scamming Australians

2018-06-21T09:31:00-08:00

The Federal Court has penalized two related companies, Domain Corp Pty Ltd and Domain Name Agency Pty Ltd, for tricking Australians out of a total of $2.3 million. Dan Pearce reporting in Lexology writes: "During a period spanning from November 2015 to April 2017, the Australian Competition and Consumer Commission (ACCC) had received a multitude of complaints against the two Domain Companies. During this period, over 300,000 unsolicited notices were sent to businesses requesting renewal of domain names. However, while these notices appeared to be renewal notices for existing domain names, they were actually notices for the registration of new domain names. This resulted in many businesses unwittingly signing up for a new domain name ending in a '.net.au' or a '.com' suffix that the business may not have needed or wanted."

Follow CircleID on Twitter

More under: Domain Names, Law

ACLU Released Guide for Developers on How to Respond to Government Demands That Compromise Security

2018-06-21T09:13:00-08:00

It is not uncommon for government agents to force technology companies to create or install malicious software in products in order to help them with surveillance. The American Civil Liberties Union (ACLU) has released a guide for developers that is intended to help preserve security and customers' privacy. ACLU says: "The likelihood that government actors may attempt to force software makers to push out software updates that include malware designed to obtain data from targeted devices grows as more companies secure their users' data with encryption. And, as companies close other technological loopholes, there will be increased pressure on law enforcement to find alternate vulnerabilities to exploit. ... You have the right to say no to requests that are not backed up by a court order. But by obtaining a court order demanding technical assistance, the government might try to compel you to install malware on a user's machine as a software update that appears to be entirely ordinary, and that comes directly from you. You have a right to challenge these orders in court."

Follow CircleID on Twitter

More under: Cybersecurity, Law, Privacy

Why You Must Learn to Love DNSSEC

2018-06-19T19:28:00-08:00

It's been nearly two months since the high profile BGP hijack attack against MyEtherwallet, where crypto thieves used BGP leaks to hijack MEW's name servers, which were on Amazon's Route53, and inserted their own fake name servers which directed victims to their own fake wallet site, thereby draining some people's wallets.

It generated a lot of discussion at the time, however, it's largely died down now, and people are content to carry on with their lives. What isn't fully appreciated is that attack has, in fact, changed the game somewhat, and this means we all have to reevaluate our assessment of DNSSEC.

Why does DNSSEC factor into a hack that was executed via BGP hijacks? Well here's the bad news, while it's debatable how easy it is to execute BGP hijacks, there is no defined security protocol in place to prevent it. Really. Last year easyDNS had some of our own IP space hijacked and it took us about a week to get it straightened out. Thank God it was unused space, but the entire episode had me realize how loose the authentication of routing announcements really is. There's some talk around implementing RPKI but it's a long way off, if ever.

That leaves us with DNSSEC as our main line of defence against these attacks, of which there are certainly bound to be more.

Had MyEtherwallet DNSSEC signed its zone, and further, used TLSA pinning for their TLS certs, this attack would have been largely mitigated. Two of the resolver services which picked up the fake IP addresses for MEW were Google Public DNS and Cloudflare's 1.1.1.1, both DNSSEC aware resolvers which would have instead returned failures instead of fake addresses.

Until now though,

DNSSEC hasn't really caught on for two reasons:

First, historically speaking, old style DNS poisoning attacks (not using BGP leaks) were theoretically possible but not commonplace. Even without DNSSEC name servers started adding mechanisms like source port randomization and it made it increasingly harder to pull off cache poisoning.

Second, DNSSEC wasn't easy to implement, and it wasn't exactly "set-and-forget". Worse, if you did it wrong like screwed up one of your key rollovers, you would hose your own zone. There is even a website that keeps track of high profile outages stemming from botched DNSSEC rollovers. It includes numerous entire TLD namespaces, the US military and even ISC, opendnssec.org and dnssec-tools.org, organizations that are chief advocates behind DNSSEC. Talk about the cobbler's children have no shoes!

It's no surprise then that businesses were reluctant to DNSSEC sign their zones because when they did the calculus, they thought they were more likely to experience a self-inflicted outage via DNSSEC misconfiguration than from having an attacker successfully poison or spoof their zone.

Aside from the difficulty in implementing and maintaining DNSSEC, there are also ideological objections. Those include the ideas that DNSSEC is simply flawed, insecure or doesn't solve anything because of the centralized nature of DNS' inverted-tree hierarchy.

A standard bearer for anti-DNSSEC deployment is posting called Against DNSSEC. It raises numerous objections to DNSSEC, some more tenable than others. Not long after, one of our developers, Zach Lym posted a response to it entitled For DNSSEC which rebutted the earlier post point-for-point. Both posts were at some point added to the Wikipedia DNSSEC citations section as embodying the opposite views to the issue.

In my mind the anti-DNSSEC article didn't age well, considered with this addendum to that post's mini-FAQ:

"What's the alternative to DNSSEC?

Do nothing. The DNS does not urgently need to be secured.

All effective security on the Internet assumes that DNS lookups are unsafe. If this bothers people from a design perspective, they should consider all the other protocol interactions in TCP/IP that aren't secure: BGP4 advertisements, IP source addresses, ARP lookups. Clearly, there is some point in the TCP/IP stack where we must draw a line and say "security and privacy are built above this layer". The argument against DNSSEC simply says the line should be drawn somewhere higher than the DNS."

This is bad advice. Because BGP leaks are now a thing (Cloudflare's 1.1.1.1 was briefly BGP hijacked the morning I typed this), doing nothing is no longer an option. Since RPKI isn't widespread now and the routing experts I talked to say it may never be able to scale. Since it is a certainty that more high profile, damaging and lucrative BGP hijacks are certain to follow, at this moment DNSSEC is the only game in town to defend against this kind of an attack.

Those who are operating their own ASNs can certainly use something like BGPmon or Artemis, and it's better to have route monitoring enabled than not, but that's still a matter of how fast your peers can slam the barn door shut after the horse is away. You want all of your key assets to not resolve to fake values, even for a moment, because there are ways attackers can use that brief window of time to promulgate fake DNS values that will last much much longer than the duration of the attack itself, days, weeks — a year.

Another criticism of DNSSEC is that because it relies on DNS, which is itself an inverted tree with a logically centralized root node, it is a "government or state" security system. Well, sure, in the sense that there exists an internet root and it is overseen by an entity at the discretion of a nation state, that much is true. But as much as I'm into decentralization, zero-knowledge systems, and even ideologically identify as an anarcho-capitalist, there is the practical reality that there is no clear path from where we are now to a fully decentralized anarcho utopia. Even if there is, it'll be a multi-generational slog to get there.

Eschewing the one defence we have against an attack variant that poses an existential threat to anybody whose livelihood depends on being visible over the Internet today is pretty much tilting at windmills. Even the Ethereum Name Service WG which has been working on deploying ENS enabled domains, both under the Ethereum native .ETH TLD and in legacy DNS integrations like .XYZ went with DNSSEC to authenticate the validity of the ENS integration process.

So what do you do about it?

Easy. You go ahead and sign your zones for DNSSEC. We were already working on a ground-up rewrite of our DNSSEC implementation when this happened (truth be told, I coded the first one and it kinda sucked. It didn't do anything with your DS records and was pretty shaky with key rollovers. Memo to staff: Don't let the CEO code anymore.)

When the MEW / Amazon Route53 BGP hijack happened, we went to the mattresses accelerating our rewrite, it was like early days. Sleeping at the office, pizza and coffee at 4am, the works. What we have now, well it's something else.

Now we have easyDNSSEC™ the world's first Set-and-Forget DNSSEC™ deployment which fully eliminates the implementation hurdles I outlined above. No more worrying about botched key rollovers or remembering to re-sign the zone after an update, let alone how the hell do you get your DS records into your parent TLD? Just press the button and you're done. End-to-end DNSSEC in about 1 second.

As always, we've pushed the new system live as beta, so start with your non-essential zones. When you enable DNSSEC for your zones you'll notice your name servers will switch from easydns.* to easydnssec.* hostnames, this is because we've also signed those name server hostnames ahead of when we pull the trigger and sign easydns.com for real, which will happen soon.

Other enhanced security measures

Once you've decided to take the plunge and DNSSEC sign your zones, there are even more safeguards you can implement to further protect yourself. Some of these measures should have been implemented already anyway, like CAA. Some are not for the novice, and they are similar to the early days of DNSSEC implementations: if you miscalculate or lose track things, you can hose your zone. Still, others won't work until you sign your zone with DNSSEC (DANE), but if you combine DNSSEC signed zones with the tactics below, you will be fairly well secured against attack vectors which can be launched via BGP leaks:

Implement CAA records to assert what CA authorities can issue TLS certs for your domain. You should have these in place anyway, since the CA/Browser forum made Certificate Authority Authorization mandatory for all CA's in 2017.
Enable HTTP Public Key Pinning (HPKP) to guard against a future compromise of your CA. This one is non-trivial and you could potentially "brick" your website if you lose track of your keys. (HPKP is implemented via HTTP server headers, not in your DNS zone.)
Publishing TLSA records for your hostnames that are secured via TLS. TLSA records enable, DANE which can be used to issue TLS certificates on your hosts and validate them without using a central CA. Doing so is not yet widely supported in browsers, but here we can also use TLSA to assert what CA's can issue certificates on our domain and what the validation path should be.

Whether you employ any of the additional tactics above, once you DNSSEC sign your zone, if your upstream DNS provider or the IP space for your website (or any other part of your network) gets hijacked, your DNSSEC validation will break, and those using DNSSEC enabled resolvers will not see any fake sites. An outage is preferable to a spoof at this point.

Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.

Written by Mark Jeftovic, Co-Founder, easyDNS Technlogies Inc.

Follow CircleID on Twitter

More under: Cyberattack, Cybersecurity, DNS, DNS Security

Heading Into Panama for ICANN62

2018-06-19T10:52:00-08:00

Well amazingly, it's that time again. Next week, individuals from around the world with a keen interest in Internet policy will head to Panama City, Panama for the second ICANN meeting of the year. As always, Brandsight will be attending to follow all of the important policy work being carried out by the community.

Before I head off to the meeting (which based on my research will actually be my 32nd ICANN meeting!), I'd like to share a preview of the major topics slated for discussion.

We will be about a month into the GDRP enforcement era and this topic will surely dominate the conversations during the week. The temporary specification ICANN issued to address WHOIS in a GDPR-compliant world has already resulted in legal action in Germany with ICANN seeking clarity from a court regarding the requirements in the temporary specification.

The temporary specification is still new and has many questions surrounding its interpretation and enforcement, so the community will have an opportunity to get some additional clarity on those outstanding questions.

Discussion around the actual policy work to address a long-term solution to WHOIS will undoubtedly be a hotly debated topic. Since the temporary specification can only be in place for a year, the policy-making body within ICANN (the GNSO) will need to develop a bottom-up policy to effectively take its place at that time, if not before. Generally, policy work at ICANN takes several years, so to complete the policy initiative around such a contentious issue as WHOIS in a year will be challenging for sure.

In addition to issues regarding collection of WHOIS data and the development of new WHIOS policy, access to non-public WHOIS data is still unresolved. The temporary specification calls for contracted parties to provide "reasonable access" to non-public, personal information, but that is obviously open to all kinds of interpretation by different parties. We are already hearing reports of issues when access to that data has been requested.

In a late-breaking development, ICANN has just published a framework for what they call "Unified Access Model for continued access to full WHOIS." This draft document was put out by ICANN to serve as a guide for community discussion around how third-parties will access non-public WHOIS data. Undoubtedly, this recently released proposal will be a major topic of conversation during the week in Panama City.

Of course, GDPR won't be the only topic of discussion. The policy work regarding the next round of new gTLDs will also be on the agenda. The subsequent procedures group is scheduled to release their preliminary report around the time of the meeting and that will certainly be something in which folks are interested. In addition, the group looking at the Rights Protection Mechanisms will also be meeting and discussing a survey recently sent to Uniform Rapid Suspension practitioners.

As is the case with every ICANN meeting, the Governmental Advisory Committee will be meeting and working on their traditional communiqué which will be released at the end of the meeting. This is always something to watch closely due to the weight their advice carries with the ICANN board.

With so much happening in the domain name system, it's sure to be a very active meeting. I'm looking forward to seeing those who are attending and sharing the highlights of the meeting during Brandsight's traditional post-ICANN webinar on July 11th.

Written by Matt Serlin, SVP, Client Services and Operations at Brandsight

Follow CircleID on Twitter

More under: Domain Names, ICANN, Internet Governance, Policy & Regulation, Privacy, Whois

Opting for UDRP Over URS

2018-06-19T08:49:00-08:00

The Internet Corporation for Assigned Names and Numbers (ICANN) implemented the Uniform Rapid Suspension System (URS) in 2013 together with three other rights protection mechanisms for trademarks. It "is not intended for use in any proceedings with open questions of fact, but only clear cases of trademark abuse" (URS Procedure 8.5). It was designed to afford rights holders claiming abusive registration of domain names with new gTLD extensions an even faster route to remedy than the Uniform Domain Name Dispute Resolution Policy (UDRP). From complaint to award, fourteen rather the thirty to forty days for the UDRP. (Examiners are expected to decide the complaint within 5 days of the filing of the response, URS Procedure 9.6).

Unlike the UDRP, rights holders for the URS qualify only if they have registered trademarks with proof of use in commerce and they have to be "word marks." Those claiming unregistered marks have no standing to maintain a URS proceeding. Despite these several differences, the URS is similar to the UDRP in both the language of its three-prong structure and its evidentiary demand for proving conjunctive bad faith. It is dissimilar 1) in requiring proof of cybersquatting by clear and convincing rather than preponderance of the evidence; and 2) providing a single remedy of suspension for the duration of the registration as opposed to cancellation or transfer of domain registration to rights holders. (Rights holders have the option to continue the suspension for an additional year at prevailing rates, Procedure 10.3).

How does one measure success of a rights protection mechanism? If by numbers, it has to be admitted the URS has not been enthusiastically embraced; at least, as measured by the number of rights holders who could have qualified for the URS but instead have opted for the UDRP. From 2013 to date rights holders filed less than 1,000 URS complaints, somewhere in the region of 220 per annum overwhelmingly with the Forum; 46 withdrawn before decision but a 93% or greater percentage success rate for rights holders suspending infringing domain names.

On a rough count, judging from the first six months of 2018 the number of rights holders commencing proceedings under the UDRP involving domain name with new gTLDs will be twice or more the number of complaints filed under the URS for the same period of time. Through the first week of June 2018, roughly 260 new gTLD complaints have been filed under UDRP against 90 for URS. If that number continues there will be over 500 UDRP complaints for new gTLD infringements by the end of 2018 (WIPO and Forum) and 200 or less for the URS process (that is, filed with the Forum. Complaints filed with the other two URS providers can be counted on one hand).

Of new gTLDs adjudicated by URS (Forum) Examiners, respondents prevailed in less than 7% of the claims (61 denials against 758 suspensions), which should give cheer to rights holders. This is for the entire four-plus years of its existence. Rights holders claiming cybersquatting with new gTLDs under the UDRP rarely fail of success, although it is instructive when they do.

Can it be assumed otherwise than rights holders prefer the UDRP process? Is it because of the remedy or the burden of proof? Or, for some other reason? Under the UDRP, rights holders have uniformly chosen transfer over cancellation. It must be that the principal inhibitory reason for opting for the UDRP is either or both the standard of proof or the sole remedy of suspension. Suspended domain names return to the pool of general availability once the registration expires, thereby risking a repeat of cybersquatting by the same respondent or someone else (which has happened).

One of these rarities of respondent prevailing in both the URS and UDRP, from last year but emblematic, involved the BLOOMBERG mark. As a general observation, respondents prevail in the URS and UDRP when rights holders fail to submit sufficient evidence of bad faith. In Bloomberg Finance L.P. v. zhang guo jie, FA1703001721683 (Forum March 31, 2017) (<Bloomberg.site> the URS Examiner explained that the "Complaint is . . . devoid of any allegations or proof of facts tending to show, even prima facie, either that Respondent has no right to or legitimate interest in the <bloomberg.site> domain name, or that the domain name was registered and is being used by Respondent in bad faith."). In the subsequent UDRP proceeding [FA1704001727926 (Forum June 8, 2017)], the Panel held "even taking account of the public use which has been made of the trademark, it is a common family name which might remain open to use in good faith by any number of traders… This is not a case of an invented word with no connotation other than the goods or services of a single trader."

One explanation for rights holders preferring the UDRP is that, overall, it is easier and less risky where the URS result is not quite as predictable as one would wish, even assuming suspension is the proper remedy. For example, in Commonwealth Bank of Australia v. WhoisGuard Protected, WhoisGuard, Inc. / Lord Oxford, D2018-0769 (WIPO May 29, 2018) (<bankwest.site> and bankwest.website>) it is likely (based on the Respondent's emails denying bad faith) that a URS Examiner would have denied the complaint for <bankwest.site> even if it granted suspension for the dot website domain name. The Respondent stated in informal emails that "the disputed domain names are spoonerisms, and that the planned use of the disputed domain names is in respect of a website about Israel's West Bank dispute." The UDRP Panel rejected Respondent's assertions:

The Panel further finds the Respondent's assertion that the planned use of the disputed domain names is in respect of a website concerning Israel's West Bank dispute, an assertion wholly unsupported by any evidence, incredible. The Panel is also, incidentally, unable to discern how the disputed domain names are said to be spoonerisms.

It should also be obvious that many new gTLDs have particular relevance to specific businesses. So, for example, . tech, .shop, .support, .deals, .design, and .tours as extensions to domain names identical to marks in industries or businesses for which they would be appropriate are (absent explanations for using names corresponding to marks) clearly infringing, but if the combination of domain name and gTLD is also recognized as a valuable addition to a Complainant's portfolio of domain names the strategic remedy of choice would certainly be transfer rather than suspension.

Thus, in STS Student Travel Schools AB v. Nordmann Nordmann, D2018-0736 (WIPO May 18, 2018) (<sts.tours>) and Compagnie Générale des Etablissements Michelin v. WhoisGuard, Inc., WhoisGuard Protected / Saad Zaeem, Caramel Tech Studios, D2017-0234 (WIPO April 3, 2018) (<michelin.design> it makes sense to opt for a UDRP remedy.

In STS Student Travel Schools, the Panel found it was "likely that the Respondent had knowledge of both the Complainant and the Trade Mark at the time he registered the Disputed Domain Name. This conclusion is reinforced by the content of the website at the Disputed Domain Name, being PPC links relating to schools and education." In Compagnie Générale des Etablissements Michelin, it is possible (and this may have been counsel's concern) that the extension .design which is not logically associated with Complainant's business could have failed in a URS proceeding. Complainant could also have had a strategic reason, namely that it saw a benefit to having the .design and the UDRP was the only route for getting it. In fact, although Respondent did not formally appear it did state that it planned to develop a website for furniture, which would most likely have resulted in a failed URS even though there was some evidence of bad faith use; that is, the Examiner could have accepted the informal defense as an "open question of fact" (URS Procedure 8.5).

For the UDRP Panel, however, bad faith was predicated on Respondent's failure under Paragraph 4(c)(i) to provide any evidence of "demonstrable preparations" and under 4(b)(iv) the use of the resolving website that "provided links and 'click through' to other sites which offer products some of which may compete with those of the Complainant." Respondent's argument that it was not responsible for the registrar earning revenue failed to persuade the Panel because "[i] is well established that where a domain name is used to generate revenue in respect of 'click through' traffic, and that traffic has been attracted because of the name's association with the Complainant, such use amounts to use in bad faith [regardless who benefits]." URS Examiners are less likely to invoke the full reasoning of UDRP Panels and more likely to apply the enhanced evidentiary standard to deny suspension.

The heavier burden of clear and convincing evidence is reflected in the most recent URS denial, Skechers U.S.A. Inc. II v. Privacy Protect, LLC (PrivacyProtect.org), FA1805001786732 (Forum June 7, 2018), FA1805001786732 (Forum June 7, 2018). In this dispute, the Examiner found that even though the domain name resolves to a parking page which according to the screen shot provided by the Complainant displays no information "it seems that there is an active literary website managed by Andres Thomas Conteris and there is not any clear evidence which shows the Respondent's commercial gain over the disputed domain. In this respect, the Examiner finds that the bad faith of the Respondent is not proven by the Claimant." (For Skechers, incidentally, this is a rerun, although from a different Respondent, from a failed URS in 2015. It has prevailed in 13 URS proceedings, but never gone to the UDRP for new gTLD complaints, but has filed and been successful in several country code and .com complaints.

The point that needs emphasizing, however, is the reason for rights holders choices. Clearly, the reduced time to remedy under the URS is not a major incentive, but the most likely disincentive is either the remedy or the combination of remedy and standard of proof where it is likely the URS Expert will deny the complaint either for lack of concrete proof or because any doubt about there being an "open question of fact" must be charged to Complainant. If there is any risk of denial, the obvious route would have to be the UDRP; a little more expensive, not quite as "rapid" but greater certainty where there is risk, and with a better remedy if transfer makes strategic sense.

Written by Gerald M. Levine, Intellectual Property, Arbitrator/Mediator at Levine Samuel LLP

Follow CircleID on Twitter

More under: Domain Management, Domain Names, New TLDs, UDRP

Google Engineer Ben McIlwain on Why HSTS Could Be a Perfect Fit for .Brands Security

2018-06-18T17:38:00-08:00

The Google-run .app TLD was always destined to draw attention and scrutiny, from the moment it fetched a then-record ICANN auction price of $25 million. Since it reached General Availability in May it has gained more than 250,000 registrations making it one of the world's most successful TLDs.

However perhaps more interesting was Google's choice to add the .app TLD and its widely used .google extension to the HTTP Strict Transport Security (HSTS) Top-Level Domain preload list, offering an unprecedented level of security for all domains under .google and .app.

I spoke with Ben McIlwain, Tech Lead and Senior Software Engineer at Google to learn a little more about HSTS, the benefits it offers and in particular, how this could be a significant value-add for .brand TLD operators in providing additional security to their customers.

* * *

Ryan Baker: Can you give us an overview of what HSTS actually is and why it's important?

Ben McIlwain: On a basic level what HSTS preloading does is enforce the use of HTTPS. If applied to a whole TLD, then every domain on that TLD is required to be served securely.

Serving via HTTPS is a good first step, but it only provides optional security. Without HSTS preloading, there's a variety of attacks that people intercepting your connection can use to downgrade it, most notably in 2009 when Moxie Marlinspike published the SSL Strip attack.

Using HSTS headers was a good first measure to improve on this, however, it's now superseded by preloading. The HSTS header only comes into play after the first connection to a domain; if you're connecting to a new (to you) domain and the very first connection is intercepted, then the interceptor can simply strip off that header along with any potentially present HTTPS. Preloading offers a stronger level of security because the preload list is built into the browsers themselves, and that can't be intercepted by an attacker. So it's always secure from the very first request.

RB: How does HSTS apply to a closed TLD such as a .brand?

BM: It's a great fit for brand TLDs because all domains on a brand TLD are typically run by the same company, so all those domains are in that company's control. This makes it easy to enforce the requirement to serve all sites on that TLD over HTTPS in order for them to work under HSTS, as we do with .google.

With .app we've also proven that TLD-wide HSTS preloading is feasible even with a large, open TLD. Obviously, it's impractical to retrofit an already launched open TLD with thousands of domains and thus individual users, but a .brand doesn't have that complexity. There's a lot less risk — so there's really no reason why you shouldn't be doing this once you're serving all your sites securely (and you should be!). If you haven't launched your brand TLD yet then there's no risk, as there are no existing possible sites to break.

And it's worth pointing out that right now there's still a small number of TLDs in the HSTS preload list, so anyone who gets in early can get that first-mover advantage on security and credibly say "We were on the vanguard of this next evolution in Web security."

RB: Why is HSTS preloading at the TLD level better than doing it for individual sites?

BM: From a configuration perspective, it's much simpler. You don't have to worry about individually preloading sites or sending HSTS headers. You just add your TLD to the list once and all of your sites are good to go. If you can already go to your websites with https:// and they load correctly (i.e. they have valid SSL certificates), then you're good to go for HSTS preloading.

Another benefit to preloading at a TLD level comes from the rollout process for the HSTS preload list itself. To preload an individual domain name, you enter it at hstspreload.org and it is verified and added to the list, which could take a few weeks. From there, the list is pulled by the individual browsers according to their individual rollout cycles, which typically takes several months between a change being made and being released in the next major browser version. And then there's lag time between when a new version has been released and when users finally get around to updating their software.

To do this for every site you launch can be incredibly impractical for webmasters. But if the entire TLD has already been preloaded, then all newly-created domains on that TLD will immediately get the benefit of increased security from the first moment of creation.

For HSTS preloading as a whole, TLD-level preloading has an aggregate effect as well. There are currently a relatively small, finite number of TLDs, which is more scalable in terms of the overall size of the preload list. Keeping the list smaller saves a non-negligible amount of storage space, memory space, and CPU cycles (from checking against the list) across all the billions of desktop and mobile browser installations out there. In the future, for size reasons, the list might close to new additions of individual domain names unless they meet certain criteria, but if you add the entire TLD you wouldn't face that problem.

And perhaps most importantly is speed. When domains are HSTS preloaded the user's browser will always hit the https version immediately; it'll never hit a redirect being served at the http version. That saves a round-trip to the server, which is a non-negligible speed improvement, especially for people on mobile connections.

RB: What should .brands consider before HSTS preloading?

BM: The main thing to consider is that if you have any domains on your .brand TLD that are not serving on HTTPS, those domains will stop working if you preload the TLD. So the important first step is to look at all the domains you have in use and ensure that all of them work with https://, which of course you should already be doing anyway (but HSTS is a useful forcing function).

You will thus need to have an SSL certificate for every domain on the TLD, even if that domain is just redirecting elsewhere. If you're using a hosting platform provisioning these automatically for you, then hopefully that will already be covered (like through the use of Let's Encrypt). The targets of the redirects will also need to be secure if they are on an HSTS-preloaded domain as well.

Once you've done this due diligence then the next step is simple: Add the TLD to the HSTS preload list. It will then roll out in a future version of major browsers in a couple of months. Other than the obvious check that every domain on the TLD is serving over HTTPS, there are no other "gotchas" to worry about. There's just that one simple requirement.

RB: Do users experience any difference interacting with HSTS preloaded TLDs (such as the 'Secure' marker displayed for sites serving via HTTPS)?

BM: Currently there's no visual difference between HSTS preloaded domains and other secure domains, however, there may be in the future. In the very near future, Chrome will show "Not secure" right next to the address bar for all insecure domain names (those served over http://). This is, of course, scary to see as an end user. You'll never have that problem on an HSTS preloaded TLD because everything on there already has to be served securely. So it's another way to avoid the poor user experience of seeing a warning due to having an insecure domain name; being insecure is no longer even an option.

* * *

It was great to speak with Ben and get his insight on HSTS and how it can apply for TLD operators. For most brands, a huge focus is placed on security to ensure a stable and trustworthy experience for consumers. HSTS preloading at the TLD level could be an opportunity for .brand operators to further strengthen that protection and get in at the ground floor of Google's latest development.

In short, the only requirement for .brand TLDs to be successfully HSTS preloaded is ensuring all sites on the TLD are serving content securely — which is already a requirement for most major organizations.

For almost no additional effort, .brand TLDs can take advantage of HSTS preloading to provide further peace of mind for customers that engaging with their brand online is a safe and secure experience.

You can watch Ben's presentation at this year's Google I/O conference to hear more about .app and HSTS. If you'd like to know more about how to implement HSTS pre-loading on your .brand TLD, reach out to Neustar today.

This piece was originally published on MakeWay.World.

Written by Ryan Baker, Advisor, Professional Services at Neustar Inc.

Follow CircleID on Twitter

More under: Cybersecurity, Domain Management, Domain Names, New TLDs, Web

When the Internet Service Provider is Government-Owned Monopoly: Cuba's Forthcoming 3G Pricing Model

2018-06-18T13:11:00-08:00

Jorge Luis Valdés Hernández, Director de Servicios Convergentes de la Vicepresidencia de Integración Comercial de ETECSA, described the forthcoming changes to their mobile Internet service in a recent press conference. (He also has a very long job title).

To be honest, the press conference coverage left me a bit confused, but this is some of what he said as I understood it:

There are 5.1 million active mobile accounts today and of those 35% use 2G phones, 45% 3G and 20% 4G. (ETECSA will be selling a lot of 3 and 4G phones).

Fourth generation LTE service is being tested in Varadero and deployment will begin in 2019. (Armando Camacho has reported on the tests and found the preliminary speeds surprisingly slow).

I believe that access to selected sites will be free or subsidized — zero-rated — and others will be capped by the amount of data transferred. My guess is that the majority of the free sites will be on the national intranet as opposed to the global Internet.

He gave a hypothetical example in which a user on the 1 GB plan would receive .5 GB free access to sites on the national intranet, stating that international access was more expensive than domestic.

While not defining plans or prices, he presented two hypothetical paid plans — one for "moderate" users at 500 MB per month and a second for "intense" users at 2.5 GB per month — and showed typical data utilization for various applications:

The press conference hailed the "launch" of the mobile Internet, but Cuban 3G mobile access began in 2015 when it was made available to tourists in limited locations and it has steadily expanded. Today there are over 520 3G-compatible base stations covering 47% of the population and all of Havana.

This press conference was not about new technology, but about new pricing, which favors government-approved political content and protects local content and services from the global competition.

Subsidized content delivery is an attractive consumer marketing tool, but proponents of network neutrality argue that it gives the Internet service provider (ISP) the power to pick winners and losers. For example, AT&apm;T could begin zero rating — delivering content produced by its recently acquired Time-Warner subsidiary — at no cost to the user.

Zero-rating or other forms of subsidy are even more problematical when the Internet service provider is a government-owned monopoly, as it is in Cuba. If you live in the US, depending upon your point of view, you probably consider Fox News or MSNBC politically biased, but your ISP does not give you a discount on either. Will Granma.cu be zero-rated?

Going beyond political information, the new pricing continues the Cuban policy of favoring content or service on the national intranet over that on the global Internet. Valdés asserted that in addition to increasing the consumption of national service, this policy would help offset the increased cost of delivering international content, but that increase is marginal and the national intranet discount amounts to a protectionist tariff on foreign content and services. (And, I bet ETECSA will make a handsome profit even with this national-intranet discount).

Mobile connectivity, not WiFi hotspots or home DSL, is the focus of Cuba's current "universal Internet access” campaign and the new pricing plans will serve to protect local content and service providers and control political information.

Written by Larry Press, Professor of Information Systems at California State University

Follow CircleID on Twitter

More under: Access Providers, Broadband, Mobile Internet, Telecom

EURODIG Tbilisi 2018: Positioning in the New Complexity of the Global Internet Governance Ecosystem

2018-06-18T08:25:01-08:00

Early June 2018 the European Internet community traveled into the Caucasian Mountains to participate in EURODIG 11. On its way into the digital age, Europe is, as EU Commissioner Mariya Gabriel said, at another crossroad. In cyberspace, Europe risks becoming sandwiched between US and Chinese Cyberpower policies. Social networks, search engines, smartphones, eTrade platforms — key sectors of today's digital economy — are dominated both by the US and Chinese giants: Alibaba and Amazon, Google and Baidu, Facebook and Weibo, Apple and Huawai. And it is also clear, that the 2020s global political agenda will be determined by issues like cyberwar and digital trade where the United States of America and the Peoples Republic of China will be the main competitors. Insofar EURODIG was a good opportunity to discuss the role of Europe in this forthcoming very complex cyber powerplay.

EURODIG is the European regional version of the UN based Internet Governance Forum (IGF). The 11th edition in Tbilisi, Georgia, saw 800 registrations from more than 50 countries, representing all stakeholder groups. And the agenda covered nearly everything: from cybersecurity and digital trade to artificial intelligence and human rights. EU Commissioner Mariya Gabriel called EURODIG "the most successful and most relevant regional initiative on Internet Governance." And indeed, over the years, EURODIG has innovated the IGF processes with new ideas: interactive formats of sessions, tangible output in form of clear and short messages, a youth IGF, open calls for themes, decentralized and bottom-up management procedures.

However, the Tbilisi meeting also showed that the IGF community, which has grown substantially since the days of the 2005 UN World Summit on the Information Society (WSIS), is now also partly the victim of its own success. There is a risk that the "usual suspects" of the global Internet Governance debate, who have been the drivers of discussions in the past, are sidelined and substituted by new communities which represent new powerhouses from governments and businesses. Those powerhouses have their own new agendas and tend to ignore widely what has been achieved over the last two decades in building a functioning Internet Governance ecosystem.

Reinventing the Wheel?

For years the message from EURODIG and the IGF was: Internet Governance is a big political issue and the multistakeholder approach is an innovation in global policymaking. 15 years after the WSIS I, world leaders have now recognized that the internet is indeed a big issue — they call it now "cyber" or "digital" — and they discuss it at summit meetings like BRICS, G7 or G20. But they have partly different ideas how to manage this network of networks. They pay lipservice to the multistakeholder approach, but the reality is that the majority of governments prefer to negotiate Internet-related issues behind closed doors.

This is the case if it comes to cybersecurity where a UN Group of Governmental Experts (GGE) tried to define rules of the road for the cyberspace. This is the case for digital trade, where the intergovernmental World Trade Organisation is negotiating behind closed doors frameworks for eCommerce. Both issues have been discussed since years both at the IGF and EURODIG. And agreements which have been achieved in this global Internet Governance debate are certainly also relevant for cybersecurity and digital trade.

The Tunis Agenda (2005) has defined what Internet Governance is and has invited both state and non-state actors to participate — in their respective roles — in the development of Internet-related public policies. The NetMundial Declaration (2014) has defined fundamental principles for good behaviour in cyberspace and has specified guidelines for multistakeholder cooperation as openness, transparency, bottom-up and inclusive. ICANN's IANA transition (2016) has demonstrated the feasibility of multistakeholder cross-community processes by transferring the responsibility for the management of key global Internet resources — domain names, IP addresses, and Internet protocols — to the empowered community (which include also governments in their respective role).

But the new intergovernmental negotiating bodies which are dealing now with cybersecurity and digital trade are rather dislinked from IGF and ICANN processes. What we see is that new intergovernmental silos are emerging and the risk is growing that in all those new closed silos the cyberwheel is reinvented.

This new intergovernmental silo approach could become a big problem. The Internet is a network of networks, everything is connected with everything via protocols and codes. This has consequences for Internet-related public policies. In the analog world, security issues had only little to do with trade, environment or freedom of expression. In the digital world, those issues are interconnected as the new EU data protection legislation (GDPR) is demonstrating. The regulation of a human rights issue — privacy — has far-reaching consequences for the business model of internet corporations and the security agenda of law enforcement agencies. And this is valid also the other way around. Any cybersecurity treaty will have economic implications and touches human rights. And agreements on digital trade will have a cybersecurity component and will also have consequences for human rights.

In other words, the big challenge with the Internet Governance Ecosystems and its growing complexity is not only to include all stakeholders in their respective roles in policy development and decision making but also to inter-link the new emerging intergovernmental silos and to pull them into a multistakeholder environment. What is needed is a holistic approach to global Internet negotiations as it was also recognized during the recent Bratislava meeting (May 2018) of the Global Commission on Stability in Cyberspace.

The Need for a Holistic Approach

How to organize such a holistic approach? The first step has to be to enhance communication among all governmental and non-governmental stakeholders. Decisions can be made only on an informed basis. No single stakeholder has all the knowledge and all the capacities which are needed to find sustainable solutions.

There is a need for something like a "global clearinghouse" which identifies the key components of an issue before decisions are made. But wait a minute, such a "clearinghouse" does already exist. If we would not have the Internet Governance Forum (IGF), there would be a need to invent it now. The IGF and its regional and national subsidiaries — like EURODIG — provide the needed framework for such a discussion across constituencies, stakeholders, state and nonstate organizations. The problem is that some governments and some business underestimate the potential of the IGF and are looking for alternative venues.

It is certainly true that the IGF has some weaknesses. The UNCSTD IGF Improvement Working Group has made some recommendations which have been reaffirmed by the UN General Assembly in its WSIS+10 Resolution in December 2015. Progress is slow but there is improvement: More intercessional work, more tangible output, more interlinkage with national and regional initiatives. And we see as EURDOG in Tbilissi has demonstrated, a more interactive cross-community debate, the involvement of more young people and the ability to send 62 short and concrete messages to all stakeholders which tell them what they could and should do in fields like cybersecurity, digital trade, artificial intelligence or human rights.

The new UN Internet Commission, which will be probably established under the guidance of UN Secretary-General Antonio Guiterres by the forthcoming UN General Assembly in fall 2018 would be very wise if it would push for a strengthening of the IGF process and to recommend to governmental and non-governmental stakeholders not only to deepen the multistakeholder cooperation but to argue also in favor of a holistic approach.

A new Round of Controversies?

However, recent meetings on the highest political level did send some contradicting and confusing messages to the global Internet community.

On the one hand, the leaders of the G7 — including US President Trump, French President Macron and the German Chancellor Merkel — during its meeting in June 2018 in Canada remained silent with regard to cybersecurity and digtal trade, but agreed on a "Commitment on Defending Democracy from Foreign Threats" which included the establishment of "a G7 Rapid Response Mechanism to strengthen our coordination to identify and respond to diverse and evolving threats to our democracies, including through sharing information and analysis, and identifying opportunities for coordinated response… in collaboration with governments, civil society and the private sector". The G7 wants to "engage directly with internet service providers and social media platforms regarding malicious misuse of information technology by foreign actors, with a particular focus on improving transparency regarding the use and seeking to prevent the illegal use of personal data and breaches of privacy."

On the other hand the leaders of the Shanghai Cooperation Organisation (SCO) — including Chinese President Xi, Russian President Putin and India's President Modi — during its parallel meeting in China supported "the central role of the UN in developing universal international rules and principles as well as norms for countries' responsible behaviour in the information space." They advocated for "the establishment of a working mechanism within the framework of the UN". And they argued that "a governing organization established to manage key internet resources must be international, more representative and democratic."

What does this mean? Is this the kick-start for a re-opening of the ICANN vs. ITU controversy? It could become a "hot fall" for Internet discussions.

In October 2018 there will be ICANN's High-Level GAC Meeting in Barcelona. The other week ITU's Plenipotentiary Conference starts in Dubai. Mid-November 2018 will see the IGF in Paris. And at the end of November 2018, the leaders of the G20 meet in Buenos Aires. Let's wait and see how the Internet world looks in December 2018.

A Chance for Europe

In this process, Europe has a chance to become a driver and pioneer.

1. Europe's strength is the rule of law. European institutions — from the Council of Europe with the European Court of Human Rights to the institutions of the European Union with the European Parliament, European Commission and European Court of Justice have produced instruments and offer procedures which make clear that cyberspace is not ruled by the "law of the jungle". GDPR is an interesting case and it remains to be seen how this European regulation contributes to more stability in cyberspace. It is a complicated issue and slippery territory but there is a need for rules-based frameworks also for issues like cybersecurity, taxation, fake news, hatespeech and others.

2. Europe's opportunity is industry 4.0, Artificial Intelligence and the Internet of Things. To link Europe's manufacturing industry to digitalization has a lot of potential. Europe has a highly developed educational system which is able to produce the skill sets needed for tomorrows digital economy.

3. But Europe's weakness is to translate good ideas into concrete policies and projects. The 28 member states of the EU have declared the establishment of a Digital Single Market as a high priority. Under the Estonian EU presidency (Fall 2017) there was a "Digital EU Summit". There is some progress, but progress is slow. And Europe has an implementation problem.

Looking into the coming months, there is a window of opportunity for a big European Cyber initiative which could include also proposals for a holistic approach to global Internet negotiations. When the French president Macron announced that Paris will host this year's IGF in Paris (November 2018) he also indicated that time is ripe to speed up Europe's journey into the digital age. After Paris, The Hague will host EURODIG 12 in June 2019. And the 14th IGF is scheduled for Berlin (November 2019). What is needed now on the road to Paris, The Hague and Berlin is more European steam.

Written by Wolfgang Kleinwächter, Professor Emeritus at the University of Aarhus

Follow CircleID on Twitter

More under: Internet Governance, Policy & Regulation

ICANN vs EPAG: ICANN Seeks Appeal Plus Pushes for ECJ Referral

2018-06-14T08:00:00-08:00

As I predicted ICANN is pursuing its case against EPAG. They're now not only appealing the case to a higher court in Germany but are also trying to get the entire thing referred to the European Court of Justice.

In an announcement late last night ICANN made it very clear what their intentions are. While they're pursuing the appeal in the higher court in the German region, which makes sense at some level, it's also very clear that they're not taking "no" for an answer:

If the Higher Regional Court does not agree with ICANN or is not clear about the scope of the European Union's General Data Protection Regulation (GDPR), ICANN is also asking the Higher Regional Court to refer the issues in ICANN's appeal to the European Court of Justice.

I'm not a lawyer, but it does strike me as slightly odd to tell the higher court that they don't trust the outcome even before it's been made.

The appeal is taking a slightly more nuanced approach to its pleadings with an emphasis not just on the collection of the admin-c and tech-c contacts, but the "legal" collection of same. Jones Day is of the opinion that Epag should be obliged to collect the contacts and attempts to provide a rationale for doing so in what it deems to be a legal way under GDPR. They also make reference to FAQs published on a couple of randomly chosen websites: bestregistrar.com and vcgcorporate.zendesk.com. While the text on those sites might support ICANN's position it's not clear why those sites were chosen, beyond the obvious backing of ICANN's views.

While I could be mistaken, to the best of my knowledge, most ICANN policies do not make specific reference to the tech-c beyond the references in relation to the collection and display. The admin-c is referenced in a couple of policies, for example in the transfer policy, but it is always the registrant contact that is key.

The court filings including a number of affidavits and other exhibits are available here.

Of course, the bigger question is why on earth ICANN is pursuing this so doggedly. If you look at the various outstanding items in the temporary specification there are several areas which will be highly contentious such as providing access to non-public data to "legitimate" interests.

And what about the costs of pursuing this case?

Getting your lawyer to send a threatening letter might only cost a couple of hundred dollars, but pursuing a court case like this will cost thousands, if not, hundreds of thousands of dollars. Wasn't ICANN concerned about its finances?

Written by Michele Neylon, MD of Blacknight Solutions

Follow CircleID on Twitter

More under: Domain Names, ICANN, Privacy, Whois

Internet Society Announces New Partnership with Consumers International

2018-06-13T11:17:00-08:00

The Internet Society today announced a new working partnership with Consumers International, the membership organization for consumer groups around the world. "We will be working with industry and consumer groups to improve the overall security and privacy of IoT offerings, and to make sure consumers have products or services that are secure and privacy-respecting," says a joint statement from Kathy Brown, President & CEO of Interne Society and Amanda Long, Director General of Consumers International. "Many IoT products are rushed to market with little consideration for basic security and privacy protections. It's time for manufacturers to get ahead of the IoT security curve and take actions that will limit risk and instill consumer trust. To do this, we will work with manufacturers, retailers and regulators to make sure safety and privacy are included in the initial design and through the entire product lifecycle. And this is just the beginning."

Follow CircleID on Twitter

More under: Cybercrime, Cybersecurity, Internet Governance, Internet of Things, Mobile Internet, Web

Oracle Launches Internet Intelligence Map Providing Insight Into the Impact of Internet Disruptions

2018-06-13T10:47:00-08:00

Oracle today announced the launch of the Internet Intelligence Map website; a source available for free that provides country-level connectivity statistics based on traceroutes, BGP, and DNS query volumes on a single dashboard. By presenting these three dimensions of internet connectivity side-by-side, company hopes users can investigate the impact of an issue on internet connectivity worldwide. Doug Madory, Director of Internet Analysis at Oracle Dyn, writes: "The website has two sections: Country Statistics and Traffic Shifts. The Country Statistics section reports any potential Internet disruptions seen during the previous 48 hours. Disruption severity is based on three primary measures of Internet connectivity in that country: BGP routes, traceroutes to responding hosts and DNS queries hitting our servers from that country."

Follow CircleID on Twitter

More under: Cyberattack, Cybersecurity, DDoS, Networks

Leveraging Traffic Statistics to Manage Corporate Domain Portfolios

2018-06-13T10:14:00-08:00

Corporate domain name portfolios often consist of domain names that do not resolve to relevant content. In fact, it's not uncommon for less than half of corporate domains to point to live content. Sure there are domains such as those that point to "sucks" sites or those registered anonymously for future use that purposely do not resolve, but those are the exception to the rule. Most domains that do not resolve were registered defensively or acquired via acquisition — without much thought given to where the domains should actually point.

The best practice is to ensure that all non-core domains point to relevant content. Using domain forwarding, which is a common feature provided by corporate registrars, is a quick and easy way to accomplish this. It allows corporations to view historical traffic statistics to understand whether the name is being visited and should be renewed. Of course, for domains that do not appear to point to content, it is critical to understand whether DNS records such as MX records exist, before updating nameservers to support domain forwarding. Just because a domain does not appear to resolve, does not mean that it is not being used for mail or for some other internal application.

A common question that is asked, is often around how much traffic should a domain receive in order for it to be considered valuable? Of course, that depends. Raw numbers can be useful, but tracking conversion rates provides powerful evidence for understanding the value of a domain.

So if a domain does not receive any traffic, should it be allowed to lapse? While traffic is a good place to start when paring a portfolio, there are still a number of other factors to consider before lapsing any domain including whether DNS records exist, the domain was previously recovered, it supports an existing brand, it has inherent value, and the brand owner has cleared the name for expiration. However, the most important question to ask is if the domain were to be reregistered by a squatter, would that be OK?

While traffic is not the only measure by which to value the importance of a domain, it certainly can be helpful in making renewal decisions, and when determining what to lapse, it is a logical place to start.

Written by Elisa Cooper, SVP Marketing and Policy at Brandsight, Inc.

Follow CircleID on Twitter

More under: Domain Management, Domain Names, Intellectual Property

Most Abused TLDs Put Under Spotlight by Spamhaus

2018-06-11T12:20:00-08:00

Partial list from Spamhaus' The 10 Most Abused Top Level Domains as of 11 June 2018TLDs such as .men and .loan are listed as some of the most abused top-level domains in the world. Spamhaus which has been tracking spam and related cyber threats since 1998, says some domain name registrars and resellers knowingly sell high volumes of domains to bad actors for profit, and many registries do not do enough to stop or limit this endless supply of domains. To shed light on the situation, Spamhaus is running a dedicated a page on its website showcasing "The World's Most Abused TLDs."

— "A TLD may be 'bad' in two ways," reads a paragraph from the page. "On one side, the ratio of bad to good domains may be higher than average, indicating that the registry could do a better job of enforcing policies and shunning abusers. However, some TLDs with a high fraction of bad domains may be quite small, and their total number of bad domains could be relatively limited with respect to other, bigger TLDs. Their total 'badness' to the Internet is limited by their small total size."

— "The other side is that some large TLDs may have a large number of bad domains as a result of the sheer size of their domain corpus. Even if their corrective measures are effective, they still constitute a problem on the global scale, and they could assign further resources to improve their anti-abuse processes and bring down the overall number of bad domains."

— Security expert Biran Krebs reporting on the Spamhaus' list says: "[T]he Internet Corporation for Assigned Names and Numbers (ICANN) - enabled the new TLDs in response to requests from advertisers and domain speculators - even though security experts warned that an onslaught of new, far cheaper TLDs would be a boon mainly to spammers and scammers. And what a boon it has been. The newer TLDs are popular among spammers and scammers alike because domains in many of these TLDs can be had for pennies apiece. But not all of the TLDs on Spamhaus' list are prized for being cheaper than generic TLDs..."

Follow CircleID on Twitter

More under: Cybercrime, Cybersecurity, Domain Names, Spam, New TLDs

WHOIS Users Facing Serious Challenges Caused by Post-GDPR Fragmentation

2018-06-08T16:44:00-08:00

On May 25, 2018, the European General Data Protection Regulation (GDPR) came into effect, meaning that European data protection authorities (DPAs) can begin enforcing the regulation against non-compliant parties.

In preparation, the ICANN Board passed a Temporary Specification for gTLD Registration Data — essentially a temporary policy amendment to its registrar and registry contracts to facilitate GDPR compliance while also preserving certain aspects of the WHOIS system of domain name registration data. Unfortunately, the Temporary Specification permits registrars and registries to significantly reduce publicly-accessible WHOIS data, and does not include a mandatory minimum uniform mechanism for access to non-public WHOIS data for legitimate purposes (such as law enforcement, cybersecurity, or intellectual property rights protection).

The Temporary Specification merely states the following in connection with access to non-public data:

Contracted parties must provide reasonable access to personal data in registration data to third parties (1) on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the registrant; or (2) where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful.

See ICANN, Temporary Specification for gTLD Registration Data, Appendix A, Section 4 (May 25, 2018) (the "Temporary Specification").

Reported Challenges

In light of the limited DPA or jurisprudential guidance concerning the legitimacy of providing any non-public WHOIS data to any class of third party, third parties are dependent on ad hoc determinations as to whether their legitimate interests are outweighed by privacy rights in any given case. While certain contracted parties appear to be providing limited guidance as to what information they require in order to respond favorably to a data access request (of course with no guarantee of success), the vast majority have not provided any such guidance, and all decisions are made on a case-by-case basis with no transparent or predictable criteria.

This problem is not limited to registration authorities based in Europe. It is already being observed throughout the world, including in the United States. In at least one case, a California-based registrar declined a data access request related to a specific intellectual property rights enforcement effort, stating that it "would provide no WHOIS data" at all while failing to provide any rationale for its decision. According to anecdotal reports, the same registrar also has refused to provide a mechanism for contacting their registrants in connection with legitimate purposes, including domain name acquisition inquiries, even though the Temporary Specification requires either an anonymized registrant email address or web form to facilitate registrant contact. See Temporary Specification, Appendix A, Section 2.5.1 ("Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself.").

Further complexity has been added to this problem through an unclear and disparate delineation between registration data that is masked because of a proxy registration service, versus registration data made non-public in response to GDPR. Certain registrars have traditionally treated the former category of data as sacrosanct short of a subpoena or court order. To that end, another registrar reportedly declined to provide registrant contact information in response to a request precipitated by a phishing attack perpetrated using the relevant domain name. It is unclear on what basis the registrar declined to provide critical registration data in light of a well-founded and immediate need. Ironically, consumers are more exposed to theft of their personally identifiable information through domain-based phishing attacks that are now taking much longer to resolve.

Furthermore, it appears that some contracted parties are not even complying with the Temporary Specification, even where it mandates that certain registration data be provided in certain specific contexts. For example, anecdotal reports have already been made about a certain EU-based registrar that was asked by a UDRP provider to confirm the underlying registration data in connection with a UDRP proceeding, where the registrar refused to provide the full data, despite the applicable requirements in the UDRP (an ICANN Consensus Policy), UDRP Rules, and Temporary Specification and other relevant and binding provisions in the registrar's accreditation agreement with ICANN. See, e.g., Temporary Specification, Appendix E, Section 1.1 ("The Registrar MUST provide the UDRP provider with the full Registration Data for each of the specified domain names, upon the UDRP provider notifying the Registrar of the existence of a complaint, or participate in another mechanism to provide the full Registration Data to the Provider as specified by ICANN.").

At a higher level, at least one major global company has already estimated that its ability to effectively enforce their trademark rights against infringing domain names may drop by 24% in the wake of the GDPR effective date and adoption of ICANN's Temporary Specification.

Conclusion and Next Steps

Although it remains early days, the impact of GDPR on the WHOIS system is already being felt by legitimate parties who rely on WHOIS data to protect Internet users from harmful activity. Anecdotal reports are already starting to pour in identifying specific challenges presented by the current fragmented and unpredictable state of WHOIS services.

This is clearly unacceptable. ICANN has been entrusted with the oversight of the domain name system, and, specifically, preserving the security and stability of the Internet. By not including an accreditation model for legitimate purposes, ICANN has destabilized the industry and contributed to the ensuing chaos. ICANN must step in without further delay to lay down a harmonized framework for credentialed access to non-public WHOIS data for specific pre-determined legitimate purposes. ICANN must also bring the full contractual compliance weight, mediation, arbitration and even litigation to bear in order to enforce not only the Temporary Specification, but also the same harmonized framework. In the meantime, businesses, brand owners, cybersecurity professionals, law enforcement and government agents, and others who rely on WHOIS to conduct their vital anti-abuse and consumer protection activities in the public interest should continue to document the harms and challenges caused by the current state of the broken WHOIS system.

Written by Brian Winterfeldt, Founder and Principal at Winterfeldt IP Group

Follow CircleID on Twitter

More under: Domain Management, DNS, Domain Names, ICANN, Internet Governance, Law, Policy & Regulation, Privacy, Whois