Last Saturday (2nd March) Yeti DNS Workshop was held in Tokyo. It is the timing between the end of first phase of Yeti DNS project and preparation of the second. People gathered with the goal of revisiting what have been done, discussing the current work and restarting Yeti project with recent technical attention and focus different from 4 years ago. Besides Yeti business, we have some invited talks on Internet governance and decentralized infrastructure over root. (Slides are available here, Talk audios are updated in YouTube: morning session, afternoon session (the first part), and Hugo’s record video).

The morning keynote was given by Dr. Paul Vixie. He revisited the background and the history related to the “third rail” of Internet governance and pressures on current DNS operation on Name Space(s). As a response to the controversy of alternative root, he made clarity on the difference the function of editing, signing and publication of DNS(Root) zone. It is a emphasis that Yeti from the beginning keep boundaries for One Unique Internet Identifier and not amending the IANA name space.

After Paul’s presentation, Davey Song on behalf of Yeti’s operational team gave a report reviewing Yeti DNS Project and Proposed Future AgendaYeti DNS Project. As usual, like every status-quo report given in previous Yeti meetings, it covers the background of Yeti DNS project including the motivation, principles and Yeti architecture (described in RFC8483). In addition he concluded and proposed two notable directions which deserve our effort in future. One is about Large DNS response issue and another is Yeti redundancy model with multiple signers. The two directions are discussed in the afternoon sessions.

In the afternoon, there were two sessions. The first one was about building a fault-tolerant root with decentralized Internet functions. Davey introduced the background, requirement and potentials. As a design principle, Yeti adds redundancy into root system to avoid single point of failure, both in root zone signing and publication function. So we have 3 Signers (DMs) and 25 servers which is different from the IANA root system. But it was found that such horizontal scaling will increase the size of DNS response, for example by containing more keys in the DNSKEY response. It is a undesirable side effect which also presents in previous proposal by John Ihren & Bill manning and Brenden Kuerbis & Milton Mueller.

Is it possible to introduce multiple independent Signers without changing the DNSSEC validation interface? And without augmenting the size of DNS response as well? In the end of Davey’s slides, threshold Signatures(Signing) was borrowed from blockchain field and introduced as a desirable property in the context of DNSSEC signing.

Presentation from Wei Xinpeng and Hugo Salgado-Hernández also gave us some potentials. In Wei’s presentation an ambitious decentralized Internet infrastructure was proposed covering DNS, RPKI and PKI functions. Enabled by blockchain technology (Permissioned Chain), all Internet resources like IP, domain name and certificate can be managed in both registration and resolution. As to DNS root, the good news is that it is technical possible to remove the necessity of centralized roles in editing, signing and distribution of root zone. During the discussion of participants, it was pointed out that if it targets the existing IP and DNS users, the radical change to current NIC&DNS system will make it hard to prevail (lacks of economic incentive for stakeholders to join)，but they are planning to explore some directions that would be more compatible to the existing system. There is also performance concerns if DNS hierarchy is replaced by a flat chain.

Hugo Salgado-Hernández who remotely participated the meeting gave us a record presentation on “Distributed Threshold cryptography: a novel way to distribute keys and signing for DNSSEC”. He showed us how the threshold cryptography possibly works for DNSSEC purpose in which M (or more) out of N signer can guarantee the robustness of the system. The amazing part of this proposal is the aggregatable property of Keys and Signatures in which the signatures signed by multiple signers can combined into one signature fit DNSSEC purpose. And the public key used for validated can be aggregated by multiple public keys published by those signers.

Although there are more details should be explored in how to generate and distributed partial keys, it is definitely a promising path to our desirable fault-tolerant root. It was proposed by Hugo to test this threshold cryptography in Yeti DNS. Note that in Hugo’s proposal there is still a centralized roll called SD (Signing Dealer) in charge of distributing zone file and collecting & aggregating the signatures. Compared with the pure decentralized approach with blockchain and a certain consensus algorithm. Hugo’s presentation provide a practical approach but with limitations in decentralized feature.

Another session in the afternoon is about ECDSA and Algorithm rollover which is listed in current agenda of Yeti experiment. ECC(Elliptic Curve Cryptography) is widely considered as a promising DNSSEC algorithm after RSA due to its property: ECC has much smaller keys and signatures with equivalent or better key strength. There are some experience of algorithm rollover in second level domain and TLD level, but there is little experience for algorithm rollover in root level. Before proposed and tested in Yeti Root, Davey and Kevin built a lab testbed in BII lab which is introduce in a document in Yeti’s GitHub repo.

Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches proceeded successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK’s inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.

After all presentations and prepared topic, we have one hour open and wrap-up discussion. In the end of the meeting, a consensus was achieved among Yeti coordinator and Yeti participants that there are concrete and interesting items we are going to explore. We decided to move to Yeti phase-2 after 2019 after fully preparation with clear goal and a technical proposal document.

Special thanks for our local host Professor Akira Kato from Keio University providing the venue and recommending fancy restaurant.