Chief Technology Officer at Verisign
Joined on June 6, 2012
Total Post Views: 48,950
As Verisign's chief technology officer, Burt is responsible for the company's long-term technology vision. He is the leader of Verisign Labs, which focuses on applied research, university collaboration, industry thought leadership, and intellectual property strategy. He also facilitates the technical community within Verisign and works closely with Verisign's executive leadership team to turn the Company vision into near-term value for its business units and customers.
Prior to joining Verisign in 2011, Burt served as the founding director of the EMC Innovation Network, the global collaboration group 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. Dr. Kaliski 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 (PKCS), now widely deployed for internet security.
Dr. Kaliski is a guest professor at Wuhan University's College of Computer Science, and was previously 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.
He is also a trustee emeritus of the Massachusetts Technology Leadership Council, and a member of the Institute of Electrical and Electronics Engineers (IEEE) Computer Society and Tau Beta Pi.
Dr. Kaliski received his bachelor's, master's and Ph.D. degrees in computer science from the Massachusetts Institute of Technology, where his research focused on cryptography.
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»