November 2023 - SSAC-Evo-Reso-WP

regrets for 30 november
by James Galvin Nov. 29, 2023

Nov. 29, 2023

I see a meeting on the SSAC calendar for tomorrow so I want to note my regrets as I will not be available. Thanks, Jim

2 1

RFC 9498: The GNU Name System
by Andrew McConachie Nov. 21, 2023

Nov. 21, 2023

Hot off the IETF press. RFC 9498: The GNU Name System <https://www.rfc-editor.org/info/rfc9498> --Andrew

1 0

Fwd: [Ext] Invitation to review SSAC's current work on the evolution of DNS resolution
by Andrew McConachie Nov. 20, 2023

Nov. 20, 2023

More feedback from Eric. > Begin forwarded message: > > From: Eric Osterweil <eoster(a)gmu.edu> > Subject: [Ext] Re: Invitation to review SSAC's current work on the evolution of DNS resolution > Date: 17 November 2023 at 22:24:43 CET > To: Lixia Zhang <lixia(a)cs.ucla.edu> > Cc: Rod Rasmussen <rod(a)rodrasmussen.com>, Andrew McConachie <andrew.mcconachie(a)icann.org> > > Hi all, > > I hope I’m not too little too late (I was counting on being able to get these thoughts to you today). :) > > I agree with Lixia’s comments, and I really liked the document, and I think it lays things out really well (kudos to the work party). Please feel free to take/leave/discard/reject/throw rocks at/etc. the below comments. I mean them only to be helpful, and I would be happy to chat with anyone if that would be helpful: > > + In the Executive Summary > - At the end of the first paragraph, I might suggest adding that the rest to DNS is software trying to decide locally which namespace to use for names. I think this is well covered in the rest of the SAC, but maybe worth spelling out here in the BLUF. > - In the second sentence of the second paragraph, I would suggest focusing the statement from “However, there is only one domain namespace…” to something like, “However, the Internet’s namespace inherently expects coherence…” (or some such). > > + In 2.1 Zooko’s Triangle > - The second para (bottom of page 9), I would suggest rephrasing the single point of trust of DNS. I (personally) don’t think it is the singular root, but the multi-stakeholder community that curates it. To that point, I think footnote 46 (on page 21) says it correctly, “there is no centralized authority for the global DNS.” > > + Section 4 > - On page 14, the top 2 paragraphs talk about difficulty registering a TLD, but I felt like this was not clearly motivated. Why does someone need to register a TLD instead of (say) an SLD, or 3LD, etc.? Below this is some discussion of censorship, but while I think that discussion has merit, I am not sure it cleanly tracks jumping to getting a TLD. That is not possible, for example, in ENS either (yet). > - Lower on page 14, at the end of the paragraph that starts with “While such evolutionary pressures…” the final sentence talks about resistance to change. I would suggest it is missing one fundamental angle, that I would suggest should be added: s/commencerate with the size of the installed base/commencerate with the size and functional necessity of the installed base/ > - In the next paragraph (which starts with “This stasis of the installed base…”), I would suggest adding the following text at the end of the final sentence, “, and likely would require explicit value propositions, and rigorous impact evaluations, to avoid SSR concerns for the Internet.” (Or something like that). > - Similarly, in the next paragraph (which starts with “Innovation requires differentiation…”), I would suggest adding the following text at the end of the final sentence, “, and if a coexistence/transition strategy is not well constructed, wide scale Internet instability might be at risk.” (Or some such). > - In the final paragraph of the Section (2nd paragraph on the top of page 15, before Section 4.1), I might suggest adding one more sentence. Something like, “What can be forecasted, and has tended to help, is conscientious measurement, monitoring, and evaluation of network systems to form data-driven views into systems and proposals.” > > + In Section 5.2 > - In the 2nd paragraph, there is mention that Tor comes with a modified Firefox browser. In addition, the Brave browser supports Tor natively out of the box. I might suggest just including that fact by modifying the second sentence: s/Firefox browser that seamlessly/Firefox browser and the Brave browser has built in support. These both seamlessly/ > > > + In Section 5.3 > - On page 19, in the paragraph that starts with “Because ENS is implemented in smart contracts…”, I believe there is an error. I believe the root of ENS is governed by a DAO, and the 7 party multisig contract is only used for delegation of TLDs. I believe the DAO governs pricing and all other aspects of the root (aside from TLD delegation). > - Also, in the paragraph below the above, I think the comment about names being lost forever may not be correct. As far as I know, ENS requires names to be registered and renewed. I think (but am not sure) that this means they are recoverable (if for no other reason than the registration elapses). > - Also, it may be noteworthy in this paragraph (I defer) that ERC-1185 let’s ENS users claim DNS names to host resolution content “authoritatively” in ENS rather than DNS, and uses DNSSEC to verify the claiming process. Happy to help craft a coherent comment on this if anyone would like. > > + Section 7.1 > - The paragraph that starts with “Wb browsers have adapted to be more user firendly…” (on page 24) I felt it might be helpful to balance some of the comments. For example, I (personally) feel that the situations described by the text have led to reduced verifiability as users try to navigate the web. They don’t have as much to look at before deciding to trust. > - On page 25, after reading the paragraph that starts with, “End users are seeing fewer domain names…”, I was wondering if the point of domain names is for users to see, or to provide verifiability of Internet names to resources? I personally feel the latter, and as I read further in the SAC I think this may be part of what it tries to convey too. If so, I think perhaps this point should be said more towards the beginning so that the document is more inductive. Happy to chat if that would be at all helpful. > > + Section 8 > - After the first paragraph (on page 28), I had the thought that the original name resolution (back in the day) was hosts.txt, which was sync’ed from (iirc) ISI (i.e., globally consistent, but centralized). > >> On Nov 17, 2023, at 8:33 AM, Lixia Zhang <lixia(a)cs.ucla.edu> wrote: >> >> Hi Rod, >> >> Thanks for your quick ACK! I just glanced over my quick comments from late Wed (trying to get a partial credit within the deadline:), it seems a number of places could benefit from a bit clarification to avoid potential misunderstanding (e.g. QR code: I didnt mean it doesn't lead to new concern, just that it changed the problem). >> Will try to clarify in my next (hopefully better organized) feedback writeup, also add my reason of why I dont believe Zooko triangle = truth. >> >> best, Lixia >> >>> On Nov 16, 2023, at 2:25 AM, Rod Rasmussen <rod(a)rodrasmussen.com <mailto:rod@rodrasmussen.com>> wrote: >>> >>> Thanks very much for taking the time to give this a review Lixia! >>> >>> I have forwarded your feedback on to the SSAC work party that has produced this work and will happily pass along any further input you find time to provide. Also, thank you for your very generous offer to have a conversation about the document with our work party. I’ have passed that along as well. We’ll be sure to let you know if they would like to arrange something with you. >>> >>> Cheers, >>> >>> Rod >>> >>>> On Nov 15, 2023, at 10:09 PM, Lixia Zhang <lixia(a)cs.ucla.edu> wrote: >>>> >>>> Hi Rod and others, >>>> >>>> When I received this draft report, Nov 17 looked very far away, now just noticed that this review deadline is coming in 2 days! >>>> >>>> I did read the report on the long flight back after Prague IETF, but yet to find time to put my thought in a structured way. I'm hosting the NDN project team retreat at UCLA for next 2 days. So let me do a quick compromise to partially meet Nov 17th deadline: >>>> - I'm putting down a quick short partial list of bullets below (if just to show I read the draft:) >>>> - I'll find time over weekend to build a full list of my points, hopefully in a better structured way, and hopefully together with more specific comments to the pdf. >>>> >>>> Now a quick, short, partial list of points (personal opinion, take with a big grain of salt) >>>> >>>> 1/ the importance of name uniqueness: I feel this (most) important property of names could be emphasized a lot more than what's in the current draft. >>>> Apps would not work correctly without unique names (at least unique within the usage scope of a name). >>>> Most importantly, certificates are issued to names, i.e. Internet's security relies on unique names (maybe this point could be added to the draft) >>>> >>>> 2/ It seems to me important to separate out the concepts of namespace governance from name resolution. >>>> DNS first defined a namespace, then how to allocate names on this space, and then provided its resolution system. >>>> >>>> To assure name uniqueness, one either has a well defined *coordination* process to assure unique allocations, like the DNS system--it is not so much "centralized", but namespace governance by a democratic coordination process; otherwise one needs solutions for collision avoidance/detection/mitigation, a lot more difficult problems in global scale. >>>> >>>> 3/ Those "decentralization" name systems replaced coordinated allocation with either centralized control (e.g. ENS 7 people controlling ENS TLD allocations), or "consensus"-- it is consensus in quote, because those anonymous systems vote by resources (proof of work/stake/space), they hide not only who are voting, but more importantly there is no way to determine how many people are voting, a rich person can pretend to be 10, or 100. >>>> >>>> 4/ Somewhere mid of the draft talked about some people want to change the governance of the DNS (really DNS namespace governance) to different name governance structures. I think we could add here how those different name governance structures do, or do not, assure name uniqueness. >>>> Without coordinated allocations to assure uniqueness, these system need name collision detection solutions, and collision mitigation procedures. As Nick Weaver's report pointed out, none of them offers collision mitigation. >>>> >>>> 5/ The executive summary mentioned that the alternative name systems copy DNS syntax, with a primary reason of benefiting from existing software: I feel a big reason here is that DNS names are semantically meaningful, that's why people/apps use them (Zooko triangle called "human memorable", memorable because they are meaningful) >>>> BTW I dont buy Zooko triangle as the truth; wikipedia also lists a few counter examples https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe… [en.wikipedia.org] <https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Zooko*27s_triangl…> >>>> >>>> 6/ The summary also mentioned "New technologies such as QR codes and URL shorteners offer great utility to Internet users while also obscuring the underlying domain names used and creating new opportunities for bad behavior." >>>> I need to think more about this: at IETF meetings (other cases may be similar), people use the QR code because they trust the QR code providers, so the trust on DNS name (now they can't see) is moved to trust the offers of QR code. One would not scan a QR code given by a total stranger, right? >>>> >>>> That's for now, will try to finish before Monday (2 days over your deadline:) >>>> I also feel a conversation might be more effective than email. >>>> >>>> Lixia >>>> >>>>> On Oct 25, 2023, at 3:08 AM, Rod Rasmussen <rod(a)rodrasmussen.com> wrote: >>>>> >>>>> Dear Lixia and Eric, >>>>> >>>>> Thanks again for your presentation to the SSAC. As we mentioned during the question period, the SSAC has been developing a report on the Evolution of DNS Resolution. The report includes discussion of ENS and other alternative naming systems. >>>>> >>>>> The document is currently in review and we would appreciate any feedback you might have. >>>>> >>>>> Since we are nearing the publication date, if you do have any feedback or comments please get them to us by 17 November 2023. >>>>> >>>>> Best Regards, >>>>> Rod Rasmussen >>>>> SSAC Chair >>>>> >>>>> <SSAC DRAFT Report on Evolution of Internet Name Resolution Oct 24.pdf> >

