Re: [Secdispatch] GNU Name System

["Schanzenbach, Martin" <[e-mail]>]

Hi Jon!

> On 24. Jul 2020, at 03:12, Jon Callas <[e-mail]> wrote:
> 
> 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.

Good point. I think I agree that the UX / Governance shouldn't be focussed too much in the protocol spec. I guess we anticipated questions regarding this point too much here.

> 
> * 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.
> 

Interesting point. I think this is worth discussing, though.

> * 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.
> 

I think it is important to put the protocol draft a bit into context. It currently not only serves as a proposal for an alternative/new
name system, but also as a documentation of our current implementation.
GNUnet's crypto has grown organically over time and parts are quite old. We have received this feedback regarding CFB before and
are already discussing a better alternative.

In general I agree that the draft proposes very concrete schemes "out of nowhere". We hope to address this by moving towards
more crypto agility. This means restructuring the draft a bit and formalising the requirements (of the crypto) better.

> * 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?)

This is likely also a result of the facts that it documents the current implementation and with it also some application use cases.
VPN is a specific application in GNUnet used to establish private tunnels between endpoints through the network.
It is always a question which (sub)set of already implemented record types to include in the document and which record types
to simply "register" at the type registry. This, however, would require to settle on the registry first. (a section which, coincidentally, nobody tripped over until now ;)

Alternatives and improvements to our revocation are welcome in any direction. In fact, we significantly reworked the revocation as part of the writing.
I guess we can agree that revocation should be addressed by the protocol (?) so we are happy to consider alternative ideas.
Of course, we can explain in more detail why we _currently_ use the PoW-based approach better.

> 
> * 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.

Well the last point is a reference to governance. Maybe it should be phrased in this context as well.

> 
> 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.

As a "pure" user, you are not required to manage any private keys. As a zone admin (which any end-user can be) you do. Protecting your keys is not in scope.
Think: key management in DNSSEC for zone admins. Pretty sure DNSSEC does not tell you _how_ to secure your keys.
"Rebuilding" a zone using a new key is similar to how you would do in DNSSEC. If the key of a zone is lost which is a "root" zone
for a user, the same applies (same as loosing DNSSEC key for a TLD).

> 
> 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."

This is also a point brought to us before. Of course, ideally we would have specified the DHT first, and then GNS.
Alas, our funding funds the GNS spec at this time.
The point we are trying to make is that the underlying stack (obviously) affects GNS's security properties.
Similar to how DNS vs "DNS over TLS" vs "DNS over HTTPS" have very different security properties.
Bad things can happen if you run DNS over UDP w/o TLS. Other bad things may happen with DNS over HTTPS. Depends on
the attacker model.
You also cannot expect to resolve the same names if you run DNS in a private internal network when compared to the Internet DNS.
(this partially brings us back to governance of course)


> 
> 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.

Well our primary objective is not to "push this into IETF" but to collect feedback on the protocol and the specification with technical experts outside of academia and GNUnet (which was the primary audience until now). I think I may have copied the email subject (from which that text is taken) from another email sent to this ML in the past.
It would be great if any existing WG finds this interesting and could imagine adopting it for improvement, of course.

Thank you for the detailed feedback! I did not get around to addressing all of this here, but it is very helpful and we will certainly update our draft using it!

Best
Martin


> 
> 	Jon
> 
>