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 <ha...@hboeck.de> 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 " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. 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.
