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

["Bless, Roland (TM)" <[e-mail]>]

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.

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

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

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