RFC: retry keyservers witout SRV
Luis R. Rodriguez
mcgrof at kernel.org
Wed Nov 29 20:20:01 CET 2017
On Wed, Nov 29, 2017 at 09:53:10AM +0100, Werner Koch wrote:
> On Tue, 28 Nov 2017 22:41, mcgrof at kernel.org said:
> > Thanks, what sort of documentation exists where this is stated other than
> > in actual code?
>
> There is no real documentation for keyservers. Howerver SRV records are
> in use for ages and that makes them a part of the specification.
Not having any formal docs for keyservers seems pretty unfortunate to say the
least, but its understandable given how it came about with Marc Horowitz's
first web based OpenPGP HTTP Keyserver.
In particular having to fulfill a DNS query for keyservers using DNS HKP SRV
seems like a pretty unique requirement I certainly was not expecting, has it
been a requirement since day 1 for keyservers?
Since there is no formal documentation about keyservers I can say I at least
tried to look for some and I did find at least one paper by Kristian Fiskerstrand
on benefits of using SRV on sks-keyservers.net [0]. This paper seems to
indicate to me it was *not* used since day 1 for all keyservers. In fact it
says GnuPG has had support for it since GnuPG v1.4.10 and v2.0.13, and it makes
it clear that PGP *did not* have support for it at the time the paper was
published on May 28, 2012.
The paper goes on about benefits and the algorithm used but its in no way clear
at all why using DNS HKP SRV is a hard requirement today.
So what is the hard technical requirement for it?
If GnuPG started using DNS HKP SRV since GnuPG v1.4.10 and v2.0.13 why is it
*now* a hard requirement?
Even if there is no real documentation I think it might be fair to ask this,
and perhaps for us to add such documentation now to GnuPG (yes, I can volunteer).
> >> we may use it to debug problems with SRV records. The "debug" prefix
> >> would also clearly mark this as a non-standard option.
> >
> > Given the above this makes perfect sense.
>
> I will consider that.
>
> > Sure, but given my little survey it would seem many more devices are affected,
> > so it does not seem to just be a one-off router, essentially completely disabling
> > PGP without any warning what so ever to the user about the reason for
>
> Given your description won't also not be able to use any XMPP service.
> In XMPP the use of SRV records is specified in the RFCs and many sites
> won't work without them. In case XMPP works for you - how does your
> gateway behave in this case?
I've long gone replaced the firmware on the router now so this is no longer
an issue for me. But I don't recall issues with XMMP. In fact the original
issues were so odd that I *had* to look underneath the hood.
If *no* keyserver records are found *at all* and the operation requested does
need one, should the error at least be clear about the issue being an SRV
record request? As noted, it does *not* seem to be off-one issue, I suspect
others may run into this again, and unless they really try to look underneath
the hood, PGP would essentially appear to just not work and it would be very
unclear why. Specially given SRV records *are* required for DNS lookup for an
undocumented service, expecting it to be obvious why PGP may not work for users
seems counter intuitive.
[0] https://sks-keyservers.net/files/sks-keyservers-SRV.pdf
Luis
More information about the Gnupg-devel
mailing list