Curl has the same complaint that I do:
$ curl https://192.0.32.9/domain/root.zone
curl: (60) SSL: no alternative certificate subject name matches target host name '192.0.32.9'In the days of ye olde internet it used to be called "ftp.internic.net". Today, I believe it is still "internicftp.vip.icann.org".
To make curl work
curl -k https://192.0.32.9
curl https://www.internic.net/domain/root.zone
The IP address isn't directly validated, but you get something even better.
And it can't go out of date as easily. Like you said, the IP changes sometimes. internic.net doesn't change.
Am I understanding this correctly. You are concerned that the IP address might change. As I said, if that happened, they would not change it without notifying the public in advance. This IP address is used to bootstrap DNS. Thus, no one should need DNS to find it. AFAIK, outside of EV certificates, CAs rely on domain name registration as their "verification" mechanism. Seems like one has to trust the DNS in order to trust a CA. And why trust a CA.
I am quite certain I will be dead before this IP address ever changes again. It used to be 208.77.188.26. This is going to be the "right" IP address for the forseeable future. TLS cert or not. I use FTP to get the root.zone, not TLS. Verisign's zone file access program used to offer .com and .net zone files only via FTP. Even if you can use TLS to get them now, I'll bet you can still use FTP.
> Seems like one has to trust the DNS in order to trust a CA. And why trust a CA.
You're arguing that certificates are useless?
They're not, because you might be on a hostile network, and it's much easier to attack one person than to attack domain verification.
And even if certificates are 99% useless, that doesn't affect my argument about which kind of certificate is better.
> You are concerned that the IP address might change.
That was only one of the things I said. Other than hostile networks, you might make a typo, and there are various reasons you might not notice getting the wrong file immediately that a nice verifiable "internic.net" label could help with.
In this case you are downlaoding a file that is served at a number of other known, unchanging IP addresses, "root servers." Even more, the RRs in the file have been signed, "DNSSEC".
All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.
I meant useless in this scenario. So same.
> All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.
What? Then we don't disagree at all. You need to reread my earlier comments. I said a certificate with a name is better than a certificate with an IP. I never said anything about the value of the IP address itself, only what's validated.
I think that's debatable. IMO, it depends in part on the perceived value of the ICANN "domain name business" as some sort of vetting mechanism. In this case the party being vetted is ICANN itself. Although they did pay for "EV".
https://censys.io/ipv4/192.0.32.9/raw
Does Globalsign still offer certificates that are tied to IP addresses.
https://support.globalsign.com/customer/portal/articles/1216...
Here is a question for the TLS certificate fanatics: Why do CAs provide non-http URLs to their CA certificates in the certificates they sell. For example,
http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1.crt
I suspect it is a bootstrapping issue. At the top of the chain there is some notion of implict trust. No different than with DNS. Trust should be decided by the end user not by developers, nor by some self-appointed "authority".
TLS 1.3 mandates use of X25519, Ed25519, X448, and Ed448.
Who is responsible for designing X25519, Ed25519, X448 and Ed448 and introducing these algorithms to TLS developers. The same person who designed and introduced DNSCurve. More diplomatically, a team lead by the same author as DNSCurve.
The observation I make from the facts is that while DoH may win a "popularity contest" over DNSCurve (VHS vs Betamax) in terms of what most people will use, TLS and therefore DoH nonetheless is or soon will be relying on the work of the author of DNSCurve. Whether anyone else besides me thinks this is notehworthy I have no idea. I mean, the author could have just intended the work to be used in DoT or whatever was the current trend (VHS), but the fact that he demonstrated how it could be used in a different way (Betamax), encrypting each packet, to me that is not a coincidence. It was not meant to be ignored, IMO.
As an end user, I am not interested in what is popular, I am interested in what is best. But that's only me. Readers can decide for themselves.