https://en.wikipedia.org/wiki/SSHFP_record
Of course this has its own challenges, but if you automate your DNS, this can be neat!
Cheers!
CloudFlare added support in 2018: https://blog.cloudflare.com/additional-record-types-availabl...
AWS still doesn’t support it: http://web.archive.org/web/20210429183447/https://forums.aws...
Namecheap doesn’t: https://www.namecheap.com/support/knowledgebase/article.aspx...
GCP doesn’t: https://cloud.google.com/dns/docs/records
Azure doesn’t: https://learn.microsoft.com/en-us/azure/dns/dns-zones-record...
Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.
I don't believe that that is true. DNSSEC RRSIG records are created over the entire result set. So even if there are numerous records returned, you should still be able to verify the signature. Also, there is nothing stopping you from also returning multiple SSHFP records in a single query.
However, SPF does have a design flaw (amongst many other) that the record is placed under the domain root, which is often already polluted with other records. This is why other standards that use TXT (DMARC, DKIM, BIMI, MTA-STS, TLSRPT, etc.) use a specific label prefix, or a selector. But this is not because of DNSSEC.
For ssh that doesn't really apply as clearly though.
https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-d...
https://www.huque.com/2014/07/30/dnssec-key-trans.html
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
Do all CAs implement multi-prespective validation these days? Let's Encrypt implemented that only in 2020 and they believed they were the first ones:
https://letsencrypt.org/2020/02/19/multi-perspective-validat...
Do you think that DNS-based proof of ownership is not something that CAs would use for SSH certification?
In contrast, there is no unique "root CA" that can fail.
DNS root key compromise breaks the entire system until it is replaced.
Not seeing a huge difference.
It is not possible to revoke the DNS root, and there are no widely deployed alternatives. The incentive to do the right thing isn't as hard: it's just "good" guys doing the right stuff. If something wrong happens, where will you go ? Nowhere else.
A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design.
Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.
Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.
> Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.
This is bypassing a dangerous design, at best.
But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.
If a country decided to invalidate the security of (predominantly) its own citizens' websites then that wouldn't harm anyone who used any of the other ccTLDs in the world (not to mention the hundreds of gTLDs).
Also, I think you are over-estimating the ease with which a CA can be "quickly mistrusted". What is the record for how quickly a CA has been taken out of browsers' certificate stores, measured from the time of their first misissuance?
And I would argue that revoking CA trust to Let's Encrypt / IdenTrust would be much more disruptive than revoking a single ccTLD operator, since that would mean breaking most sites on the web. So DNSSEC is actually better in terms of the "too big to fail" problem.
> This is bypassing a dangerous design, at best.
But that's my point; DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you, and wait for the bureaucratic and software update processes to remove that CA from all your users' browsers.
There are definitely limitations to the DNSSEC system as currently deployed, just as there were with the web PKI system before browsers started to patch all the holes in that, but I don't know why my position on this technical question is so controversial. Nevertheless, I really appreciate you taking the time to offer intelligent counter-arguments in your comment, thank you.
Entire countries best case is a small blast radius? A small CA going rogue would have a much smaller one, when we're talking about best case. Worst case is massive either way (say LetsEncrypt and .com). People also buy a lot of domains ignoring the fact that they're ccTLDs. The mere implication that people should choose their domains considering this fact is terrible.
> The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.
They can, but it'll be discovered really quick, especially with CAA violations. This can't be said about DNSSEC, any key compromise and abuse is difficult if not impossible to detect. Imagine that but with DANE, indefinite MITM, scary.
> DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you
That's an insane bypass though. "Just cut your arm off, then it won't hurt." Change your email, figure out how to patch millions of devices out in the wild, so many problems.
A rogue issuer is much less hassle short- and long-term to deal with. Most browsers ship CRLite or similar and can revoke the root quickly. You can resume operation with a new CA rather fast.
DNSSEC is a nice complement to WebPKI and vice versa, but for our all sake, it can't be the only source of trust.
> SSHFP:
> https://www.rfc-editor.org/rfc/rfc4255
>> Re SSHFP:
>> Regarding DNS as a database for keys... Please stop this madness.
>> DNS isn't a database.
>> It's not a configuration store.
>> It was meant and should be used only for name resolution.
[0] https://mjg59.dreamwidth.org/65874.html?thread=2106450#cmt21...
>> It's not a configuration store.
Its quite literally both those things.
There may be practical reasons to question storing high value keys in dns. But not being a database of configuration info isn't one of them.
People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?
> I must say that I am not a fan of these floppy-based routers. Essentially, you are taking one of the most unreliable pieces of storage known to man, and trying to build security infrastructure on it. That's madness.
dns is not the foundation upon which you want to build your secure infrastructure.
Besides, we’re not talking about secure infrastructure per se, but distributing public metadata for IP addresses. That sounds like the prime thing DNS has been invented for to me.
2. Cache. People are caching DNS aggressively. Often more aggressive than what the TTL allows.
You don't want to save the fingerprint in a stale, insecure database like that.
If you start using other ways of using DNS, then you might as well not use DNS and instead develop something more suited to the purpose.
I'd be interested to know where you get your data from. By my count, there are 142 ccTLDs that support it and 106 that don't, out of 248 ccTLDs.[0]
That's already more than half, but if you include the gTLDs then the number of TLDs signed in the DNS root goes up to 92% according to the best data I can find.[1]
I'm trying to figure out how having a stale fingerprint would be an automatic bad thing.
Let's assume you have a server with a fingerprint stored in DNS. Something happens and the server's certificate/key needs to change. So now you push out a new key fingerprint to DNS.
The failure mode for an out-of-date fingerprint would be to not trust the new server's key. In this case, the default failure mode is to fail safely. The client could then have a few new options, like querying the authoritative DNS server or prompt the user.
You can argue that you wouldn't want to have stale DNS caching in an automated system, but in a user-interactive mode, it's not the worst thing.
And for an automated system, the system should be robust enough to manage a bad fingerprint (fail safely again), or be in control of the entire infrastructure, including you DNS cache.
Or am I missing something?
But its kind of a strawman because nobody is suggesting putting unauthenticated keys in dns with no dnssec. The suggestion is either using dnssec, or have some sort of CA system.