Re: [Sks-devel] SRV records and HKPS requests

[Kristian Fiskerstrand]

On 10/07/2012 04:20 AM, Phil Pennock wrote:
> GnuPG folks (since this is cross-posted, if my mail makes it through):
> 
>  there is a bug in GnuPG's SRV handling, I've identified where I think
>  it is, it's in the second block of text from me; the first part of this
>  mail relates to SKS and some policy issues around the new keyserver
>  pool Kristian has added.

Hi Phil,

Thanks for helping tracking down the SRV bug.

> 
> On 2012-10-06 at 17:48 +0200, Kristian Fiskerstrand wrote:
>> Some background information on this particular pool: My crawler is now
>> trying to detect HKPS enabled servers by looking for this SRV record,
>> and if no such SRV record is found, attempting to connect and locate a
>> SKS stats page on port 443. Servers available on 443 are then included
>> as A, AAAA and SRV records, while other SSL-enabled servers are only
>> represented as SRV records, as shown in #Snippet 3#
> 
> Ah, interesting; in checking, I just discovered that my SRV record for
> _pgpkey-https had not been updated since I added nginx proxying, so was
> still giving the "0 0 0 ." (explicitly no service here) response, but
> what's happening is that you're looking for records on the _server_, I
> think, not the "discoverability" records on the _domain_.
> 
> Normally, I think the answer is "whatever is given to GnuPG as the
> host/domain label in the --keyserver URL".  This is a little different.
> 
> Not knowing if you're using the hostname from peering records, or the
> hostname reported from the lookup?op=stats pages, I've added records for
> both.  That should cover it, right?  Your snippet 3 suggests the
> op=stats hostname, but seems safest to just cover both.
> 


I should be a tad more specific here. The HKPS Pool is unrelated to the
main pool in the sense that it either finds a HTTPS host or not, so
currently SRV record won't affect the regular pools, only HKPS. Although
I might update this going forwards and start looking for SRV records for
_pgpkey-http as well as _pgpkey-https.

I'm doing a few sanity checks when looking at the SRV records, as can be
seen in [0] around line 295.
1) The SRV target has to match the hostname of the SKS Server as
reported in the stats page
2) Port has to be in a range of 1 - 65536

If these two conditions are not there, the SRV record will be ignored,
and the crawler continues with looking up port 443. If you want me to
add some non-discovery check to tell it to butt out at this stage I can
certainly do that.

[0]
http://code.google.com/p/sks-keyservers-pool/source/browse/trunk/sks-keyservers.net/status-srv/sks_get_peer_data.php


-- 
----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
----------------------------
"I never worry about action, but only inaction."
(Winston Churchill)
----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/

signature.asc
Description: OpenPGP digital signature