1 0

Fwd: Invitation to review SSAC's current work on the evolution of DNS resolution
by Rod Rasmussen Nov. 17, 2023

Nov. 17, 2023

A follow-up from Lixia. Sounds like she’ll have a much more thought-out response shortly. > Begin forwarded message: > > From: Lixia Zhang <lixia(a)cs.ucla.edu> > Subject: Re: Invitation to review SSAC's current work on the evolution of DNS resolution > Date: November 17, 2023 at 5:33:25 AM PST > To: Rod Rasmussen <rod(a)rodrasmussen.com> > Cc: Eric Osterweil <eoster(a)gmu.edu>, Andrew McConachie <andrew.mcconachie(a)icann.org> > > Hi Rod, > > Thanks for your quick ACK! I just glanced over my quick comments from late Wed (trying to get a partial credit within the deadline:), it seems a number of places could benefit from a bit clarification to avoid potential misunderstanding (e.g. QR code: I didnt mean it doesn't lead to new concern, just that it changed the problem). > Will try to clarify in my next (hopefully better organized) feedback writeup, also add my reason of why I dont believe Zooko triangle = truth. > > best, Lixia

1 0

Fwd: Invitation to review SSAC's current work on the evolution of DNS resolution
by Rod Rasmussen Nov. 16, 2023

