Re: [Din] Draft / Specification of the GNU Name System

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

> On 19. Mar 2021, at 14:44, Schanzenbach, Martin <[e-mail]> wrote:
> 
> Signed PGP part
> Hi Roland,
> 
>> On 19. Mar 2021, at 14:11, Bless, Roland (TM) <[e-mail]> wrote:
>> 
>> Hi Martin,
>> 
>> see inline...
>> 
>> On 19.03.21 at 13:15 Schanzenbach, Martin wrote:
>>> Hi Roland!
>>> 
>>>> On 19. Mar 2021, at 12:34, Bless, Roland (TM) <[e-mail]> wrote:
>>>> 
>>>> Hi Martin,
>>>> 
>>>> I'm somewhat confused. DINRG is a _research_ group of the IRTF, so
>>>> it's not about standardization in the first place, whereas secdispatch
>>>> is an IETF activity. So the question is what you want to achieve in the end: Discussion of the general approach for further input on the concept
>>>> or just a documentation what you did?
>>> I would like to refer you to our original email(s) (actually the OP of this thread) for an answer to this question.
>>> There is a pretty concise description of our goals, where we are coming from and why we
>>> sent a message here.
>> 
>> Thanks for the reference, I think that this still doesn't answer my question. I find that
>> your approach is quite nicely fitting into the DINRG agenda, especially if there are open research
>> questions left. If this concrete proposal can be converted into an RG draft is another question.
>> However, if your ultimate goal is to get an IETF standards track RFC,
>> you need an IETF WG that is willing to work on this.
> 
> I think now I understand. From the secdispatch meeting (https://codimd.ietf.org/notes-ietf-108-secdispatch#)
> we interpreted the consensus to be that we should talk to DINRG and ask for it be an active draft here.
> It also sounded a lot like the consensus is that DINRG would be a fit.
> From that session it felt like it was less our "choice" on where we want it but more contingent on DINRG
> deciding if it thinks it would "take" it based on interest and charter fit.
> But I invite you to skim the minutes maybe we misinterpreted the outcome.
> 
> Otherwise I guess the concrete question would be if DINRG would adopt it and possibly even continue the
> work here with us wrt improvements and the DHT, for example.
> 
>> 
>>> The reason why I mentioned secdispatch is that if you (the RG) do not consider this draft to be relevant, then I thought
>>> we may have to go for another round through secdispatch to find an IETF WG or BoF or etc.
>>> 
>>> Please also note that for some aspects of the protocol (specifically the key derivations) there
>>> are still open research questions as well with respect to our drafted Ed25519 support (and the security of it)
>>> and a missing PQ-secure derivation.
>>> 
>>>> If you are interested in getting this standardized, my impression is
>>>> that you should get input from IETF DNSOPS people whether your approach
>>>> is able to satisfy the most important operational characteristics as DNS replacement.
>>>> 
>>> We have had discussions with DNSOPS before, too. But we are coming from secdispatch and
>>> were referred here (again see the mail below).
>>> Working on a "decentralized internet infrastructure" sums up our goals pretty well.
>>> Our draft discusses the aspect of naming.
>>> 
>>> If you think we are misinterpreting the goals of this WG and the overlap with the draft,
>>> clarification would be helpful.
>> Nope, however, it's an RG not a WG and that's a difference.
>>> 
>>>> Furthermore, if you want to go for standardization, the whole underlying DHT specification is missing and I'm not sure that your model is
>>>> compatible with RELOAD (https://tools.ietf.org/html/rfc6940). One
>>>> needs to also check that and probably come up with a
>>>> corresponding modification of RELOAD or a completely new DHT proposal.
>>>> 
>>> Such discussions would be highly valuable.
>>> This draft is the result of funding and was limited to GNS [1], but we are very open (actually planning) to also specify the DHT we currently use.
>>> That being said, we believe our approach is deliberately incompatible with RELOAD, as RELOAD conflicts with the IAB report's requirement for *decentralization*. Quoting the RELOAD RFC:
>>> 
>>> Security Framework:  A P2P network will often be established among a
>>>      set of peers that do not trust each other.  RELOAD leverages a
>>>      central enrollment server to provide credentials for each peer,
>>>      which can then be used to authenticate each operation.  This
>>>      greatly reduces the possible attack surface.
>>> <<<<
>>> 
>>> In other words, RELOAD has centralization built into their P2P network, which is exactly what IAB and us want to avoid.
>>> Not to mention arguably outdated protocols.
>> 
>> Not quite. RELOAD also supports a fully decentralized mode
>> that uses self-signed certificates and doesn't require a central
>> enrollment server. However, in your completely
>> decentralized system you also need to answer questions
>> w.r.t. to resistance against sybil attacks, eclipse attacks and so on.
> 
> I see, interesting. We should probably look at it im more detail then.
> However, I think given that each project seems to be implementing its own
> p2p network (blockchains and storages like IPFS included) which is not RELOAD the issue seems to be
> the lack of a common infrastructure / overlay which would be beneficial and applicable to all of them,
> including GNS. Again, not really in scope of the draft but relevant and there is some overlap.
> 

Looking at the RELOAD draft a bit further it sais:

"
RELOAD's security model is based on each node having one or more
   public key certificates.  In general, these certificates will be
   assigned by a central server, which also assigns Node-IDs, although
   self-signed certificates can be used in closed networks.
"

So RELOAD does not exactly permit an *open* and *decentralized* network.
This would not fit the bill for the requirements of GNS (maybe a point to make clearer in the respective section).
RELOAD also has some other misfeatures, like requiring a peer that stores data to sign storage permissions with its certified key. While this solves the hypothetical issue of limited storage (in practice, the limiting factor is usually bandwidth or disk IO, or even CPU time for cryptographic operations -- but not storage capacity), it destroys desirable properties like unlinkability. GNS would like nodes to not be able to selectively censor records based on which zone they originate from. By forcing records to come with a certified unblinded signature from the originator, censorship is again trivial.

In our GNUnet implementation of GNS the underlying DHT ist R5N.
The R5N answer for sybil/eclipse attacks is randomization and replication as well as pluggable content verification. While in RELOAD basically anything is pluggable (overlay, transport), the specification does not permit pluggable content verification.


>> 
>>> Hence we see the need for a consolidated p2p routing layer for any decentralized service, naming or otherwise.
>>> And we would be happy to work within DINRG on such an approach as well. But it is not the focus of the draft.
>>> It also should not be in the draft because if GNS would propose its own DHT/routing, it would be detrimental
>>> to the efforts of decentralizing services due to the fragmentation of that layer.
>> I think that splitting this up is the right approach, however, there may exist some subtle
>> interdependencies. Therefore, defining requirements for the underlying
>> DHT may be in scope of the draft (section 11.4 reads as if it wants to discuss
>> implications in the other direction).
> 
> Agreed. This section should handle such considerations, we will try to work on this part more.
> This section would then naturally lead to references to possible DHT suitable implementations.
> 
> BR
> Martin
> 
>> 
>> Regards,
>> Roland
>> 
>>>> On 19.03.21 at 11:29 Schanzenbach, Martin wrote:
>>>>> Dear DINRG,
>>>>> this WG seems inactive and consequently we are kind of in limbo at the moment.
>>>>> Considering that a recent IAB report basically screams decentralization and
>>>>> specifically mentions naming [1], we are convinced our draft is still very much relevant,
>>>>> and such topics are discussed at IETF.
>>>>> We would like to improve upon the draft and get into more
>>>>> discussions with interested experts, but we get the feeling this may not be the
>>>>> correct WG where this is discussed?
>>>>> As written before we still believe that given the charter of DINRG
>>>>> this should be the right place for our topic.
>>>>> If there were other discussions happening on this list we would have inferred that
>>>>> there is no interest in the draft, but the only response on this ML is the mail from
>>>>> Dirk indicating interest in it.
>>>>> We are not sure how to proceed.
>>>>> Will there be a meeting this year? Would this draft be the only topic?
>>>>> Are you waiting for additional topics to come up?
>>>>> If there is no technical feedback to be had for us within this WG, organizational
>>>>> pointers on how to proceed would be welcome.
>>>>> Should we go back to secdispatch?
>>>>> Should we move into independent stream?
>>>>> Best
>>>>> Martin
>>>>> [1] https://www.rfc-editor.org/rfc/rfc8980.html#name-centralized-deployment-mode
>>>>>> On 24. Jan 2021, at 10:49, Schanzenbach, Martin <[e-mail]> wrote:
>>>>>> 
>>>>>> Signed PGP part
>>>>>> Hi Dirk,
>>>>>> 
>>>>>> just wanting to touch base if there will be a DINRG meeting at the next IETF?
>>>>>> We have continued working on the draft and there have further been efforts to more cleanly specify the set reconciliation for zone revocation in a general fashion here [1].
>>>>>> 
>>>>>> Of course we are still available and interested in presenting/discussing the GNS draft at DINRG.
>>>>>> 
>>>>>> Best
>>>>>> Martin
>>>>>> 
>>>>>> [1] https://www.ietf.org/archive/id/draft-summermatter-set-union-00.txt
>>>>>> 
>>>>>>> On 8. Dec 2020, at 21:01, Dirk Kutscher <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Martin,
>>>>>>> 
>>>>>>>> we wanted to check back with you if it makes sense to coordinate next
>>>>>>>> week at IETF 109. It seems as if dinrg is not (yet) listed on the
>>>>>>>> agenda?
>>>>>>>> 
>>>>>>>> According to the minutes of IETF 108, the next steps would involve
>>>>>>>> coordination/deconflicting with DINRG:
>>>>>>>> https://codimd.ietf.org/notes-ietf-108-secdispatch#
>>>>>>> thanks for bringing this up and apologies for the late reply.
>>>>>>> 
>>>>>>> We didn't meet around IETF-109.
>>>>>>> 
>>>>>>> This is definitely an interesting topic for DINRG, and we should talk about it at an upcoming meetings.
>>>>>>> 
>>>>>>> We are currently planning upcoming meetings etc., and we should have a more concrete plan for early 2021 activities after new year.
>>>>>>> 
>>>>>>> In the meantime, please feel free to use the mailing list as well.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Dirk
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Best Regards
>>>>>>>> Martin
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sun, 2020-10-18 at 15:13 +0200, Schanzenbach, Martin wrote:
>>>>>>>>> Dear DINRG,
>>>>>>>>> 
>>>>>>>>> at IETF 104, we have presented to you our work on the GNU Name System
>>>>>>>>> [1].
>>>>>>>>> Since then, we have been working on improvements and a technical
>>>>>>>>> specification of the system [2].
>>>>>>>>> At IETF 108, we appeared at secdispatch in order to discuss if the
>>>>>>>>> draft may fit into any existing WG in IETF (or IRTF) [3].
>>>>>>>>> We were encouraged to ask DINRG if it would be interested in this
>>>>>>>>> work and continue improving and working on it (see minutes of
>>>>>>>>> secdispatch). Your charter would certainly support the general theme
>>>>>>>>> of the protocol: "The evolution of distributed ledger technologies
>>>>>>>>> and the platforms that leverage them has given rise to the
>>>>>>>>> development of decentralized communication and infrastructure
>>>>>>>>> systems, and experiments with the same. Some examples include name
>>>>>>>>> resolution (Namecoin, Ethereum Name Service), identity management
>>>>>>>>> (OneName), distributed storage (IPFS, MaidSafe), distributed
>>>>>>>>> applications, or DApps (Blockstack), and IP address allocation and
>>>>>>>>> delegation."
>>>>>>>>> 
>>>>>>>>> Since our appearance at secdispatch, we have received a lot of
>>>>>>>>> feedback from the community and experts. We have taken the time to
>>>>>>>>> incorporate the feedback and the result is in the current version of
>>>>>>>>> the draft as well as our implementation.
>>>>>>>>> As you can see, the draft versions 01 and 02 differ significantly.
>>>>>>>>> The two major changes regarding the protocol that we have made are:
>>>>>>>>> 
>>>>>>>>> 1. Improve crypto agility: Allow other zone key types and key
>>>>>>>>> derivation schemes and define the required properties.
>>>>>>>>> 2. Improve crypto implementation: The used symmetric encryption
>>>>>>>>> scheme has been replaced to be more resilient to IND-CCA
>>>>>>>>> 
>>>>>>>>> For (1.) we have drafted an alternative scheme based on Schnorr
>>>>>>>>> signatures. This instantiation is still a draft and not implemented.
>>>>>>>>> Any feedback here is specifically welcomed and helpful.
>>>>>>>>> 
>>>>>>>>> Finally, we would be happy to appear at the next IETF and discuss
>>>>>>>>> whether DINRG would be a place to continue our work with you.
>>>>>>>>> 
>>>>>>>>> Best
>>>>>>>>> Martin
>>>>>>>>> 
>>>>>>>>> [1]
>>>>>>>>> https://www.ietf.org/proceedings/104/slides/slides-104-dinrg-gnu-name-system-00.pdf
>>>>>>>>> [2] https://datatracker.ietf.org/doc/draft-schanzen-gns/
>>>>>>>>> [3]
>>>>>>>>> https://www.ietf.org/proceedings/108/agenda/agenda-108-secdispatch-02
>> 
>> 
>> _______________________________________________
>> Din mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/din