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/919d37f6-936e-412f-a3c9-6aede6f33b27n%40mozilla.org.
