Re: [Secdispatch] GNU Name System

[Chelsea Komlo <[e-mail]>]

I looked over the GNS draft and have a few comments regarding how the terms
"censorship resistance" and "privacy-preserving" are used in the draft.

The draft says that "This specification describes a censorship-resistant,
privacy-preserving and decentralized name system: The GNU Name System
(GNS)." The term "censorship-resistance" here refers to the ability for the
system to resist removal of domain names by someone that does not directly
control the domain.

However, this definition of censorship resistance is in fact quite limited,
and doesn't consider other factors like namesquatting, doppelgangers, and
other variations of abuse that prevent use of the system. While some of
these considerations may be outside the scope of this draft, identifying
and describing the implications of these assumptions is important to ensure
the system is viable in practice (Section 9.2 currently just says that zone
administrators must take abuse into account and develop rules to mitigate
it).

Further, this draft implicitly assumes that users have access to some
censorship-resistant channel (such as Tor) in order to perform lookups.
For example, this system will likely be blocked in countries that also can
successfully block Tor (such as China without the use of bridges). This
draft should clearly specify the assumption that users have access to some
censorship-resistant channel.

Finally, the draft should explicitly define what "privacy-enhancing" means
in the description that "GNS provides a privacy-enhancing alternative to
the Domain Name System (DNS)"; i.e, whose privacy is being enhanced, and
under what circumstances. The draft describes how user lookups are
performed over resource record blocks, which hides a user's lookup within a
single block (which seem to contain multiple domains?), but of course the
privacy guarantees of this approach are much weaker than systems that
provide a single anonymity set for lookups.

Chelsea

On Thu, Jul 23, 2020 at 7:12 PM 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.
>
> * 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
>
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>


-- 
Chelsea H. Komlo | chelseakomlo.com