--- Begin Message ---
One good example of where it is used:
pkgs.fedoraproject.org publishes SSHFP record on signed domain. That can
be used by hundreds and thousands of developers. Unfortunately it
requires explicit enabling that in SSH. Needs also dnssec verification
enabled, which is not the default.
I think it might make sense to publish your SSH key in form of KEY
record. You could use similar owner digest computation like OPENPGPKEY
record does. That might allow people just to type ssh-allow
[email protected], which could get his public keys and added them into
authorized_keys on some your machine. Without any special internal
database needed.
Some kind of internal domain for it would make more sense to me. You do
not have to be too verbose to publish what types of keys do you rely on.
In fact I proposed to add also SSHFP similar way to OPENPGPKEY records,
because SSH key can be used even to sign some code. It could act as sort
of quick revocation of SSH keys solution.
So, I think it is sometimes used. It could be used more often if DNSSEC
validation was more common on end client machines.
Regards,
Petr
On 26/02/2025 19:00, Phillip Hallam-Baker wrote:
I am currently taking a hard look at mechanisms for using DNS Handles
as a means for exchange of authenticated and non-authenticated contact
information via JSContact.
As part of that, I wanted to know if there was any *existing* use of
the SSHFP record for publishing SSH credentials and if so whether it
was limited to the server. And yes, I can read the specs, what I am
asking about is actual practice.
If there is existing use, it might be something to build on.
Otherwise, I think it best to forget it and apply the same SRV/TXT
framework used for everything else.
The basic idea of JSContacts in handles being that I can
put @phill.hallambaker.com <http://phill.hallambaker.com> on my
business card or a publication, someone can pull the TXT record and
get a uri that is a locator, decryptor and authenticator all in one:
_jscontact.phill.hallambaker.com
<http://jscontact.phill.hallambaker.com>. IN TXT
"uri=jscontact://mplace2.social/egm3-lbnd-upo4-yxha-fy7p-hiim-y4kq"
This sounds like you are looking for URI record directly. This should
not be in TXT record this way.
That egm3-lbnd-upo4-yxha-fy7p-hiim-y4kq bit is a truncated SHA-3
digest of the contact data. So if my SSH key is in the contact and the
TXT record is DNSSEC signed, we have at least some authentication of
the contact.
Alternatively, I might put the jscontact link on my business card as a
QR code. So now, you can scan the link and get direct verification.
mplace2.social is just a resolution hint, a domain that currently has
the contact information. If that is going to be in a paper
publication, the resolution site might have changed but not the
contact itself.
jscontact: @phill.hallambaker.com/egm3-lbnd-upo4-yxha-fy7p-hiim-y4kq
<http://phill.hallambaker.com/egm3-lbnd-upo4-yxha-fy7p-hiim-y4kq>
Since my publication engine has to populate the TXT records, it can do
SSHFP in theory. But I see no reason to do that if it hasn't already
established a user base.
The problem is somehow common. How can application trust the system it
did dnssec validation properly? Linux has added recently trust-ad flag
to indicate ad bit in response means something to us. Some
implementations mistake AD bit with AA bit instead.
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
