Senior VP and Chief Technology Officer at Verisign
Joined on June 6, 2012
Total Post Views: 382,515
About |
Dr. Burt Kaliski Jr., senior vice president and chief technology officer, leads Verisign’s long-term research program. Through the program’s innovation initiatives, the CTO organization, in collaboration with business and technology leaders across the company, explores emerging technologies, assesses their impact on the company’s business, prototypes and evaluates new concepts, and recommends new strategies and solutions. Burt is also responsible for the company’s industry standards engagements, university collaborations, and technical community programs.
Prior to joining Verisign in 2011, Burt served as the founding director of the EMC Innovation Network, the global collaboration among EMC’s research and advanced technology groups and its university partners. He joined EMC from RSA Security, where he served as vice president of research and chief scientist. Burt started his career at RSA in 1989, where, as the founding scientist of RSA Laboratories, his contributions included the development of the Public-Key Cryptography Standards, now widely deployed in internet security.
Burt has held appointments as a guest professor at Wuhan University’s College of Computer Science and as a guest professor and member of the international advisory board of Peking University’s School of Software and Microelectronics. He has also taught at Stanford University and Rochester Institute of Technology. Burt was program co-chair of Cryptographic Hardware and Embedded Systems 2002, chair of the Institute of Electrical and Electronics Engineers P1363 working group, program chair of CRYPTO ‘97, and general chair of CRYPTO ‘91. He has also served on the scientific advisory board of QEDIT, a privacy-enhancing technology provider.
Burt is a member of the Association for Computing Machinery, a senior member of the IEEE Computer Society, and a member of Tau Beta Pi.
Burt received his PhD, Master of Science and Bachelor of Science degrees in computer science from the Massachusetts Institute of Technology, where his research focused on cryptography.
Except where otherwise noted, all postings by Dr. Burt Kaliski Jr. on CircleID are licensed under a Creative Commons License.
The quantum computing era is coming, and it will change everything about how the world connects online. While quantum computing will yield tremendous benefits, it will also create new risks, so it's essential that we prepare our critical internet infrastructure for what's to come. That's why we're so pleased to share our latest efforts in this area, including technology that we're making available as an open source implementation to help internet operators worldwide prepare. more
In 2021, we discussed a potential future shift from established public-key algorithms to so-called "post-quantum" algorithms, which may help protect sensitive information after the advent of quantum computers. We also shared some of our initial research on how to apply these algorithms to the Domain Name System Security Extensions, or DNSSEC. In the time since that blog post, we've continued to explore ways to address the potential operational impact of post-quantum algorithms on DNSSEC, while also closely tracking industry research and advances in this area. more
The global internet, from the perspective of its billions of users, has often been envisioned as a cloud -- a shapeless structure that connects users to applications and to one another, with the internal details left up to the infrastructure operators inside. From the perspective of the infrastructure operators, however, the global internet is a network of networks. It's a complex set of connections among network operators, application platforms, content providers and other parties. more
In previous posts in this series, I've discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC). In this final blog post, I'll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I've also written about DNS encryption as well as minimization in a separate post on DNS information protection.) more
In my last article, I described efforts underway to standardize new cryptographic algorithms that are designed to be less vulnerable to potential future advances in quantum computing. I also reviewed operational challenges to be considered when adding new algorithms to the DNS Security Extensions (DNSSEC). In this post, I'll look at hash-based signatures, a family of post-quantum algorithms that could be a good match for DNSSEC from the perspective of infrastructure stability. more
One of the "key" questions cryptographers have been asking for the past decade or more is what to do about the potential future development of a large-scale quantum computer. If theory holds, a quantum computer could break established public-key algorithms including RSA and elliptic curve cryptography (ECC), building on Peter Shor's groundbreaking result from 1994. more
In my last post, I looked at what happens when a DNS query renders a "negative" response -- i.e., when a domain name doesn't exist. I then examined two cryptographic approaches to handling negative responses: NSEC and NSEC3. In this post, I will examine a third approach, NSEC5, and a related concept that protects client information, tokenized queries. The concepts I discuss below are topics we've studied in our long-term research program as we evaluate new technologies. more
In my previous post, I described the first broad scale deployment of cryptography in the DNS, known as the Domain Name System Security Extensions (DNSSEC). I described how a name server can enable a requester to validate the correctness of a "positive" response to a query -- when a queried domain name exists -- by adding a digital signature to the DNS response returned. more
As one of the earliest protocols in the internet, the DNS emerged in an era in which today's global network was still an experiment. Security was not a primary consideration then, and the design of the DNS, like other parts of the internet of the day, did not have cryptography built in. Today, cryptography is part of almost every protocol, including the DNS. And from a cryptographer's perspective, as I described in my talk at last year's International Cryptographic Module Conference (ICMC20), there's so much more to the story than just encryption. more
Over the past several years, questions about how to protect information exchanged in the DNS have come to the forefront. One of these questions was posed first to DNS resolver operators in the middle of the last decade, and is now being brought to authoritative name server operators: "to encrypt or not to encrypt?" It's a question that Verisign has been considering for some time as part of our commitment to security, stability and resiliency of our DNS operations and the surrounding DNS ecosystem. more
The Domain Name System (DNS) has become the fundamental building block for navigating from names to resources on the internet. DNS has been employed continuously ever since its introduction in 1983, by essentially every internet-connected application and device that wants to interact online. Emerging from an era where interconnection rather than information security was the primary motivation, DNS has gradually improved its security features. more
The evolution of the internet is anchored in the phenomenon of new technologies replacing their older counterparts. But technology evolution can be just as much about building upon what is already in place, as it is about tearing down past innovations. Indeed, the emergence of cloud computing has been powered by extending an unlikely underlying component: the more than 30-year-old global Domain Name System (DNS). more
A year ago, under the leadership of the Internet Corporation for Assigned Names and Numbers (ICANN), the internet naming community completed the first-ever rollover of the cryptographic key that plays a critical role in securing internet traffic worldwide. The ultimate success of that endeavor was due in large part to outreach efforts by ICANN and Verisign which, when coupled with the tireless efforts of the global internet measurement community, ensured that this significant event did not disrupt internet name resolution functions for billions of end users. more
One of the longstanding goals of network security design is to be able to prove that a system -- any system -- is secure. Designers would like to be able to show that a system, properly implemented and operated, meets its objectives for confidentiality, integrity, availability and other attributes against the variety of threats the system may encounter. A half century into the computing revolution, this goal remains elusive. more
Earlier this year, I wrote about a recent enhancement to privacy in the Domain Name System (DNS) called qname-minimization. Following the principle of minimum disclosure, this enhancement reduces the information content of a DNS query to the minimum necessary to get either an authoritative response from a name server, or a referral to another name server. more
Two principles in computer security that help bound the impact of a security compromise are the principle of least privilege and the principle of minimum disclosure or need-to-know. As described by Jerome Saltzer in a July 1974 Communications of the ACM article, Protection and the Control of Information Sharing in Multics, the principle of least privilege states, "Every program and every privileged user should operate using the least amount of privilege necessary to complete the job." more
A network traffic analyzer can tell you what's happening in your network, while a Domain Name System (DNS) analyzer can provide context on the "why" and "how." This was the theme of the recent Verisign Labs Distinguished Speaker Series discussion led by Paul Vixie and Robert Edmonds, titled Passive DNS Collection and Analysis -- The "dnstap" Approach. more
UCLA and Washington University in St. Louis recently announced the launch of the Named Data Networking (NDN) Consortium, a new forum for collaboration among university and industry researchers, including Verisign, on one candidate next-generation information-centric architecture for the Internet. Verisign Labs has been collaborating with UCLA Professor Lixia Zhang, one of the consortium's co-leaders, on this future-directed design as part our university research program for some time. more
Recent comments on the name collisions issue in the new gTLD program raise a question about the differences between established and new gTLDs with respect to name collisions, and whether they're on an even playing field with one another. Verisign's latest public comments on ICANN's "Mitigating the Risk of DNS Namespace Collisions" Phase One Report, in answering the question, suggest that the playing field the industry should be concerned about is actually in a different place. The following points are excerpted from the comments submitted April 21. more
Verisign posted preliminary public comments on the "Mitigating the Risk of DNS Namespace Collisions" Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done. I have outlined the four main observations... more
Keynote speaker, and noted security industry commentator, Bruce Schneier (Co3 Systems ) set the tone for the two days with a discussion on how humans name things and the shortcomings of computers in doing the same. Names require context, he observed, and "computers are really bad at this" because "everything defaults to global." Referring to the potential that new gTLDs could conflict with internal names in installed systems, he commented, "It would be great if we could go back 20 years and say 'Don't do that'," but concluded that policymakers have to work with DNS the way it is today. more
I'm delighted to announce that the name collisions workshop this weekend will include Jeff Schmidt, CEO of JAS Global Advisors, presenting the Name Collision Occurrence Management Framework that his firm just released for public review. Jeff's presentation is one of several on the program announced by the program committee for the Workshop and Prize on Root Causes and Mitigations of Name Collisions (WPNC). more
The Mitigating the Risk of DNS Namespace Collisions report, just published by JAS Global Advisors, under contract to ICANN, centers on the technique of "controlled interruption," initially described in a public preview shared by Jeff Schmidt last month. With that technique, domain names that are currently on one of ICANN's second-level domain (SLD) block lists can be registered and delegated for regular use, provided that they first go through a trial period where they're mapped to a designated "test" address. more
There may still be a few security practitioners working in the field who didn't have a copy of Bruce Schneier's Applied Cryptography on their bookshelf the day they started their careers. Bruce's practical guide to cryptographic algorithms, key management techniques and security protocols, first published in 1993, was a landmark volume for the newly emerging field, and has been a reference to developers ever since. more
According to the Online Etymology Dictionary, the verb collide is derived from the Latin verb collidere, which means, literally, "to strike together": com- "together" + lædere "to strike, injure by striking." Combined instead with loquium, or "speaking," the com- prefix produces the Latin-derived noun colloquy: "a speaking together." So consider WPNC 14 - the upcoming namecollisions.net workshop - a colloquium on collisions: speaking together to keep name spaces from striking together. more
Many years ago on my first trip to London, I encountered for the first time signs that warned pedestrians that vehicles might be approaching in a different direction than they were accustomed to in their home countries, given the left-versus-right-side driving patterns around the world. (I wrote a while back about one notable change from left-to-right, the Swedish "H Day," as a comment on the IPv6 transition.) more
ICANN's second level domain (SLD) blocking proposal includes a provision that a party may demonstrate that an SLD not in the initial sample set could cause "severe harm," and that SLD can potentially be blocked for a certain period of time. The extent to which that provision would need to be exercised remains to be determined. However, given the concerns outlined in Part 2 and Part 3 of this series, it seems likely that there could be many additions (and deletions!) from the blocked list given the lack of correlation between the DITL data and actual at-risk queries. more
As discussed in the several studies on name collisions published to date, determining which queries are at risk, and thus how to mitigate the risk, requires qualitative analysis. Blocking a second level domain (SLD) simply on the basis that it was queried for in a past sample set runs a significant risk of false positives. SLDs that could have been delegated safely may be excluded on quantitative evidence alone, limiting the value of the new gTLD until the status of the SLD can be proven otherwise. more
For several years, DNS-OARC has been collecting DNS query data "from busy and interesting DNS name servers" as part of an annual "Day-in-the-Life" (DITL) effort (an effort originated by CAIDA in 2002) that I discussed in the first blog post in this series. DNS-OARC currently offers eight such data sets, covering the queries to many but not all of the 13 DNS root servers (and some non-root data) over a two-day period or longer each year from 2006 to present. more
As widely discussed recently, observed within the ICANN community several years ago, and anticipated in the broader technical community even earlier, the introduction of a new generic top-level domain (gTLD) at the global DNS root could result in name collisions with previously installed systems. Such systems sometimes send queries to the global DNS with domain name suffixes that, under reasonable assumptions at the time the systems were designed, may not have been expected to be delegated as gTLDs. more
It would be one of the ironies of global technology development that the West has effectively so far followed a Jugaad principle of "good enough" innovation for DNS security, whereas India could well embrace all the latest advances in DNS security as its Internet economy grows. Like most other protocols from the early Internet, the DNS protocol was not designed with security built in. For those protocols, security services were typically either implemented at a different layer of the protocol stack, or were added on later. more
In recent interviews about World IPv6 Launch I've been asked by several different people whether or not I think there needs to be some kind of a "Flag Day" on which the world all together switches from Internet Protocol version 4 (IPv4) to the version 6 (IPv6). I don't think a flag day is needed. World IPv6 Launch is just the right thing. It's worth looking at some previous flag-type days to get a better sense of why. more