A ballot has been introduced removing these problematic DCV methods: https://lists.cabforum.org/pipermail/servercert-wg/2024-September/004821.html
On Sun, Sep 15, 2024 at 13:22 Amir Omidi (aaomidi) <a...@aaomidi.com> wrote: > I'll be honest, I think this issue is not being taken as seriously as I > think it should be. The problem I see right now is that this specific > attack model is now a *known attack model*. There's simply no way (I > think?) for root programs, or the public to know the extent that this is > currently being abused. CA's that use this method *may* have an idea, but > honestly, if a CA is still using this method I'm not entirely sure I'm > trusting them to do a security analysis here. > > We have a couple of options ahead of us here. I'm listing some below: > > 1. Do nothing in the short term. I'm fine with this assuming the community > thinks we don't need anything immediate here. > > 2. In the short term, require a specific CAA string that specifically opts > into making WHOIS based domain control validation permitted. I don't know > if such a construct currently exists, but we could define one temporarily > and require CAs that do WHOIS validation to actually check for that. This > would mean WHOIS based DCV becomes opt-in. Given that this method does not > *seem* like its a very popular method, I'd argue that two week deadline > to have this implemented is a reasonable measure. If a CA can't have this > implemented by then, they will have to stop using WHOIS based DCV. > > 3. Phase out these DCV method over the next few months (while allowing > authorization reuse for the duration the BRs currently allow). I don't > think anyone really can claim that these DCV methods are correct? Beyond > that, the vast majority of certificates being issued today are using > DNS/HTTP/ALPN validation methods which are a lot better than an email to a > random address a CA finds over WHOIS. > > Do folks have other suggestions here for the short term? Do folks feel > strongly about any of these options? > > On Friday, September 13, 2024 at 6:44:23 PM UTC-4 Clint Wilson wrote: > >> 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-secur...@mozilla.org < >> dev-secur...@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> >> 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 <watso...@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-secur...@mozilla.org <dev-secur...@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 <dava...@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-secur...@mozilla.org <dev-secur...@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> 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-secur...@mozilla.org" group. >>>> >>>> To unsubscribe from this group and stop receiving emails from it, >>>> send an email to dev-security-po...@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-secur...@mozilla.org" group. >>>> >>> To unsubscribe from this group and stop receiving emails from it, >>>> send an email to dev-security-po...@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-secur...@mozilla.org" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to dev-security-po...@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-secur...@mozilla.org" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to dev-security-po...@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-secur...@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-po...@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/CAOG%3DJUJSKs0r7mLeh1xgFRZuxHB8fvhYhTQz8WWf%2BJX6AbH73w%40mail.gmail.com.
