I can see how this would work on a technical level but what's the intended use case?
replies(13):
In other cases dns is just not needed at all. You might prefer simplicity, independence from dns propagation, so you will have your, say, Cockpit exposed instantly on a test env.
Only our imagination limits us here.
If you want to use NTS, but can’t get an IP cert, then you are left requiring DNS before you can get a trusted time. If DNS is down- then you can’t get the time. A common issue with DNSSEC is having the wrong time- causing validation failures. If you have DNSSEC enforced and have the wrong time- but NTS depends on DNS, then you are out of luck with no way to recover. Having IP as part of your cert allows trusted time without the DNS requirement, which can then fix your broken DNSSEC enforcement.
Elaborate, please.
> There's no reason AT ALL to bring IP addresses into the mix.
Not sure what scenario you are talking about, but IPs are kind of hard to avoid. DNS is trivial to avoid - you can simply not set it up.
"bringing IPs into the mix" is literally the only possible option.
I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the giant https proxy services like Cloudflare, that the idea of IP certs was floated as a solution but dismissed as a pipe dream. With IP address certificates, now every server can participate in ESNI, not just the giants. If it becomes common enough for clients to assume that all web servers have an IP cert and attempt to use ESNI on every connection, it could be a boon for privacy across the internet.
> Elaborate, please.
Identify a service directly by its crypto key. When you configure something else to connect to it, treat the IP address as a hint, not the primary identifier for what it's talking to. Standard idiom.
... and before you tell me that that's infeasible because you'd have to modify software, go do a survey of all the code out there, and see how much of it supports IP address certificates. If you're moving around the parts of some big complex system, it's pretty much guaranteed that many of those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
And if you're fixing the software anyway, then it's not sane to "fix" it to attach identity to something you're going to want to change all the time, like an IP address. Especially if they're global addresses (which are the only ones any Let's Encrypt or any other public CA is ever going to certify) in the IPv4 space (which is the only one any "enterprise" ever seems willing to use).
1. Want to connect to https://www.secret.com.
2. Resolve using DNS, get 1.2.3.4
3. Connect to 1.2.3.4, validate cert
4. Send ESNI, get separate cert for www.secret.com, validate that
... and the threat you're mitigating is presumably that you don't want to disclose the name "www.secret.com" unless you're convinced you're talking to the legitimate 1.2.3.4, so that some adversary can't spoof the IP traffic to and from 1.2.3.4, and thereby learn who's making connections to www.secret.com. Is that correct?
But the DNS resolution step is still unprotected. So, two broad cases:
1. Your adversary can subvert DNS. In this case IP certificates add no value, because they can just point you to 5.6.7.8, and you'll happily disclose "www.secret.com" to them. And you have no other path to communicate any information about what keys to trust.
2. Your adversary cannot subvert DNS. But if you can rely on DNS, then you can use it as a channel for key information; you include a key to encrypt the ESNI for "www.secret.com" in a DNS record. Even if the adversary can spoof the actual IP traffic to and from 1.2.3.4, it won't do any good because it won't have the private key corresponding to that ESNI key in the DNS. And those keys are already standardized.
So what adversary is stopped by IP certificates who isn't already stopped by the ESNI key records in the DNS?
[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
[2] https://cabforum.org/working-groups/server/baseline-requirem...
I've been doing that for years on onprem (~60% old "enterprise/legacy" ~40% modern stuff) and never seen anything that doesn't support it. YMMV, but if all I work with supports it, I won't complain in vain.
> those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
I did many times, seems that legacy heavens were always kind to me in this regard.
> something you're going to want to change all the time, like an IP address
That's a personal assumption as well. If your architectures change IPs all the time, OK. Ones I worked with didn't. Always had plenty of components with IPs that didn't changed in a decade or two. Even my two previous local ISPs I had gave me "dynamic public IP" and kept them for many years. For some companies changing an ip of their main firewalls/load balancers or VPN servers is unthinkable.
Even on my last project on Public Cloud, the first thing I did was to make sure public IPs won't be dynamic (will survive recreation of services) so I don't have to deal with consequences of my corporate client endpoints and proxies flushing DNS caches randomly. (don't ask me why, but even huge companies still use proxies on a large scale. Good luck with figuring out when such proxy invalidates your DNS record).
> in the IPv4 space
IPv6 is here. Your printer and light bulb will want a cert as well.
> you include a key to encrypt the ESNI for "www.secret.com" in a DNS record
I've never heard of this, is this a thing that exists today? (edited to remove unnecessary comment)
see: https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...
> Another Internet Draft incorporates a parameter for transmitting the ECH public keys via HTTPS and SVCB DNS record types, shortening the handshake process.[24][25]
[25]: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
Only helpful if the IP itself is not incriminating or revealing, that is, it's an IP from a large pool like Cloudflare, GCP, AWS, etc.
To my mind, it's much more interesting to verify that an address like 1.1.1.1 or 8.8.8.8 is what it purports to be, but running UDP DNS over TLS is still likely not practical, and DoH already exists, so I don't see how helpful is it here.
Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods).
I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates:
curl -sI https://1.1.1.1 | grep -i '^date:'
curl -sI https://8.8.8.8 | grep -i '^date:'
curl -sI https://9.9.9.9 | grep -i '^date:'
(This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)
Its a mesh routing network where your identity is your public key and your ipv6 address is derived from the hash of your public key.
Works perfectly
DHCP option 42 (defined in RFC 2132) can be used to specify multiple NTP server IPv4 addresses.
(There’s also DHCP option 4, but that’s used to specify the IP for the older RFC 868 time protocol.)
DHCPv6 has option 31 for SNTP (via deprecated RFC 4075), and option 56 for NTP (via RFC 5908).
So, that would probably be the best option: Get an NTP address from DHCP or DHCPv6, use that to set your clock, and then do whatever you need!
(Yes, it does require that you trust your DHCP source, and its NTP reference.)