FWIW, this has been brought up a few times that I can recall, and is currently captured in this Issue in the CA/Browser Forum: http://github.com/cabforum/servercert/issues/459. While there isn’t consensus yet within the Forum, I expect we’ll continue discussing it and hopefully come to agreement on a solution (which I agree to being necessary).
> On Sep 13, 2024, at 12:21 PM, 'Amir Omidi' via > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> 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 <ma...@letsencrypt.org > <mailto:ma...@letsencrypt.org>> 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 <watsonbl...@gmail.com >> <mailto:watsonbl...@gmail.com>> 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 >>> dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> >>> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org>> >>> 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 <davad...@umich.edu >>> > <mailto:davad...@umich.edu>> 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 >>> >> dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> >>> >> <dev-security-policy@mozilla.org >>> >> <mailto:dev-security-policy@mozilla.org>> 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 <ha...@hboeck.de >>> >>> <mailto: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 <http://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 >>> >>>> <mailto: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 >>> >>>> <mailto:dev-security-policy%2bunsubscr...@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 >>> >>> <mailto: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 >>> >>> <mailto:dev-security-policy%2bunsubscr...@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. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google Groups >>> > "dev-security-policy@mozilla.org >>> > <mailto: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 >>> > <mailto:dev-security-policy%2bunsubscr...@mozilla.org>. >>> > 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 >>> "dev-security-policy@mozilla.org <mailto: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 >>> <mailto:dev-security-policy%2bunsubscr...@mozilla.org>. >> >>> 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 > "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 > <mailto: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%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 "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/C5E2E975-BD7F-4892-9854-BCA5A59A4386%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
