- SSAC-Evo-Reso-WP - lists.icann.org

will be late today: 14 december
by James Galvin Dec. 15, 2023

Dec. 15, 2023

Unfortunately, I have a conflict for the first 30 minutes of today’s meeting. If the meeting runs “short” please note my regrets, otherwise I’ll see at half past the hour. Jim

6 11

A significant comment on "Courtesy Preview: SSAC Report on the Evolution of Internet Name Resolution"
by Barry Leiba Dec. 14, 2023

Dec. 14, 2023

We sent the evo-reso report to OCTO and got a quick response from Paul Hoffman, which we, the work party, need to consider: > Greetings agian. Matt passed the preview to OCTO, and I read it > through. It is comprehensive and useful, but I am very concerned > about Recommendation 2: "The SSAC recommends that the ICANN > organization continue to encourage collaboration and facilitate > coordination among the various namespace communities." Please > consider passing my concerns on to SSAC. > > --Paul > > To the best of my knowledge ICANN org has *never* encouraged > collaboration or facilitated coordination "among the various > namespace communities". Nothing in the body of the document > (that I could find) talks about ICANN org doing this, which is > good: we shouldn't be doing it. As far as I know, ICANN org is > not working with any of the systems listed in Section 5, not > even mDNS. From Section 9, SAC113 and RFC 9476 will not help > with collaboration or coordination at all: they will give two > unmanaged namespaces where there is likely to be collisions at > the second level. > > OCTO sponsoring the Emerging Identifier Technologies panels is > about exposing the ICANN community to the identifiers, not to > encourage collaboration or facilitate coordination. The outcome > of each one of these has been education of the community and no > follow-up with the representatives of the identifiers. Education > is not collaboration or coordination. > > If SSAC wants to recommend that ICANN org *start* "to encourage > collaboration and facilitate coordination among the various > namespace communities", it would be useful for this document to > say how we might do that and what the harmsand benefits might > be. Given that you want to publish the document in the next few > weeks, it would likely be better to simply remove this > recommendation from the current document and start new work > talking about possible work to encourage collaboration and > facilitate coordination. (To be clear, I'm quite skeptical that > such work would have more benefit than harm, but SSAC might have > a different opinion.) Now, we did discuss this at length, and I believe it was the referenced EIT panels that we were talking about. Paul is very clear that those panels were *not* meant to be any sort of forum for collaboration, and were *only* to inform the community. Given his comment on this, I agree that we should reconsider recommendation 2, with, as I see it, two likely outcomes: 1. We simply remove the recommendation. 2. We change the wording to refer more directly to the Emerging Identifier Technologies panels, and say something like, "The SSAC recommends that the ICANN organization continue to keep the ICANN community abreast of new developments through such means as the Emerging Identifier Technologies panels that have been presented at a number of ICANN meetings." If we choose path 2, we need to consider whether it's a separate recommendation or gets subsumed into recommendation 1, which already says, "The SSAC recommends that the ICANN organization continue to track and provide regular updates to the ICANN Board and community on both alternative protocols that make use of the domain namespace, and efforts to create mitigations and reduce risks inherent in the coexistence of multiple namespaces and protocols." I'd like to try to get this resolved this week by email, rather than having another work party call, so let's please have a discussion here on the work party mailing list. Thoughts? Barry

9 14

nearing the finish line ...
by Andrew McConachie Dec. 5, 2023

Dec. 5, 2023

Dear SSAC Members, I've addressed everything that got brought up on last Thursday's call. <https://docs.google.com/document/d/1_eOj_csXgOi3hzkobsY6SgA7b4CcMPhTLKvQ_8F…> We'll have our call this Thursday and hopefully we can resolve all comments. After that we have the SSAC 48-hour review before publication. If you won't be on the call this Thursday please take a look at the suggestions I made and leave any feedback you have. Thanks, Andrew

1 0

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

Re: [SSAC-Evo-Reso-WP] Evo-reso paper: let's pass it to Lixia and Eric for their review
by Joe Abley Oct. 24, 2023

Oct. 24, 2023

On 22 Oct 2023, at 14:56, Barry Leiba <barryleiba(a)computer.org> wrote: > Given the blockchain presentation that Lixia and Eric made to the > admin committee on Saturday afternoon, we should get the evo-reso > paper to them for their review in parallel with the SSAC review. It > would be great to have their comments and to possibly incorporate > their data/results. > > Does anyone in the work party object to getting them a copy? I didn't see Lixia and Eric's presentation but I am aware of their habit of saying things that make sense. No objection from me. Joe

1 0

Sessions on Alternative Name Systems at ICANN 78
by Andrew McConachie Oct. 23, 2023

Oct. 23, 2023

Wednesday has three sessions that feature content on Alternative Naming Systems. DNSSEC Workshop 2.7 Eric Osterweil, George Mason University: Monitoring and Evaluating ENS through the INSO <https://icann78.sched.com/event/1T4Nh/dnssec-and-security-workshop-2-of-3> 3.5 14:50 – 15:05 (12:50 – 13:05 UTC) – Lixia Zhang, UCLA: A Comparative Study of DNS and Blockchain-based Naming System <https://icann78.sched.com/event/1T4Nk/dnssec-and-security-workshop-3-of-3> OCTO is also hosting another session on Emerging Identifier Technologies. <https://icann78.sched.com/event/1T4Id/emerging-identifier-technologies> "This session will provide participants with the opportunity to learn more about emerging identifier technologies. In Hamburg we will hear from the Co-Founder of Unstoppable Domains, Bradley Kam. We will also be joined by AFNIC." Unfortunately the OCTO session overlaps with the 2nd part of the DNSSEC WS and Eric’s presentation. —Andrew

1 0