No, TLS even without verification of the other end’s identity is significantly better than plaintext, because the threat model “what if I’m not talking to who I think I’m talking to” is only one threat model, and others such as “what if someone is listening in on my conversation” are also important.
Or to put it more bluntly: if the entire point and entire benefit of TLS was to prove the identity of the other party rather than to prevent eavesdropping, there’d be no need to encrypt anything once you’d checked the other side’s certificate, and we could just remove that part of it. Right?
No, IP addresses are treated like any other domain – they are marked as untrusted by every browser and HTTP library, unless you manage to get a trusted CA to sign you a certificate.
It’s great to see something being standardised in this space. A lot of people were caugh out by the big money grab for new TLDs, so having something that is guaranteed not routable is great. The next thing I want is some form of link-local certificates. For example, mDNS including some random network ID that’s then echoed by all responders so you have a persistent identifier for Fred’s LAN and can tell the difference between his printer and yours, even though they’re the same model.
I’m curious why .LAN wasn’t considered. A lot of people are already using it as a defacto private TLD. If i remember correctly, OpenWRT’s dnsmasq configuration sets .lan as the domain by default
I think two common uses will be corporate VPNs for employees and overlay networks in large systems, neither of which have much to do with physical location.
For sure (although there’s not really much reason a corporate VPN can’t use a name it controls in the global DNS space). But ime plenty of corporate networks use .lan even though they may be anything but local.
Many candidate strings were deemed unsuitable due to their lack of meaningfulness. IANA has
interpreted the requirement for the string to be meaningful to allow the purpose of the string’s
reservation to be gleaned from its name without special expertise. For example, “DOMAIN” as a
string is meaningful, but would not convey that its purpose is specifically for private-use
applications.
re certs for local/developer uses: my current employer bought a cert for a domain we control but don’t otherwise use that points at 127.0.0.1 and distributed the cert/key to all our developers. so, we have a signed cert for developer use and don’t have to deal with any self signing or trying to run a CA or anything. I highly recommend this and I hadn’t run into before but whatever we spent on the cert has been more than paid back by us not having to manage our own certs. If and when I move on I would recommend the same thing to that employer as well
fwiw our cert is something like local.ourcompany.different-TLD-than-we-use-anywhere-else
Yes you can, however there are still situations where those self signed certs can be extremely annoying. The immediate thing that comes to mind is attempting to run something like puppeteer in a container. As soon as you introduce other logical machines like containers or VMs self signed certs get extremely unwieldy. And now you are further separating your dev environment even more from staging/prod
We run our own ca infra and developers have tooling to get an internally trusted cert/key. Reusing certs/keys is strictly prohibited, even in development
We used to have a top level domain for private use, .dev, until Google exploited the situation and took it over, demanding exorbitant sums for domain names using it.
I don’t understand why google has the right to print money like this (or godaddy with their widespread squatting). Money certainly seems to be ruining DNS as of late.
Now, I want a
.insecuretld that we can get commonly accepted ssl certs for without any verification. It would make testing things a lot easier.I don’t understand what you mean. TLS without any DCV is as good as plaintext
You don’t need TLS to be secure if you only need it for testing.
No, TLS even without verification of the other end’s identity is significantly better than plaintext, because the threat model “what if I’m not talking to who I think I’m talking to” is only one threat model, and others such as “what if someone is listening in on my conversation” are also important.
Or to put it more bluntly: if the entire point and entire benefit of TLS was to prove the identity of the other party rather than to prevent eavesdropping, there’d be no need to encrypt anything once you’d checked the other side’s certificate, and we could just remove that part of it. Right?
You are supposed to have that already for any local ip address.
No, IP addresses are treated like any other domain – they are marked as untrusted by every browser and HTTP library, unless you manage to get a trusted CA to sign you a certificate.
Supposed to.
Supposed to according to what? I can’t find a source for this
It’s great to see something being standardised in this space. A lot of people were caugh out by the big money grab for new TLDs, so having something that is guaranteed not routable is great. The next thing I want is some form of link-local certificates. For example, mDNS including some random network ID that’s then echoed by all responders so you have a persistent identifier for Fred’s LAN and can tell the difference between his printer and yours, even though they’re the same model.
Yes, especially .dev 😳
I’m curious why
.LANwasn’t considered. A lot of people are already using it as a defacto private TLD. If i remember correctly, OpenWRT’s dnsmasq configuration sets.lanas the domain by defaultAlso
.home.arpaalready exists, although that is a bit awkward.I think two common uses will be corporate VPNs for employees and overlay networks in large systems, neither of which have much to do with physical location.
For sure (although there’s not really much reason a corporate VPN can’t use a name it controls in the global DNS space). But ime plenty of corporate networks use .lan even though they may be anything but local.
SAC113: SSAC Advisory on Private-Use TLDs [PDF] makes it clear that ICANN was aware of OpenWRT’s usage of
.lan(see Table 2).Identification of a top-level domain for private use [PDF] gives a likely reason why
.lanwasn’t chosen:To my brain,
.lanconveys as much meaning as.internalYes, but not all users know what the abbreviation LAN stands for.
i see .local more than I see any of the ones mentioned here.
That one’s taken by mDNS, unfortunately.
In fact some versions of dig will complain about kubernetes
cluster.localaddresses and log a warning that you’re intruding on the mDNS spacere certs for local/developer uses: my current employer bought a cert for a domain we control but don’t otherwise use that points at 127.0.0.1 and distributed the cert/key to all our developers. so, we have a signed cert for developer use and don’t have to deal with any self signing or trying to run a CA or anything. I highly recommend this and I hadn’t run into before but whatever we spent on the cert has been more than paid back by us not having to manage our own certs. If and when I move on I would recommend the same thing to that employer as well
fwiw our cert is something like
local.ourcompany.different-TLD-than-we-use-anywhere-elseFor people who don’t work at this company, you can instead create locally-trusted certificates easily with mkcert.
Yes you can, however there are still situations where those self signed certs can be extremely annoying. The immediate thing that comes to mind is attempting to run something like puppeteer in a container. As soon as you introduce other logical machines like containers or VMs self signed certs get extremely unwieldy. And now you are further separating your dev environment even more from staging/prod
We run our own ca infra and developers have tooling to get an internally trusted cert/key. Reusing certs/keys is strictly prohibited, even in development
We used to have a top level domain for private use, .dev, until Google exploited the situation and took it over, demanding exorbitant sums for domain names using it.
I don’t understand why google has the right to print money like this (or godaddy with their widespread squatting). Money certainly seems to be ruining DNS as of late.