Stop using the method On Fri, Sep 13, 2024, 12:22 PM 'Amir Omidi' via [email protected] <[email protected]> wrote:
> 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJULgMonwCuKNCGFgZCNbvcrTY1G04E_VSYsBahzULws-dA%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/CACsn0cmnVDv2SstNq3f8s459KsUbjhtpyALbavEKoXbBO5S23A%40mail.gmail.com.
