Subject: [Secdispatch] GNU Name System

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 17:56:54 -0400

Hi, I read through draft-schanzen-gns just now.
First, I generally like the idea.
I particularly like the reference to pet names and SDSI.

The SDSI work *not* been paid attention to enough, so I'm glad that this
document goes with it.
I'm perfectly fine with having to say "ICANN's ietf.org" as a petname for a
DNS rooted in ICANN's DNSSEC root.  Some may find that this may be
a stepping stone towards multiple roots, but I see it differently, because it
enable's stuff like "Michael's Neighbour's Work-Server"
{I didn't get to a part where the presentation of this was discussed,
and how I'd type this into a Location box}

The document is a bit rough, and could definitely benefit from more
implementer feedback, but that's of course, why you are here :-)

There are probably some algorithm agility issues, but I suspect that they
aren't worse that for ICANN DNSSEC, because the decision to change algorithm
types can be a partially local decision.

DHT just sort of pops up in the section 3 description.
And then it isn't until section 6 that we learn that there is a DHT.
I thought I'd learn more in section 8, but I didn't.
And then section 9.4 says it's out of scope?
I didn't quite figure out how it was used at all actually.
Since all names are local... wouldn't I always know how to find my
relationships?

I see that GNUnet is being funded by nlnet and NGI, and this is rather good.
I don't see a clear connection to FSF, and I wonder if they will be happy
about the naming.  I.e. do you have RMS' blessing here?
Better to get the name right early.

If this work is worth doing at the IETF, it probably needs it's own WG.
There are some RGs that deal with far more distributed networking than the
IETF has been interested in yet, so maybe that's a route.

How would it get deploy as other than a niche effort of geeks?
Do you think that it will be possible to build a GNS Service for Android, or
for iOS?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Grothoff <[email-masked]>
Date: Wed, 22 Jul 2020 00:06:57 +0200

Hi! First of all, thanks for reading the draft!

> implementer feedback, but that's of course, why you are here :-)

Indeed.

> types can be a partially local decision.

This is actually an area where we already had some feedback via other
channels and are planning on
1) fixing some agility issues, and
2) improving the explanation and write-up to make it
   easier to see how agility can be achieved *and*
   actually give a 2nd instantiation.

Alas, this will require significant changes to the draft and
implementation(s).

> And then it isn't until section 6 that we learn that there is a DHT.

Yes, we were already told to improve this part of the write-up. We'll
try, specific suggestions welcome.

> And then section 9.4 says it's out of scope?

The exact specification, yes. It's way too much for one draft to include
it IMO -- not to mention that GNS can be instantiated over virtually any
DHT.

> Since all names are local... wouldn't I always know how to find my

Suppose you have alice.bob.dave.carol.  You must have 'carol' locally,
but you would (typically) lookup 'dave' in carol's namespace in the DHT
already. Basically, the root is local, but the rest is resolved via the DHT.

> Better to get the name right early.

We do indeed have RMS's blessing.

> IETF has been interested in yet, so maybe that's a route.

Well, we hope to find out what the best home at IETF would be.

> How would it get deploy as other than a niche effort of geeks?

Our plan is to initially integrate it with applications that are
underserved by DNS, like decentralized communication platforms / social
networking applications, identity management (see reclaim:ID) and IoT
applications.

> Do you think that it will be possible to build a GNS Service for Android, or

For Google and Apple, certainly ;-).  And Apps could certainly link in a
GNS stack for name resolution bypassing the OS resolver entirely if desired.

---

From: Jon Callas <[email-masked]>
Date: Thu, 23 Jul 2020 18:12:14 -0700

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

---

From: Chelsea Komlo <[email-masked]>
Date: Thu, 23 Jul 2020 20:59:57 -0600

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 <[email-masked]> wrote:

> * 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."
>
> * 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

-- 
Chelsea H. Komlo | chelseakomlo.com

---

From: Russ Housley <[email-masked]>
Date: Fri, 24 Jul 2020 09:34:47 -0400

> * 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 Twof…

These days, I ask why an AEAD is not being used.

Russ

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Jul 2020 13:02:40 -0700

> On Jul 24, 2020, at 6:34 AM, Russ Housley <[email-masked]> wrote:
> 
> Jon:
> 

That's why I framed it in terms of CBC or CTR. 

	Jon

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Sat, 25 Jul 2020 15:09:21 +0200

Hi Jon!

> On 24. Jul 2020, at 03:12, Jon Callas <[email-masked]> wrote:
> 

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 becam…

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 Twof…

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 revo…

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.

> 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 mit…

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

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

> 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 o…

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

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 30 Jul 2020 09:24:21 +0000

Hi Jon,

Just to touch on the last part of your mail, the objective stated in the agenda (which I drafted): that is meant to be the objective that presenters shared with us chairs, to start  the dispatching discussion on what their preferred output would be, if they come with a proposal. By no mean that presupposes the decision that the draft is to be in the IETF. 

Thank you for your feedback, and especially for the one to the point of the potential track and dispatching question. 
Francesca

On 24/07/2020, 03:12, "Secdispatch on behalf of Jon Callas" <[email-masked] on behalf of [email-masked]> wrote:

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

    	Jon