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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf