> I’m hoping that the Chrome Root Program takes the lead on this and sets a deadline for sunsetting WHOIS based DCV.
It is possible for members of the Web PKI community besides Chrome to do things. On Fri, Sep 13, 2024 at 9:17 AM 'Amir Omidi' via [email protected] <[email protected]> wrote: > Given the way the ecosystem has recently worked, I’m hoping that the > Chrome Root Program takes the lead on this and sets a deadline for > sunsetting WHOIS based DCV. > > On Fri, Sep 13, 2024 at 09:15 Hanno Böck <[email protected]> wrote: > >> Hi, >> >> In the context of the recent .mobi whois takeover vulnerability, I had, >> as already mentioned in another thread, checked all the whois servers >> listed in IANAs data, and found a substantial number not answering. >> (Those were for the TLDs cf ci dz ec gn gp hm iq ml na sb tk to uy >> xn--lgbbat1ad8j xn--mgbtx2b xn--ygbi2ammx) >> >> I reported this to IANA, and also asked them about the reliability of >> the whois server data provided by them, as I believe this is very >> relevant for the security of whois as a domain validatin mechanism. >> >> Kim Davies from IANA shared this with me, and allowed me to share it >> publicly with this group: >> >> > You'll note that the TLDs you gave identified with inoperative WHOIS >> > servers are country-code top-level domains (ccTLDs). For ccTLDs, >> > there is no global policy requirement for ccTLD managers to operate a >> > WHOIS server, and if they do, what kind of information is provided. >> > ccTLDs are expected to be operated under local oversight (i.e. within >> > their respective country) and accountability for how WHOIS servers >> > are operated is performed locally, not under ICANN policies. This is >> > in contrast to generic top-level domains (gTLDs) where ICANN policies >> > establish specific requirements and obligations, which are maintained >> > through contracts. ICANN operates a contractual compliance function >> > to address when these obligations are not met. >> > >> > More generally, TLD managers are obligated to keep their records >> > up-to-date with IANA. but again in the case of country-code top-level >> > domains IANA does not have an enforcement mechanism to ensure the >> > ccTLD manager maintains accuracy of their records. We do verify the >> > data is correct at the time we are assessing a change request from >> > the TLD manager, but we cannot ensure it is consistently maintained >> > without the ccTLD manager voluntarily participating. This is an issue >> > that has been raised with the policy setting body for ccTLDs, the >> > Country Code Name Supporting Organization (ccNSO), and they have >> > recently established a working group called the Policy Gaps Analysis >> > Working Group that is expected to study the issue in the near future. >> > >> > To your question as to whether IANA can guarantee control of the >> > servers that TLD operators use to operate their TLDs. We believe we >> > have sufficient safeguards in our processes that when we receive >> > change requests from TLD operators, we validate they are authentic >> > and appropriately authorized, and we confirm at that time the servers >> > are those duly designated by them. However we are only responsible >> > for their entries in the root zone and the associated meta-data >> > concerning who the recognized operator of the domain is. We have no >> > policy basis to investigate the internal workings of a TLD manager >> > and perform assessments on whether they have full control over the >> > components that comprise their registry operations. >> >> And in a further mail: >> >> > Briefly reading that thread, on an informal basis we have reached out >> > to whois client vendors when we notice poor implementations. The IANA >> > WHOIS server (whois.iana.org) actually has a "refer:" field that, >> > when queried for a FQDN that is more specific than the data we hold, >> > provides referrals to second-level WHOIS servers programmatically so >> > that there is no need to hard-code TLD WHOIS server locations. With >> > that said, WHOIS itself as a protocol is being superseded by RDAP >> > which has a more robust discovery/referral approach and would be the >> > preferred mechanism moving forward. >> >> I take away two things from this: >> >> * Hardcoding whois servers, like what appears to be the standard of >> many whois tools, is generally not a good idea. If one uses whois at >> all, one should query the iana whois server, and use the "refer:" >> field to get to the actual whois server responsible. >> >> * Particularly whois data for ccTLDs has limited reliability, and we >> have no guarantee that TLD operators keep this information updated >> and accurate. >> >> In my opinion, the latter is even more reason to consider deprecating >> whois as a domain validation mechanism. >> >> I have not looked into RDAP, and do not know about its security >> properties and whether this is used by CAs as an alternative to whois. >> >> >> -- >> Hanno Böck - Independent security researcher >> https://itsec.hboeck.de/ >> https://badkeys.info/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer >> . >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJU%2BnOogOb58QKV8B5bEJUXnr5vsNeKSRKniL0Tud53x-Sg%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJU%2BnOogOb58QKV8B5bEJUXnr5vsNeKSRKniL0Tud53x-Sg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACf5n7_tdNb-EyMDZcKj-w%2B0ab4AHKNsOp39fd83dj1q7PhrVg%40mail.gmail.com.
