Chief Technology Officer at Verisign
Joined on June 6, 2012
Total Post Views: 16,681
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.
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»