On 18/9/2024 3:07 μ.μ., Mike Shaver wrote:
Hi Dimitris,
On Tue, Sep 17, 2024 at 2:55 AM Dimitris Zacharopoulos (HARICA)
<[email protected]> wrote:
On 16/9/2024 11:39 μ.μ., Mike Shaver wrote:
I’ll admit that I am not very familiar with how gTLD operators
manage their Whois services, or ensure prompt update when domains
lapse or similar. Could you provide some more detail about the
“decent rules” in place, and how they align with the general
standard of hygiene and reliability that is required of other DCV
methods?
I recall past discussions at the Forum where this conversation
between the quality of ccTLD vs gTLD operators took was covered in
more detail but a more recent post
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer>in
m.d.s.p. confirmed that gTLD operators are more closely monitored
by IANA compared to the general case of ccTLDs. Of course, ccTLD
operators in the EU are functioning under European Law
(Regulations/Directives), and they are considered part of the
Essential/Critical Infrastructure under the NIS2 Directive.
Sorry, yes, I understand that they are monitored, but I don't know
exactly what's monitored. As an analogy, a CA might have SOC2, which
is a form of audit and valuable to its customers, but that would not
suffice for purposes of them issuing certificates: they need to have
the WebTrust stuff audited as well. (I don't actually care if there's
a specifically-accredited audit stamp, my point is that IANA might not
be monitoring for the same things that SCWG would expect to suffice
for use as DCV.)
We don't need Domain Name Registrars to go through WebTrust or ETSI
audits suitable for Trust Service Providers. These Registrars are the
source of truth for the DNS on which all Internet connections, and the
WebPKI relies on. It's so fundamental to the ecosystem that IMO it
doesn't make sense to ask ourselves how this Forum can make them better.
Other authorities should be working on that.
If a ".cookoo" TLD operator is not functioning properly, then the entire
TLD is in jeopardy and every Domain owner under that TLD is at risk.
Certificates are the least of people's problems when relying parties
connect to websites operated under that unsafe TLD operator.
As far as I can tell there isn’t even a provision for server
authentication of the WHOIS protocol, meaning that it could be
subverted by any MITM or DNS-poisoning adversary, for any domain.
Such an attack could be run, in theory, against any Domain Name
that is not protected by DNSSEC. It is not specific to the WHOIS
protocol.
Well yes, which is sort of why the SCWG and TLS exist in the first
place! If you know of other DCV methods that are similarly unprotected
from DNS attacks, I very much think that we should look critically at
them as well!
No, the SCWG and TLS is not here to solve the unencrypted nature of the
DNS protocol. IETF and DNSSEC is. There is a great number of Domain
Names in the DNS without DNSSEC, and there is still heavy reliance on
the unencrypted DNS protocol in almost EVERY Domain Validation under
3.2.2.4.
Even the Agreed-upon change to website method, 3.2.2.4.18, relies on
"Authorized Ports that are offered via non-encrypted channels (ports 80,
25, 22).
I would go as far as to say that even the ACME methods connecting to
https URLs are untrusted, because the endpoints are not protected by
publicly trusted certificates and anyone could launch a MiTM attack.
Just to repeat my previous statement, I support the deprecation of
using the WHOIS protocol (RFC 3912) to retrieve Domain Registrant
contact information but I am not entirely convinced about the
expedited manner of removing it in its entirety. It seems
disproportionate.
Could you elaborate on the proportionality here? From my perspective,
there is a publicly-demonstrated vulnerability in DCV that can only be
promptly remedied by ceasing use of WHOIS-the-protocol (at least)
.com, .org, .net, .healthy-operators are operating just fine and the
Internet has been working reliably with Domain Names under those
reliable TLD operators.
On the other hand, there might be some "unreliable" TLD operators for
which certificate issuance is the least of the Internet's problem. For
example, if we know that there is a rogue TLD operator that may change
the NS records of Base Domain Names under that TLD at will in order to
intercept traffic, the WebPKI ecosystem can do nothing about it but to
ask public CAs to block that TLD from getting certificates. Fortunately,
we have not seen such a case with this security issue.
In addition to that, in my previous email, I specifically focused on the
flaw of certain WHOIS libraries that fail to search for the
source-of-true regarding TLD Registrar entry points. In order for the
SCWG measures to be proportionate, we should not blame the entire WHOIS
protocol but work on additional controls to minimize the risk of CAs
using those problematic WHOIS libraries.
Instead, we could focus on requiring immediate/emergency measures
for CAs to use the WHOIS protocol securely, thus mitigating the
immediate risk, and use a transition period that will allow CAs to
gracefully migrate off the WHOIS and into RDAP. At the same time,
if CAs want to completely discontinue WHOIS/RDAP, it would give
time to their Subscribers to switch to other Domain Validation
methods.
There are a few issues here:
WHOIS: The BRs currently make mention in multiple places of WHOIS and
specify WHOIS-the-protocol (RFC 3912). WHOIS-the-protocol is clearly
inappropriate because of it being subject to DNS interception,
I disagree. We are trying to move from "http" to a "trustworthy https"
(note: "trustworthy https" in the sense that it doesn't use untrusted
certificates). At some point, CAs need to rely on unencrypted
communication to achieve that. The Forum and SCWG has been working for
years to make sure the Domain Validation methods have reasonable
controls to minimize the risk of a certificate being issued to an entity
that is not associated and does not control the Domain Name in the
certificate. Historically, the Forum has deprecated methods that are
proved to be insecure in their entirety but I don't think this is one of
those cases.
and I'm a little embarrassed that in my recent dives into the BRs and
validation methods I didn't twig to the fault there. WHOIS the
protocol should be sunset by CAs *immediately*, IMO. They should all
be following this list and Bugzilla, and they should have all seen
that if they're using WHOIS-3912 they're issuing insecurely
(independent of takeover attacks!
Who is "they"? I believe CAs in this WG monitor m.d.s.p. and other lists
but some might not agree with your assessment that all Domain Validation
methods must rely on fully-encrypted communication end-to-end.
Certificates are trying to solve exactly that fundamental problem, using
the insecure Internet.
Domain Names are also susceptible to takeover attacks. You can search
the web and find multiple sources and articles describing how Domain
owners lost control of their Domain Names. Digital Certificates can't
prevent these cases from happening.
the protocol itself is fatally flawed!), and they should cease
issuance using that method—without waiting for BR revision to codify
it. That's just good faith operation of a certificate authority, given
what is known and has been demonstrated. If there is a CA that wants
to make the "critical infrastructure" argument about domain validation
by WHOIS-3912 then I'd be very curious to hear how emergency
validation through other mechanisms isn't possible.
I'm confused by this statement. Is this a plea to the CAs to stop using
what you think is an insecure method? Everyone is entitled to an opinion
but that's why we are having these discussions publicly so that the SCWG
members can find "substantial consensus" as mandated in the Bylaws. I'm
sure some CAs are already working, or have already stopped using WHOIS,
proactively, until this discussion comes to an end.
RDAP: RDAP looks like it would give transport security and a better
ability for IANA to ensure the integrity of domain-to-registrar
mappings, which is certainly progress, but:
Domain Registries for validation of domain contacts: domain registry
information should, IMO, only be used at *all*, independent of
protocol, if the SCWG can be confident that IANA or another trusted
body will be able to ensure that all those registries, for all domains
present and future, will meet the SCWG's requirements for reliability.
This includes whatever the requirements might be for who can alter the
record, as well as the maximum latency for updates to be available
after the change of control of a domain—and how those are
This is like saying that the Registrars, the main stewards assigned to
run the DNS which is fundamental for how the Internet works and
practically the World Wide Web, need to meet the SCWG requirements for
reliability. I think there is a very big misunderstanding on how things
work and I'm surprised we are having this discussion. It is a dependency
problem:
* The web needs certificates to run securely.
* The web also needs DNS to run.
* DNS entry points for all Base Domain Names are managed by gTLD/ccTLD
Registrars.
Put differently, if CAs are managing "the keys to the Internet", domain
name Registrars are managing "the backbone of the Internet". That's just
how things work IMO and I'm already wondering if I'm missing something
huge or fundamental, and I'd hope someone else can confirm this
dependency issue or present why this is not the case.
I don't have strong feelings about this but I'm afraid of this
setting a bad precedence (killing a Domain Validation method used
for decades because of bad/insecure *implementation* of this method).
There is no possible secure implementation of WHOIS-as-RFC-3912
without additional specification of an authenticating transport layer.
That's just bytes-on-the-wire fact, and no grace period is going to
improve anyone's safety on the web.
(That a DCV method has been used unmodified for decades is a sign that
we should subject it to *more* scrutiny, not less, IMO. I was there
decades ago and while I'm generally proud of the work done by this
community before and after CA/BF came to be, we were certainly much
less sophisticated in our understanding of the threat models for
domain validation and certificate abuse than we are today. MPIC, for
example, was not considered a meaningful issue at the time, and we now
know well that it represents a clear and present threat to web PKI
integrity. I probably should have seen unencrypted-WHOIS as a bad
choice, though. :( )
There is no need to feel bad about this because, as stated earlier,
almost all validation methods approved by the BRs have some sort of
unencrypted communication in order to prove control of a Domain Name
with some reasonable assurance. MPIC is a great example of a
proportional measure, taken to mitigate a known-for-years threat that
affected a few Domain Names taken over by BGP hijacking techniques, but
which was not ever considered to be so wildly abused in a way that would
break the webPKI. I believe the WHOIS deprecation could follow a similar
pattern but for sure the SCWG should urgently focus on requiring CAs to
use WHOIS libraries that query the proper Registrar endpoints, IF they
are using the WHOIS method to query Domain Contact information.
Dimitris.
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
