SRV-Record lookups for keyserver discovery?
44 views
Skip to first unread message
Özgür Kesim
Feb 26, 2024, 9:19:38 AMFeb 26
to Upspin
Hello upspiners,
I ran an experiment lately and tried to access all the name spaces
listed in key.upspin.io/log. One result was that more than 50% were
clearly decommisioned systems - the DNS lookup's for the storage
servers failed (no such hosts). This let me to file issue #661
(dircache.watcher never times out on non-existing hosts) which is now
fixed.
However, that also made think of an idea and I was wondering what
people think about introducing SRV DNS-records¹ for the lookup of the
key-server of a domain?
Say, I want to access another namespace "fn...@kesim.org". Currently
the upspin code uses the keyserver from the config-file for the lookup
of keys and storage host related to that namespace.
I propose to prior of using the configured keyserver (or maybe only
when the lookup with the configured keyserver fails) to do a
DNS-lookup of a SRV record for that domain, something along the lines
of:
_upspin._tcp.kesim.org. 86400 IN SRV 10 60 443 keyserver.kesim.org.
This would allow an owner of a domain to run her own keyserver and
make it publically discoverable. From a trust perspective, there is
not much of a difference for me as a user to trust key.upspin.io any
more than the DNS record for the domain kesim.org.
Also, the changes to the code base are probably going to be quite
small (1 DNS-lookup + fallback logic). I would be happy to implement
support and testing for that.
What do you think?
Cheers,
Özgür (Oscar)
¹) https://de.wikipedia.org/wiki/SRV_Resource_Record
I ran an experiment lately and tried to access all the name spaces
listed in key.upspin.io/log. One result was that more than 50% were
clearly decommisioned systems - the DNS lookup's for the storage
servers failed (no such hosts). This let me to file issue #661
(dircache.watcher never times out on non-existing hosts) which is now
fixed.
However, that also made think of an idea and I was wondering what
people think about introducing SRV DNS-records¹ for the lookup of the
key-server of a domain?
Say, I want to access another namespace "fn...@kesim.org". Currently
the upspin code uses the keyserver from the config-file for the lookup
of keys and storage host related to that namespace.
I propose to prior of using the configured keyserver (or maybe only
when the lookup with the configured keyserver fails) to do a
DNS-lookup of a SRV record for that domain, something along the lines
of:
_upspin._tcp.kesim.org. 86400 IN SRV 10 60 443 keyserver.kesim.org.
This would allow an owner of a domain to run her own keyserver and
make it publically discoverable. From a trust perspective, there is
not much of a difference for me as a user to trust key.upspin.io any
more than the DNS record for the domain kesim.org.
Also, the changes to the code base are probably going to be quite
small (1 DNS-lookup + fallback logic). I would be happy to implement
support and testing for that.
What do you think?
Cheers,
Özgür (Oscar)
¹) https://de.wikipedia.org/wiki/SRV_Resource_Record
David Presotto
Feb 26, 2024, 10:17:52 AMFeb 26
to Özgür Kesim, Upspin
It slightly increases the attack surface but not that much. Sounds like a good idea to me.
--
You received this message because you are subscribed to the Google Groups "Upspin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to upspin+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/upspin/w7zryapiviwxs7zs5mbnynf2ndzy66m7qsm3jr5lu7yib5djmt%40jxe42nm67icz.
Eric Grosse
Feb 26, 2024, 2:14:52 PMFeb 26
to Özgür Kesim, Upspin
Nice suggestion. A couple questions, to help me understand:
Q1: If you trust that a few of us monitor the TLS certificates for
key.upspin.io and check the key.upspin.io log checksums, then you have
some assurance that fake keys are not being selectively given to a
victim. Do you have as much confidence that nowhere in the world does
DNS point to a fake keyserver.kesim.org?
Q2: Suppose all upspin domains adopted SRV records as proposed. We
could even get rid of key.upspin.io, which nicely saves me a monthly
charge for running upspin infrastructure. But then how would you
re-run your original experiment?
These are not fatal issues; for example, we might shift our trust
model to an ssh-like warn-upon-keychange. And there could be a
convention on a central place to post notice of new and changed upspin
domains. Or we could depart from the attempted global upspin community
and accept smaller communities of interest.
Q1: If you trust that a few of us monitor the TLS certificates for
key.upspin.io and check the key.upspin.io log checksums, then you have
some assurance that fake keys are not being selectively given to a
victim. Do you have as much confidence that nowhere in the world does
DNS point to a fake keyserver.kesim.org?
Q2: Suppose all upspin domains adopted SRV records as proposed. We
could even get rid of key.upspin.io, which nicely saves me a monthly
charge for running upspin infrastructure. But then how would you
re-run your original experiment?
These are not fatal issues; for example, we might shift our trust
model to an ssh-like warn-upon-keychange. And there could be a
convention on a central place to post notice of new and changed upspin
domains. Or we could depart from the attempted global upspin community
and accept smaller communities of interest.
David Presotto
Feb 26, 2024, 3:09:42 PMFeb 26
to Eric Grosse, Özgür Kesim, Upspin
Oops, p...@birdsh.it can't reply to upspin. Trying again as presotto.
On Mon, Feb 26, 2024 at 12:07 PM David Presotto <p...@birdsh.it> wrote:
We'd still need to offer some key server since people don't necessarily control the domains they are using. Plus I would still want to get a negative reply from key.upspin.io before even trying the domain specific one. even of that slows things down a bit. Makes people hijacking a little harder.As for fake keyserver.kesim.org we'd still expect a valid cert. Not perfect but helpful.
To view this discussion on the web visit https://groups.google.com/d/msgid/upspin/CAHfGVNcL1W2J5nRQM%2BS6ZRvuj4hhXNaf%2BMYfCNEMY_-Pb4%3D6gA%40mail.gmail.com.
Özgür Kesim
Feb 27, 2024, 7:43:46 AMFeb 27
to Upspin
[Answering both emails, from Eric and David]
As David pointed out, there will be a need for `key.upspin.io` to exist
for any user with a name for which the owner of a domain won't run a
dedicated keyserver.
The proposal for using SRV records for the discovery of keyservers
helps to create a genuinely distributed, yet still global namespace,
that is: maintaining discoverability under proliferation of the
instantiations.
But the proposal doesn't solve or alter the trust issue. As I argued
earlier, from the user's perspective, there is no (technical) reason
to trust the domain owner and maintainer of key.upspin.io any more
than the domain owner of any other domain. Also, again from the
user's perspective, there is no technical reason to trust the
_contents_ of key.upspin.io without prior knowledge f.e. of the
fingerprint of a key.
(Using auto-certifiers like letsencrypt doesn't solve the trust issue
neither, as I have to trust the domain- and email-address ownership to
begin with. But again, the proposal is orthogonal to the trust
issue.)
To give you a concrete motivation for my suggested approach:
an...@upspin.io has de-facto been decommissioned, but is still
referred to in various places in the code base (upspin-ui, f.e.).
Let me aggressively extrapolate from this incidence:
There could be a point in time where control over the domain upspin.io
or the instance key.upspin.io is lost. The current incarnation of the
global namespace would basically go dark, at least for a while. Using
SRV records, however, would keep the lights on at parts of the global
namespace, making it more resilient.
I think the two suggestions by David and Eric (and two added by me)
are strong requirements for a proper design of the proposal:
- Use key.upspin.io as the default and SRV lookup results only as
fallback.
- Add warnings on key and keyserver changes. Requires local storage of
that information.
- Add warnings if a username occurs on multiple keyservers with
different keys.
- Maybe generally useful: Provide a mechanism to confirm a public key
of a user's name by providing a fingerprint (acquired by another,
trusted channel).
As for the experiment I ran: I could re-run with the entries in the
still existing key.upspin.io, of course. For other domains I would
have to somehow guess or find domain-names and then lookup SRV
records. However, this is not any different from, say, currently
self-hosted instances of upspin-keyservers that might or might not be
publicly listed.
As for the SRV-based lookup itself in a potential implementation: I
was thinking to actually run it in a goroutine, in parallel to the
request to key.upspin.io. That way, we can always evaluate the
consistency of the results without adding much of a delay by another
round trip.
Cheers,
Özgür (Oscar)
Thus spake Eric Grosse (gro...@gmail.com):
> Nice suggestion. A couple questions, to help me understand:
>
> Q1: If you trust that a few of us monitor the TLS certificates for
> key.upspin.io and check the key.upspin.io log checksums, then you have
> some assurance that fake keys are not being selectively given to a
> victim. Do you have as much confidence that nowhere in the world does
> DNS point to a fake keyserver.kesim.org?
>
> Q2: Suppose all upspin domains adopted SRV records as proposed. We
> could even get rid of key.upspin.io, which nicely saves me a monthly
> charge for running upspin infrastructure. But then how would you
> re-run your original experiment?
>
> These are not fatal issues; for example, we might shift our trust
> model to an ssh-like warn-upon-keychange. And there could be a
> convention on a central place to post notice of new and changed upspin
> domains. Or we could depart from the attempted global upspin community
> and accept smaller communities of interest.
>
Thus spake David Presotto (p...@birdsh.it):
As David pointed out, there will be a need for `key.upspin.io` to exist
for any user with a name for which the owner of a domain won't run a
dedicated keyserver.
The proposal for using SRV records for the discovery of keyservers
helps to create a genuinely distributed, yet still global namespace,
that is: maintaining discoverability under proliferation of the
instantiations.
But the proposal doesn't solve or alter the trust issue. As I argued
earlier, from the user's perspective, there is no (technical) reason
to trust the domain owner and maintainer of key.upspin.io any more
than the domain owner of any other domain. Also, again from the
user's perspective, there is no technical reason to trust the
_contents_ of key.upspin.io without prior knowledge f.e. of the
fingerprint of a key.
(Using auto-certifiers like letsencrypt doesn't solve the trust issue
neither, as I have to trust the domain- and email-address ownership to
begin with. But again, the proposal is orthogonal to the trust
issue.)
To give you a concrete motivation for my suggested approach:
an...@upspin.io has de-facto been decommissioned, but is still
referred to in various places in the code base (upspin-ui, f.e.).
Let me aggressively extrapolate from this incidence:
There could be a point in time where control over the domain upspin.io
or the instance key.upspin.io is lost. The current incarnation of the
global namespace would basically go dark, at least for a while. Using
SRV records, however, would keep the lights on at parts of the global
namespace, making it more resilient.
I think the two suggestions by David and Eric (and two added by me)
are strong requirements for a proper design of the proposal:
- Use key.upspin.io as the default and SRV lookup results only as
fallback.
- Add warnings on key and keyserver changes. Requires local storage of
that information.
- Add warnings if a username occurs on multiple keyservers with
different keys.
- Maybe generally useful: Provide a mechanism to confirm a public key
of a user's name by providing a fingerprint (acquired by another,
trusted channel).
As for the experiment I ran: I could re-run with the entries in the
still existing key.upspin.io, of course. For other domains I would
have to somehow guess or find domain-names and then lookup SRV
records. However, this is not any different from, say, currently
self-hosted instances of upspin-keyservers that might or might not be
publicly listed.
As for the SRV-based lookup itself in a potential implementation: I
was thinking to actually run it in a goroutine, in parallel to the
request to key.upspin.io. That way, we can always evaluate the
consistency of the results without adding much of a delay by another
round trip.
Cheers,
Özgür (Oscar)
Thus spake Eric Grosse (gro...@gmail.com):
> Nice suggestion. A couple questions, to help me understand:
>
> Q1: If you trust that a few of us monitor the TLS certificates for
> key.upspin.io and check the key.upspin.io log checksums, then you have
> some assurance that fake keys are not being selectively given to a
> victim. Do you have as much confidence that nowhere in the world does
> DNS point to a fake keyserver.kesim.org?
>
> Q2: Suppose all upspin domains adopted SRV records as proposed. We
> could even get rid of key.upspin.io, which nicely saves me a monthly
> charge for running upspin infrastructure. But then how would you
> re-run your original experiment?
>
> These are not fatal issues; for example, we might shift our trust
> model to an ssh-like warn-upon-keychange. And there could be a
> convention on a central place to post notice of new and changed upspin
> domains. Or we could depart from the attempted global upspin community
> and accept smaller communities of interest.
>
Eric Grosse
Feb 27, 2024, 9:08:42 AMFeb 27
to Özgür Kesim, Upspin
All sounds ok to me.
--
You received this message because you are subscribed to the Google Groups "Upspin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to upspin+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/upspin/rpbwkg3q7u6cqxbxenjs3y5fzqpoqzhqnvm3mf5ckaagk2oalq%40mor5ceipvsh3.
Albert-Jan de Vries
Mar 4, 2024, 5:16:05 AMMar 4
to Upspin
All very good ideas. I think I mentioned ti before, but I run a backup/failback key server, that has a cache of the users and their keys (from key.upspin.io). So when key.upspin.io is down my upspin services still work.
Op dinsdag 27 februari 2024 om 15:08:42 UTC+1 schreef Eric Grosse:
Reply all
Reply to author
Forward
0 new messages