I would love for that to happen. Do you have any suggestions on what we can do to mitigate what is effectively a 0-day?
On Fri, Sep 13, 2024 at 10:42 AM David Adrian <[email protected]> wrote: > > 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/CAOG%3DJU%2B%2BA4VxUY4z7Y95ZVOEx58wU8HRx4EoU8p_PRCa7x5BhA%40mail.gmail.com.