Nov. 16, 2023

Some input on the report from Lixia, with a promise of some more by early next week. I leave this to the WP leadership to determine how to incorporate, but I will thank her for taking the time to respond. She also suggested a conversation that might prove to be an interesting conversation, but isn’t required for us to finish this work. Cheers, Rod > Begin forwarded message: > > From: Lixia Zhang <lixia(a)cs.ucla.edu> > Subject: Re: Invitation to review SSAC's current work on the evolution of DNS resolution > Date: November 15, 2023 at 10:09:47 PM PST > To: Rod Rasmussen <rod(a)rodrasmussen.com> > Cc: Eric Osterweil <eoster(a)gmu.edu>, Andrew McConachie <andrew.mcconachie(a)icann.org> > > Hi Rod and others, > > When I received this draft report, Nov 17 looked very far away, now just noticed that this review deadline is coming in 2 days! > > I did read the report on the long flight back after Prague IETF, but yet to find time to put my thought in a structured way. I'm hosting the NDN project team retreat at UCLA for next 2 days. So let me do a quick compromise to partially meet Nov 17th deadline: > - I'm putting down a quick short partial list of bullets below (if just to show I read the draft:) > - I'll find time over weekend to build a full list of my points, hopefully in a better structured way, and hopefully together with more specific comments to the pdf. > > Now a quick, short, partial list of points (personal opinion, take with a big grain of salt) > > 1/ the importance of name uniqueness: I feel this (most) important property of names could be emphasized a lot more than what's in the current draft. > Apps would not work correctly without unique names (at least unique within the usage scope of a name). > Most importantly, certificates are issued to names, i.e. Internet's security relies on unique names (maybe this point could be added to the draft) > > 2/ It seems to me important to separate out the concepts of namespace governance from name resolution. > DNS first defined a namespace, then how to allocate names on this space, and then provided its resolution system. > > To assure name uniqueness, one either has a well defined *coordination* process to assure unique allocations, like the DNS system--it is not so much "centralized", but namespace governance by a democratic coordination process; otherwise one needs solutions for collision avoidance/detection/mitigation, a lot more difficult problems in global scale. > > 3/ Those "decentralization" name systems replaced coordinated allocation with either centralized control (e.g. ENS 7 people controlling ENS TLD allocations), or "consensus"-- it is consensus in quote, because those anonymous systems vote by resources (proof of work/stake/space), they hide not only who are voting, but more importantly there is no way to determine how many people are voting, a rich person can pretend to be 10, or 100. > > 4/ Somewhere mid of the draft talked about some people want to change the governance of the DNS (really DNS namespace governance) to different name governance structures. I think we could add here how those different name governance structures do, or do not, assure name uniqueness. > Without coordinated allocations to assure uniqueness, these system need name collision detection solutions, and collision mitigation procedures. As Nick Weaver's report pointed out, none of them offers collision mitigation. > > 5/ The executive summary mentioned that the alternative name systems copy DNS syntax, with a primary reason of benefiting from existing software: I feel a big reason here is that DNS names are semantically meaningful, that's why people/apps use them (Zooko triangle called "human memorable", memorable because they are meaningful) > BTW I dont buy Zooko triangle as the truth; wikipedia also lists a few counter examples https://en.wikipedia.org/wiki/Zooko%27s_triangle > > 6/ The summary also mentioned "New technologies such as QR codes and URL shorteners offer great utility to Internet users while also obscuring the underlying domain names used and creating new opportunities for bad behavior." > I need to think more about this: at IETF meetings (other cases may be similar), people use the QR code because they trust the QR code providers, so the trust on DNS name (now they can't see) is moved to trust the offers of QR code. One would not scan a QR code given by a total stranger, right? > > That's for now, will try to finish before Monday (2 days over your deadline:) > I also feel a conversation might be more effective than email. > > Lixia

3 2