I agree with this idea and has been something I’ve wanted for a long time.
Beyond that though, what should we do now? Especially now that information about how to do an attack like this is out. It’s unlikely that the operators of TLDs are suddenly going to get better at handling their WHOIS domains. On Fri, Sep 13, 2024 at 13:53 Matthew McPherrin <[email protected]> wrote: > It would certainly be possible for CAs to include a Certificate Policies > Extension <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4> > with an OID specifying the validation method. That may have privacy and > certificate size implications. > > However, being able to identify the validation method may be of enough > value to make it worthwhile for cases like this in the future. For example, > a researcher may want to cross-reference certificates by TLD using a > whois-based validation method. Or for other incidents, like verifying that > Let's Encrypt's https://bugzilla.mozilla.org/show_bug.cgi?id=1751984 > incident correctly revoked all TLS-ALPN-01 certificates. > > I will leave it to the root programs or CA/B forum to decide if such > action would be worthwhile and how to proceed with that. > > Matthew McPherrin > (Sent in a personal capacity only) > > On Fri, Sep 13, 2024 at 1:13 PM Watson Ladd <[email protected]> wrote: > >> One thing would be to look at CPS's to see which CAs have been using >> this method. >> >> Some CAs that have have opened up bugs, I presume that all of them >> have looked and if not affected have not opened one to keep the >> channel clear. Affected ones of course must. >> >> Sadly the validation method used does not appear in the issued certs >> so it's hard to use tools to get a report. >> >> On Fri, Sep 13, 2024 at 8:12 AM 'Amir Omidi' via >> [email protected] <[email protected]> >> wrote: >> > >> > 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 >> . >> > >> > -- >> > 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 >> . >> >> >> >> -- >> Astra mortemque praestare gradatim >> >> -- >> 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/CACsn0cnub7x%2B1yw16aAW8aeW1TFi02YNunMB7nfhPy049yJERA%40mail.gmail.com >> . >> > -- 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%3DJULgMonwCuKNCGFgZCNbvcrTY1G04E_VSYsBahzULws-dA%40mail.gmail.com.
