> > But I'll do this only if asked. > > Consider it done. > Ok, here is a rough protocol sketch. For simplicity, I'll gloss over non-critical details, e.g. timeout handling. Bear with the notation, we'll end up with something neat at the end: - assume that R1 and R2 pick random numbers r1 and r2 which they keep private, and agree on random numbers v1 and v2. - they keep counters n1 and n2, starting at 0 - there is a global counter seqno, starting at 0 - they each have public/private key pair K_r1 and k_r1. - use h(s, n) to refer to a secure one-way hash chain, such that h(s,n) = sha(sha(sha(...sha(s)...))), where there are n sha() applications, note that knowing h(s, n) gives you no way to determine h(s, n-1), but knowing h(s,n-1), it is trivial to check that h(s,n)=sha(h(s,n-1) - In the beginning, R1 sends h(r1, N+1) to R2, and vice versa. - To register a name, R1 sends <seqno, name, ip> signed with k_r1 and blinded with h(r1, N-n1) to R2 - R2 signs and returns the packet, note that it cannot see what it just signed due to the blinding factor, and it cannot guess the blinding factor, - If R1 or R2 have a packet outstanding in the network, they toss one of the packets away (either theirs or their opponent's) to establish progress. which packet they throw away is determined by a random bit derived from v1 or v2, respectively. - Both R1 and R2 increment seqno when they hear from the other party - R1 reveals x=h(r1, N-n1), R2 checks to make sure that sha1(x) yields the previously revealed h(r1, N+1). - The blinding factor is removed to yield a packet, signed by both R1 and R2, with the desired name and binding. Voila, bindings now have signatures from _both_ parties, even though both are mutually suspicious, and no one gets to know what the other party is doing. R1 cannot deduce what name R2 is trying to register, and submit a fake "concurrent" request for the same name - it only gets to find the name out when the protocol concludes. It's pretty early in the morning here and I wrote this without consulting Bruce Schneier's excellent book, so it's likely to be in error :-), but you get the idea and there should be a more generic version of a similar protocol in there that is not in error. >I see > CoDoNS as having two parts, one is a very interesting system to > replace the DNS servers by a better P2P protocol (a part which is > certainly worth a RFC). The other is vague claims of being able to > replace the complete registry system. You're right, the second part is not something that is germane to the system. CoDoNS would do just fine without the multiple registrars per domain. In retrospect, we wanted to point out that a different kind of nameservice is possible with CoDoNS+DNSSEC. In reality, it is too tricky and too nuanced an idea to get across, and, as I said, we'd be happy if IANA just signed the single TLD delegations already. Best, Gun. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf