Re: [Secdispatch] GNU Name System

[Jon Callas <[e-mail]>]

I've also read through the GNS draft and have some comments:

* Like Michael Richardson, I have a great love for SDSI and love to see it used. I think there's a large discussion we should have about what the use cases can and should be. Alternate roots etc. are an issue, but I'm not sure it would be so bad to be able to say "ICANN's ietf.org" other than that it implies there could be someone else's "ietf.org" and that this is obviously problematic, particularly in how it would enable things like phishing. I take the opposite take on user experience. Protocol documents shouldn't be talking UX. Anyway, I think there's a discussion point as to whether this is a good idea. As much as I would like to be able to say "the media server I have at home" (for a number of reasons, not the least of which that that implies I'm not at home"), it's not clear this is really a good idea in the general case. My security auditor's mind is having a field day in thinking of cool (meaning confusing or malicious) ways to use this. Yet, I think it's a discussion point.

* If this gets put into a working group, I think it needs an IETF name for it, not GNS and not something that contains "GNU." Other standards have had their institutional links filed off; SSL became TLS, SSH became SECSH. Notably, OpenPGP did not, and I think that this was unfortunate. Despite all good intentions at the time, it's created confusion, and I say that as an RFC editor and as an implementer. There's nothing wrong with GNUnet's GNS being a reference implementation of <protocol>, and my advice to both the IETF and the GNS people, you'll be happier if you change the protocol name.

* There are a number of eccentric things in the protocol now. I don't mean that as a pejorative -- there are lots of eccentric things I like, SDSI, for example. I also like CFB mode as well as Twofish. Why, though, are they here? Are the design decisions leading to these? There's not a lot in the draft about these decisions. In general, it's better to stick to the well-trodden paths, to pick algorithms, modes, etc. that are in common use. In specific there are often reasons to do something on its own; I can see that a naming system might have reasons for going its own way. We just need a discussion of them. New code, new algorithms mean new bugs. If you can write about these decisions, "Most people do X, we are doing Y, because Z" that helps understand why the decisions are there. Some can be guessed -- CFB means no CBC padding, and no keying issues of a stream cipher like CTR mode. Tell us, though. I also really want to see what's going on and why with the record data encryption ini 4.3. 

* There are a number of other features in this that are interestingly eccentric, but leave me with a raised eyebrow. For example, a resource record for a VPN. That's interesting, but why? Zone revocation with proof-of-work -- why, as time and time again proof-of-work proves not to work? (I refer also to section 9.5 where you recommend pre-generating proofs of work. Where should these be stored, how should they be protected?) 

* The Security considerations need more work. 9.1 discusses the ECDSA decision, but not other crypto considerations. It refers us to the relevant papers without really saying more.  

9.2 points out that unrestricted Unicode names can lead to phishing, but says nothing more than, "zone administrators must take into account this attack vector and incorporate rules in order to mitigate it." That's not helpful. Or perhaps, 'this enables phishing, and it's your problem not ours, and we're not going to tell you what to do' is the actual security consideration. The second paragraph essentially says that protocol prevents taking down phishing site because authoritarian governments are bad. Um, okay.

9.3 is also pretty scary, a direct quote (and not my paraphrase) is: "Zone administrators, and for GNS this includes end-users, are required to responsibly and dilligently [sic] protect their cryptographic keys." That's a pretty big security consideration that everyone has to do their own key management and get it 100% right.

I do have a question -- what happens if the keys are lost? Does this mean the domain is essentially gone forever? I can't quite tell.

9.4 says that we need to pick the right DHT, if we pick the wrong one bad stuff will happen, and if we pick different ones interoperability is "unlikely."

I don't have further things to say about revocations, except that it's tetchy and brittle, by design.

All in all, the security considerations don't leave me thinking this is anything like a safe protocol.

* Despite all my comments above, I think that there's something interesting in the protocol and the issues can be fixed. Nonetheless, this is being positioned as an Informational RFC and I think that's a bad idea. This should either be standards track or continue to be off on its own and not part of the IETF.

The major risk is that this is an alternative to DNS that could lead to fragmentation of the most basic service on the Internet, naming. Yet it requires everyone to do key management perfectly and optimizes against easy management through proof of work and so on. I know I've done silly things managing my own DNS, and it seems that I'd be unhappily doing proof-of-work to undo every typo.

There are exciting ideas here. I believe that many of the issues I've brought up have relatively simple solutions. I also believe that it's no where near ready to deploy or standardize in the IETF. An informational RFC is not a good idea; this is too big and too experimental for that. While we in the IETF understand the difference, most people think and RFC is an RFC is an RFC is an RFC. The belief is that informational RFCs are standards. (Again, I am a sinner here, too. I have at times gotten tired of saying "informational" when someone incorrectly says "standard" and just let them go on.)

The agenda for Secdispatch says simply that this item is, "objective: find a home at IETF" which seems to be presupposing that the decision is not if it should be in some working group, but which one. I think it's premature for that. Much more work needs to be done.

	Jon