Re: IANA whois information

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) wrote: > I'll be honest, I think this issue is not being taken as seriously as I > think it shou

Re: IANA whois information

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 b

Re: IANA whois information

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 agreemen

Re: IANA whois information

Stop using the method On Fri, Sep 13, 2024, 12:22 PM 'Amir Omidi' via 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 lik

Re: IANA whois information

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 domain

Re: IANA whois information

It would certainly be possible for CAs to include a Certificate Policies Extension with an OID specifying the validation method. That may have privacy and certificate size implications. However, being able to identify the validation m

Re: IANA whois information

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 n

Re: IANA whois information

> 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 wrote: > Given t

Re: IANA whois information

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 wrote: > > I’m hoping that the Chrome Root Program takes the lead on this and sets > a deadline for sunsetting WHOIS based DCV. >

Re: IANA whois information

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 wrote: > Hi, > > In the context of the recent .mobi whois takeover vulnerability, I had, >

IANA whois information

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 x