IANA whois information

[Hanno Böck]

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/

[Amir Omidi]

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. 

--
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.

[Amir Omidi]

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.

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.

[David Adrian]

> 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:

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.

[Watson Ladd]

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

> 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

[Matthew McPherrin]

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 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)

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.

[Amir Omidi]

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.

[Watson Ladd]

Stop using the method

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.

[Clint Wilson]

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).

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.

[Amir Omidi (aaomidi)]

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?

[Amir Omidi]

A ballot has been introduced removing these problematic DCV methods:

https://lists.cabforum.org/pipermail/servercert-wg/2024-September/004821.html